Bug 202209 - gcj compiled applications require execstack priviledge by default
gcj compiled applications require execstack priviledge by default
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: gcc (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Depends On:
  Show dependency treegraph
Reported: 2006-08-11 11:52 EDT by Daniel Walsh
Modified: 2008-08-02 19:40 EDT (History)
7 users (show)

See Also:
Fixed In Version: 4.1.2-7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-04-02 04:26:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Daniel Walsh 2006-08-11 11:52:53 EDT
Description of problem:
Comment 1 Daniel Walsh 2006-08-11 11:56:22 EDT
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.


Comment 2 Jakub Jelinek 2006-08-11 12:15:39 EDT
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.
Comment 3 Daniel Walsh 2006-08-12 06:34:27 EDT
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?
Comment 4 Andrew Haley 2006-08-12 10:17:17 EDT
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.
Comment 5 Andrew Haley 2006-08-12 10:31:38 EDT
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.

Comment 6 RHEL Product and Program Management 2006-10-26 16:29:40 EDT
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
Comment 9 Jakub Jelinek 2007-01-04 05:50:23 EST
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
Comment 35 Jakub Jelinek 2007-01-11 03:33:50 EST
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.
Comment 38 Jakub Jelinek 2007-01-11 11:55:38 EST
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.
Comment 43 Jakub Jelinek 2007-01-13 03:41:00 EST
                       (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...
Comment 45 Alexandre Oliva 2007-01-18 02:29:02 EST
Patch posted at http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01496.html, but
beware of the broken patch fixed in a followup.
Comment 46 Jakub Jelinek 2007-04-02 04:26:20 EDT
Should be fixed in gcc-4.1.2-7, thanks Alex.

Note You need to log in before you can comment on or make changes to this bug.