Hi David, thanks for the comment . Currently I do not see the issue in our fastdebug builds . So I think the opt-flag filtering got changed/removed in the years after the issues were reported .
https://bugs.openjdk.java.net/browse/JDK-8047952 mentions special O-level settings for sharedRuntimeTrig.cpp and sharedRuntimeTrans.cpp . But the files have optimization set in both fastdebug and opt builds : Linux x86_64 gcc-7 based builds : fastdebug build (with the added -D_FORTIFY_SOURCE=2 flag) : -Werror -O3 -D_FORTIFY_SOURCE=2 -DNO_PCH -ffp-contract=off -O2 -D_FORTIFY_SOURCE=2 Opt build (without -D_FORTIFY_SOURCE=... ) : -O3 -DNO_PCH -ffp-contract=off -O2 .... (btw. the setting of both -O3 AND -O2 looks strange to me , but that’s unrelated to my change ; I noticed that already in OpenJDK 11 ). Best regards, Matthias > > Hi Matthias, > > On 8/05/2019 6:05 pm, Baesken, Matthias wrote: > > Hello, here is a webrev, I used the existing bug > > "JDK-8130017 : use _FORTIFY_SOURCE in gcc fastdebug builds" > > > > Hope that’s fine . > > That is fine, but please add a comment to the bug explaining exactly how > you fixed the issue and how the issues raised in the bug description > regarding optimisation levels have been addressed. > > Not a review - I'll leave that to build team. The proof of this will be > in the building and testing. > > Thanks, > David > > > 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.joels...@oracle.com>; 'build- > >> d...@openjdk.java.net' <build-dev@openjdk.java.net> > >> Cc: 'Kim Barrett' <kim.barr...@oracle.com>; Zeller, Arno > >> <arno.zel...@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.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
