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.joels...@oracle.com> > Sent: Freitag, 3. Mai 2019 17:40 > To: Baesken, Matthias <matthias.baes...@sap.com>; 'build- > d...@openjdk.java.net' <build-dev@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