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 12:36:52 UTC 2019


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.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