Bug 202209 - gcj compiled applications require execstack priviledge by default
Summary: gcj compiled applications require execstack priviledge by default
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: gcc
Version: 4.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Jakub Jelinek
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-08-11 15:52 UTC by Daniel Walsh
Modified: 2008-08-02 23:40 UTC (History)
7 users (show)

Fixed In Version: 4.1.2-7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-04-02 08:26:20 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Daniel Walsh 2006-08-11 15:52:53 UTC
Description of problem:

Comment 1 Daniel Walsh 2006-08-11 15:56:22 UTC
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



Comment 2 Jakub Jelinek 2006-08-11 16:15:39 UTC
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 10:34:27 UTC
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 14:17:17 UTC
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 14:31:38 UTC
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 Program Management 2006-10-26 20:29:40 UTC
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.

Comment 9 Jakub Jelinek 2007-01-04 10:50:23 UTC
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 08:33:50 UTC
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 16:55:38 UTC
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 08:41:00 UTC
                       (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 07:29:02 UTC
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 08:26:20 UTC
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.