Description of problem:
This is forcing us to turn off allow_execstack boolean in Beta releases. Not allowing execstack/execmem applications is a great security benefit to RHEL and Fedora Core. The following bugzilla discusses this fully. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201038
Can you explain what exactly you are asking for? - Is that changing boehm-gc so that it handles two pools of memory - non-executable and executable, using non-PROT_EXEC one by default and force allocations for libffi stubs use PROT_EXEC pool? - Is that just issuing some understandable error message if mmap fails because of missing PROT_WRITE|PROT_EXEC permissions? - Is it teaching gcj driver to chcon the binaries it creates? In this case, still not sure what would be the way to go with rpms we ship. Given the nature of the language, it is impossible to get rid of execmem in all Java programs altogether.
I am not sure of the internals, but I would figure a compiled java that never intends to load a jar file should not require this priv. How many java applications are really required to work as a JVM? I would figure this is the bulk of compiled java apps. I do not think labeling the file directly is a good idea since, this would not transport well with the application and differnt policies would require different labels. We need to know the compiled java apps that need to work as a jvm. frysk is the only one I know for sure. tomcat? eclipse? jboss?
Tomcat, eclipse, jboss definitely all need executable memory. Anything that uses servlets, for sure: servlets are compiled and loaded at runtime. Anything that uses proxies: proxies use dynamically generated classes to wrap Java objects. It's wrong to think of compiled Java applications as some sort of big binary lump that'll never need to load a jar file. Although this is true of some small Java applications, it isn't generally true of the large ones.
A correction: I think that jboss starts with a script which invokes 'java', which will already be marked as using execmem. I'm not sure about Eclipse.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux major release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Major release. This request is not yet committed for inclusion.
I disagree, this is a WONTFIX for RHEL5, as that's too late, but for FC7 or FC8 it isn't impossible to solve, just harder. All that is needed is: 1) teach boehm-gc about multiple memory pools (executable vs. non-executable) 2) for the executable pool mmap memory twice, once executable non-writable, once writable non-executable, write through the former, execute from the latter
Looking at the various arches, x86/x86_64/cris/frv/mips/ppc32/s390{,x}/sh/sh64/sparc32 wouldn't need substantial changes, the trampoline already encodes a pointer to the closure and there is nothing which would rely that it is equal to the trampoline's address. ia64/ppc64 don't have executable trampolines. arm/m32r/m68k don't support closures at all. alpha/pa/sparc64 are the only architectures that would need bigger changes, perhaps have 2 kinds of trampoline instructions, one would be used with ffi_prep_closure and one with ffi_init_closure, the latter would store a pointer to the closure after the current instructions.
Regarding #37 second paragraph, only alpha/pa/sparc64 currently don't encode the closure address within the trampoline's instructions. So the rest of arches really don't care with current trampoline instructions and trampoline helpers where the closure data is. You really don't need to make the code portable IMHO. Only enable it on Linux (and only if asked for that with some configure option), for all other arches you just use the trivial implementation (return both pointer into closure's tramp array). I'm not aware of any other OS which would need exactly this and even if there is one, it will hardly not have mmap/munmap.
(void*) this); + (void*) this, + code); self->ncode = (void *) closure; This ought to be = code;, right? Shouldn't /dev/shm be among the list of mountpoints to try? /dev/shm very often contains a tmpfs...
Patch posted at http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01496.html, but beware of the broken patch fixed in a followup.
Should be fixed in gcc-4.1.2-7, thanks Alex.