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