Red Hat Bugzilla – Bug 1283949
no hardening build on F23
Last modified: 2015-12-20 01:53:04 EST
java 21955 Partial RELRO No canary found NX enabled No PIE
Hi Andrew, is this something we can safely do in the jvm?
The background to this - i.e. why we don't just pick up these changes by default - is that we don't pass LDFLAGS down to the build and OpenJDK doesn't do so on its own. If we want to enable these changes, we'd need to add --with-extra-ldflags.
The immediate thing that stands out to me in the wiki page is the mention of RPATH. The JDK relies on this to find its internal libraries so this can't be disabled.
rpath in doubt has *nothing* to do with PIE which has nothing to do with FULL RELO - different things - just harden as far as it is possible
(In reply to Deepak Bhole from comment #1)
> Hi Andrew, is this something we can safely do in the jvm?
AFAIK yes. The JVM itself is PIC because it's all in a shared library. Resolving all symbols when the program is started or when libjvm is dlopened should be OK.
(In reply to Harald Reindl from comment #3)
> rpath in doubt has *nothing* to do with PIE which has nothing to do with
> FULL RELO - different things - just harden as far as it is possible
I know. I was referring to this line:
"Running checksec should always report only Full RELRO Canary found NX enabled PIE enabled No RPATH No RUNPATH otherwise a tracking bug should exist for the respective packages."
OpenJDK is never going to be able to report "No RPATH". If whatever tool produces the bug reports flags this, OpenJDK will need to be exempted.
(In reply to Andrew John Hughes from comment #5)
> OpenJDK is never going to be able to report "No RPATH". If whatever tool
> produces the bug reports flags this, OpenJDK will need to be exempted.
Sure, there is nothing which can be done about that.
The other things (PIE, Stack canary, …) can be done I think.
Assigning to ahughes to investigate/implement which ones of the above can be done.
I started looking at this last week. This patch:
gets OpenJDK building with the Fedora standard LDFLAGS and most of the standard CFLAGS/CXXFLAGS. As explained in the patch, a few are filtered out as inappropriate.
A scratch build of this is here:
(no idea why the ARM build is stalled; have we seen this before?)
Can someone verify that the resulting binaries are now as expected? Thanks.
Ah ignore the ARM comment. It seems to have now completed, just very very slow.
Ugh, this change:
is also needed as OpenJDK wrongly uses the CFLAGS for the HotSpot C++ compiler.
This also fixes bug1120792.
Updated build: http://koji.fedoraproject.org/koji/taskinfo?taskID=12106076
looks way better, ZendStudio (PHP-IDE based on eclipse and my main java-application) rebuilt all my projects and as far as i can see works like before
java 18964 Full RELRO No canary found NX enabled PIE enabled
"No canary found" is a good question, there are also other applications and that *can be* a false positive, should be visible in the build-outputs if "-fstack-protector-strong" is used in the params
"OpenJDK is never going to be able to report "No RPATH" - Hmm :-)
[harry@srv-rhsoft:~]$ rpm -qa | grep jdk
If you check the first patch, you'll see the spec file was previously explicitly setting -fstack-protector-strong, so the canary should have been there from the start. What my patch does is bring the rest into line with Fedora, just blacklisting the few things that cause issues (no idea why -fexceptions is being set by Fedora, for example; this seems like something the developer should decide on).
If you check other files in the JDK package, like the libraries, they will have been compiled with -fstack-protector-strong. It seems the launchers (like 'java') aren't.
 SRC := /builddir/build/BUILD/java-1.8.0-openjdk-184.108.40.206-6.b17.fc23.i386/openjdk/jdk/src/share/bin
 INCLUDE_FILES := main.c
 LANG := C
 OPTIMIZATION := $(java_OPTIMIZATION_ARG)
 CFLAGS := $(java_CFLAGS) -I/builddir/build/BUILD/java-1.8.0-openjdk-220.127.116.11-6.b17.fc23.i386/openjdk/jdk/src/share/bin -I\
.0-openjdk-18.104.22.168-6.b17.fc23.i386/openjdk/jdk/src/linux/bin -DFULL_VERSION='"1.8.0_65-b17"' -DJDK_MAJOR_VERSION='"1"' -DJDK_\
MINOR_VERSION='"8"' -DLIBARCHNAME='"i586"' -DLAUNCHER_NAME='"openjdk"' -DPROGNAME='"java"' -DEXPAND_CLASSPATH_WILDCARDS
 CFLAGS_linux := -fPIC
 CFLAGS_solaris := -KPIC -DHAVE_GETHRTIME
 LDFLAGS := -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Xlinker --hash-style=both -Xlinker -z -Xlinker def\
s -Xlinker -O1 -Xlinker --allow-shlib-undefined -Xlinker -rpath -Xlinker \$$ORIGIN/../lib/i386/jli -Xlinker -rpath -Xlinker \$\
 LDFLAGS_macosx := -Xlinker -soname=java
 LDFLAGS_linux := -lpthread -Xlinker -soname=lib.so
 LDFLAGS_solaris := $(java_LDFLAGS_solaris) -Xlinker -soname=lib.so
 MAPFILE := $(java_MAPFILE)
 LDFLAGS_SUFFIX := $(java_LDFLAGS_SUFFIX)
 LDFLAGS_SUFFIX_posix :=
 LDFLAGS_SUFFIX_windows := $(java_WINDOWS_JLI_LIB) /builddir/build/BUILD/java-1.8.0-openjdk-22.214.171.124-6.b17.fc23.i386/open\
jdk/build/jdk8.build/jdk/objs/libjava/java.lib advapi32.lib user32.lib comctl32.lib
 LDFLAGS_SUFFIX_linux := -L/builddir/build/BUILD/java-1.8.0-openjdk-126.96.36.199-6.b17.fc23.i386/openjdk/build/jdk8.build/jdk\
/lib/i386/jli -ljli -ldl -lc
 LDFLAGS_SUFFIX_solaris := -L/builddir/build/BUILD/java-1.8.0-openjdk-188.8.131.52-6.b17.fc23.i386/openjdk/build/jdk8.build/j\
dk/lib/i386/jli -ljli -lthread -ldl -lc
I'll see if I can track down a fix for that.
The rest can go in by the sound of it. I don't have commit access to Fedora, so someone will need to pull the two changes into the f23 branch.
Ok, it is there:
/usr/bin/gcc -W -Wall -Wno-unused -Wno-parentheses -pipe -D_GNU_SOURCE -D_REENTRANT -D_LARGEFILE64_SOURCE -fno-omit-frame-poin\
ter -D_LITTLE_ENDIAN -DLINUX -DNDEBUG -DARCH='"i586"' -Di586 -DRELEASE='"1.8.0_65"' -I/builddir/build/BUILD/java-1.8.0-openjdk\
xport -I/builddir/build/BUILD/java-1.8.0-openjdk-184.108.40.206-6.b17.fc23.i386/openjdk/jdk/src/share/native/common -I/builddir/buil\
d/BUILD/java-1.8.0-openjdk-220.127.116.11-6.b17.fc23.i386/openjdk/jdk/src/solaris/native/common -g -pipe -Wformat -Wno-cpp -Werror=f\
ormat-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/li\
b/rpm/redhat/redhat-hardened-cc1 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -fno-strict-aliasing -I/builddir/bu\
jdk/src/linux/bin -DFULL_VERSION='"1.8.0_65-b17"' -DJDK_MAJOR_VERSION='"1"' -DJDK_MINOR_VERSION='"8"' -DLIBARCHNAME='"i586"' -\
DLAUNCHER_NAME='"openjdk"' -DPROGNAME='"java"' -DEXPAND_CLASSPATH_WILDCARDS -fPIC -g -O3 -DTHIS_FILE='"main.c"' -c -MMD -\
MF /builddir/build/BUILD/java-1.8.0-openjdk-18.104.22.168-6.b17.fc23.i386/openjdk/build/jdk8.build/jdk/objs/java_objs/main.d -o /bu\
java-1.8.0-openjdk-22.214.171.124-13.b17.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-c0a111beb9
java-1.8.0-openjdk-126.96.36.199-13.b17.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update java-1.8.0-openjdk'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-c0a111beb9
java-1.8.0-openjdk-188.8.131.52-13.b17.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.