RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - was : RE: gcc FORTIFY_SOURCE application security flags
Baesken, Matthias
matthias.baesken at sap.com
Wed May 8 08:05:17 UTC 2019
Hello, here is a webrev, I used the existing bug
"JDK-8130017 : use _FORTIFY_SOURCE in gcc fastdebug builds"
Hope that’s fine .
https://bugs.openjdk.java.net/browse/JDK-8130017
http://cr.openjdk.java.net/~mbaesken/webrevs/8130017.0/
Our internal OpenJDK Linux (x86_64, ppc64, ppc64le , s390x) fastdebug builds are fine with the added flag .
Best Regards, Matthias
> -----Original Message-----
> From: Baesken, Matthias
> Sent: Dienstag, 7. Mai 2019 16:55
> To: 'Erik Joelsson' <erik.joelsson at oracle.com>; 'build-
> dev at openjdk.java.net' <build-dev at openjdk.java.net>
> Cc: 'Kim Barrett' <kim.barrett at oracle.com>; Zeller, Arno
> <arno.zeller at sap.com>
> Subject: RE: gcc FORTIFY_SOURCE application security flags
>
> Hello, I looked at JDK-8050803 .
> There are build issues reported when using the _FORTIFY_SOURCE flag .
> However I only noticed one build issue, this is related to an additional
> warning ("no result checking of fwrite call") , most likely generated by the
> added compile time checks of -D_FORTIFY_SOURCE=2 .
> Obviously , the _FORTIFY_SOURCE flag must be used together with
> optimization flags , otherwise the feature does not work .
> So I propose to add it to the optimization flags, but only in case we have a
> fastdebug build. See the patch below .
>
> Best regards, Matthias
>
>
> Patch :
> -----------
>
> diff -r 26748009f2e5 make/autoconf/flags-cflags.m4
> --- a/make/autoconf/flags-cflags.m4 Thu May 02 20:47:23 2019 +0200
> +++ b/make/autoconf/flags-cflags.m4 Tue May 07 16:07:32 2019 +0200
> @@ -300,6 +300,13 @@
> C_O_FLAG_DEBUG="-O0"
> C_O_FLAG_DEBUG_JVM="-O0"
> C_O_FLAG_NONE="-O0"
> + # -D_FORTIFY_SOURCE=2 hardening option needs optimization enabled
> + if test "x$OPENJDK_TARGET_OS" = xlinux -a "x$DEBUG_LEVEL" =
> "xfastdebug"; then
> + C_O_FLAG_HIGHEST_JVM="${C_O_FLAG_HIGHEST_JVM} -
> D_FORTIFY_SOURCE=2"
> + C_O_FLAG_HIGHEST="${C_O_FLAG_HIGHEST} -D_FORTIFY_SOURCE=2"
> + C_O_FLAG_HI="${C_O_FLAG_HI} -D_FORTIFY_SOURCE=2"
> + C_O_FLAG_NORM="${C_O_FLAG_NORM} -D_FORTIFY_SOURCE=2"
> + fi
> elif test "x$TOOLCHAIN_TYPE" = xclang; then
> if test "x$OPENJDK_TARGET_OS" = xmacosx; then
> # On MacOSX we optimize for size, something
> diff -r 26748009f2e5 test/fmw/gtest/src/gtest.cc
> --- a/test/fmw/gtest/src/gtest.cc Thu May 02 20:47:23 2019 +0200
> +++ b/test/fmw/gtest/src/gtest.cc Tue May 07 16:07:32 2019 +0200
> @@ -34,6 +34,7 @@
> #include "gtest/gtest.h"
> #include "gtest/gtest-spi.h"
>
> +#include <assert.h>
> #include <ctype.h>
> #include <math.h>
> #include <stdarg.h>
> @@ -3538,7 +3539,8 @@
> // errors are ignored as there's nothing better we can do and we
> // don't want to fail the test because of this.
> FILE* pfile = posix::FOpen(premature_exit_filepath, "w");
> - fwrite("0", 1, 1, pfile);
> + size_t cnt= fwrite("0", 1, 1, pfile);
> + assert(cnt == (size_t)1);
> fclose(pfile);
> }
> }
>
>
> > -----Original Message-----
> > From: Erik Joelsson <erik.joelsson at oracle.com>
> > Sent: Freitag, 3. Mai 2019 17:40
> > To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-
> > dev at openjdk.java.net' <build-dev at openjdk.java.net>
> > Subject: Re: gcc FORTIFY_SOURCE application security flags
> >
> > Hello Matthias,
> >
> > We have tried to use it before but later removed it. See
> > https://bugs.openjdk.java.net/browse/JDK-8050803
> >
> > /Erik
> >
> > On 2019-05-03 08:12, Baesken, Matthias wrote:
> > >
> > >
> > > Hello.
> > > maybe some of you are aware of the gcc FORTIFY_SOURCE application
> > security flags.
> > > Developers can enable compile and also runtime checks for some string /
> > memory related operations with the flag.
> > >
> > > See details :
> > > https://access.redhat.com/blogs/766093/posts/1976213
> > >
> > > Have you tried already those flags in the OpenJDK ?
> > >
> > > One issue I experienced when using the flag (-D_FORTIFY_SOURCE=2) is
> > that in case that a runtime issue is detected,
> > > no hs_err file is written , only a "*** buffer overflow detected ***" +
> > backtrace + Memory map output is written, looks like this :
> > >
> > >
> > > *** buffer overflow detected ***: <my-path>/bin/java terminated
> > > ======= Backtrace: =========
> > > /lib64/libc.so.6(__fortify_fail+0x37)[0x7f5b500b7177]
> > > /lib64/libc.so.6(+0xe8e10)[0x7f5b500b4e10]
> > > /lib64/libc.so.6(+0xe8109)[0x7f5b500b4109]
> > > /lib64/libc.so.6(_IO_default_xsputn+0x85)[0x7f5b5003f705]
> > > /lib64/libc.so.6(_IO_vfprintf+0x18e)[0x7f5b5000f0ce]
> > > /lib64/libc.so.6(__vsprintf_chk+0x9d)[0x7f5b500b41ad]
> > > /lib64/libc.so.6(__sprintf_chk+0x80)[0x7f5b500b40f0]
> > >
> > > ........
> > > ======= Memory map: ========
> > > c0000000-c0700000 rw-p 00000000 00:00 0
> > > .....
> > >
> > >
> > >
> > > I would prefer to get a hs_err file, do you know a way to get this in
> context
> > of the gcc flag _FORTIFY_SOURCE ?
> > >
> > > In case this is not possible, the flag might not be useful any more for
> > OpenJDK .
> > > Maybe the gcc7 flags for memory error detection
> > >
> > > https://developers.redhat.com/blog/2017/02/22/memory-error-
> > detection-using-gcc/
> > >
> > > might provide an alternative solution - are they already enabled by
> default
> > ?
> > >
> > >
> > > Thanks, Matthias
More information about the build-dev
mailing list