United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-7019808 : build fails on Fedora 14: SELinux run-time check: execution of stack in libjvm.so

Details
Type:
Bug
Submit Date:
2011-02-15
Status:
Closed
Updated Date:
2013-01-31
Project Name:
JDK
Resolved Date:
2011-05-16
Component:
hotspot
OS:
linux
Sub-Component:
build
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
7
Fixed Versions:
hs21 (b12)

Related Reports
Backport:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

Description
Build of JDK7 trunk fails on Fedora 14 due to SELinux check:
libjvm.so is marked as trying to execute its stack, so in order for build to proceed one has to disable this check, either by turning off the SELinux functionality or by disabling just that stack execution check thus:

  sudo setsebool allow_execstack=on

This is the error I saw in the build:

cd linux_amd64_compiler2/fastdebug && ./test_gamma
java full version "1.6.0_23-b05"
./gamma: error while loading shared libraries: libjvm.so: cannot enable executable stack as shared object requires: Permission denied

With strace we see what's happening:

[pid  2700] execve("./gamma", ["./gamma", "-Xbatch", "-showversion", "Queens"], [/* 36 vars */]) = 0
[pid  2700] brk(0)                      = 0x9e7000
[pid  2700] mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f789c39a000
[pid  2700] access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
[pid  2700] open("./tls/x86_64/libjvm.so", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid  2700] open("./tls/libjvm.so", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid  2700] open("./x86_64/libjvm.so", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid  2700] open("./libjvm.so", O_RDONLY) = 4
[pid  2700] read(4, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240\215 \0\0\0\0\0"..., 832) = 832
[pid  2700] fstat(4, {st_mode=S_IFREG|0775, st_size=19803690, ...}) = 0
[pid  2700] getcwd("/home/dw136774/jdk7-sandbox2/tl/build/linux-amd64-fastdebug/hotspot/outputdir/linux_amd64_compiler2/fastdebug", 128) = 110
[pid  2700] mmap(NULL, 20004456, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) = 0x7f789b086000
[pid  2700] mprotect(0x7f789c049000, 2097152, PROT_NONE) = 0
[pid  2700] mmap(0x7f789c249000, 765952, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0xfc3000) = 0x7f789c249000
[pid  2700] mmap(0x7f789c304000, 613992, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f789c304000
[pid  2700] mprotect(0x7fff32fa8000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) = -1 EACCES (Permission denied)
[pid  2700] close(4)                    = 0
[pid  2700] writev(2, [{"./gamma", 7}, {": ", 2}, {"error while loading shared libra"..., 36}, {": ", 2}, {"libjvm.so", 9}, {": ", 2}, {"cannot en\
able executable stack a"..., 56}, {": ", 2}, {"Permission denied", 17}, {"\n", 1}], 10./gamma: error while loading shared libraries: libjvm.so: ca\
nnot enable executable stack as shared object requires: Permission denied

                                    

Comments
EVALUATION

These buiulds issues have previously been discussed on the ###@###.### mailing list - see the thread starting:

http://mail.openjdk.java.net/pipermail/build-dev/2010-December/003752.html

There is a proposed patch there, but I didn't see anyone pick up that patch. It's unclear if this is an actual hotspot build issue. One comment in that thread states:

"Also, all installed Java executables should be marked java_exec_t, like this:

happy:~ $ ls --lcontext /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/bin/java
-rwxr-xr-x. 1 system_u:object_r:java_exec_t:s0 root root 41000 2010-10-13 13:33 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/bin/java*

This allows RWX mapping of memory pages."
                                     
2011-02-16
EVALUATION

My question is where do we need to do this, just on selected loadobjects or any loadobjects that use libjvm.so?

I'm hoping that it's just libjvm.so,  but if it is, it needs to be done on all hotspot builds, 6-open, jdk7, and 6 updates.

I do not consider this a P4 issue, moving to P3.  (might even be a P2 issue if jdk7 doesn't work on Fedora 14+ out of the box).
                                     
2011-02-17
SUGGESTED FIX

This is the patch that was suggested.

diff -r 3f3653ab7af8 make/linux/makefiles/launcher.make
--- a/make/linux/makefiles/launcher.make	Fri Dec 03 19:44:29 2010 -0800
+++ b/make/linux/makefiles/launcher.make	Sat Dec 11 16:07:57 2010 -0800
@@ -73,4 +73,15 @@
 	    $(LINK_LAUNCHER) $(LFLAGS_LAUNCHER) -o $@ $(LAUNCHER.o) $(LIBS_LAUNCHER); \
 	    $(LINK_LAUNCHER/POST_HOOK) \
 	    [ -f $(LAUNCHER_G) ] || { ln -s $@ $(LAUNCHER_G); }; \
+            if [ \"$(CROSS_COMPILE_ARCH)\" = \"\" ] ; then                    \
+	      if [ -x /usr/sbin/selinuxenabled ] ; then                 \
+	        /usr/sbin/selinuxenabled;                               \
+                if [ $$? = 0 ] ; then					\
+		  /usr/bin/chcon -t execmem_exec_t $@;                  \
+		  if [ $$? != 0 ]; then                                 \
+		    echo "ERROR: Cannot chcon $@";			\
+		  fi							\
+	        fi							\
+	      fi                                                        \
+            fi 								\
         }
                                     
2011-02-17
PUBLIC COMMENTS

We handled the selinux problem with libjvm.so way back in 2007 under 6538311.

I don't understand why it has taken this long for the problem running the gamma  launcher to show up - more strict checks in Fedora? If the fix is as simple as indicated then I don't see a problem with it - but of course I'm not the RE assigned to this. The following post has some useful information:

http://forums.steampowered.com/forums/archive/index.php/t-1036467.html

I think because the gamma launcher is not kept around we don't need to worry about the "semanage" parts. That said, if the gamma launcher has this problem, what about the true Java launchers?
                                     
2011-02-17
PUBLIC COMMENTS

The root of the problem is: we set stack executable flag in the elf header of  libjvm.so during build so GNU ld call function _dl_make_stack_executable when load libjvm and attempts to change stack protection. This attempt is blocked by security check.

We didn't see it before probably because selinux has 
allow_execstack = 1 by default. So it has to be changed explicitly or binary have to be confined to see the error.

Linux has plenty of methods to control memory page protection and selinux is only one of them so we shouldn't rely on selinux attributes here but change linker options to don't mark stack of libjvm.so as executable (ld -z noexecstack)
                                     
2011-04-22
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/dddc5753c53a
                                     
2011-04-29
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/dddc5753c53a
                                     
2011-05-04



Hardware and Software, Engineered to Work Together