RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - was : RE: gcc FORTIFY_SOURCE application security flags

Wed May 8 12:06:08 UTC 2019

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