Re: Get libffi closures to cope with SELinux execmem/execmod

[Andrew Haley <aph at redhat dot com>]

Alexandre Oliva writes:
 > On Jan 24, 2007, Andrew Haley <aph@redhat.com> wrote:
 > 
 > > David Daney writes:
 > >> Well I'm not Anthony, but I am concerned about the overhead for
 > >> systems that have an executable stack.  I am thinking small
 > >> embedded systems.  It would be nice to have some sort of configure
 > >> option that would allow us to build it the old way, or close to the
 > >> old way if desired.  That said, I have not measured the size of the
 > >> dlmalloc and other additions to know if it really makes a
 > >> difference.  I am trying to put an entire Linux/GNU system with an
 > >> application statically linked to libgcj into a 16MB flash memory.
 > >> Adding more code to libgcj does not make it any easier.
 > 
 > > Thanks for that.  I agree; it makes no sense to burden non-SELinux
 > > systems with all this stuff.
 > 
 > There's no way to tell, at compiler build time, whether the target
 > system is going to have some such security measures in effect.  In the
 > patch, I take the approach that, barring separate specification,
 > GNU/Linux systems are assumed to possibly require this more costly
 > approach, with some impact on code size, but that still tries the less
 > costly approach at run time and uses that if it works.

Sure, you can't automagically tell if it'll be needed, but a configure
option will do the trick.

 > If you know the target system is not going to be subject to these
 > constraints, and it is a GNU/Linux system, it suffices to build libffi
 > with -DFFI_MMAP_EXEC_WRIT=0 and we'll use only malloc, with a
 > negligible impact on code size.
 > 
 > That, or patching libffi/src/closures.c, might appease the code-size
 > concerns.  If not, I suppose we could simplify the definition of the
 > macro with a configure-time option for libffi.  I'm not convinced
 > having the configure option would be so much better than say
 > make CPPFLAGS_FOR_TARGET=-DFFI_MMAP_EXEC_WRIT=0 for an option that
 > would already be hidden in libffi, would be of so little use for
 > most people and would make such a little difference even when it does:
 > 
 >     text     data     bss      dec     hex filename
 >    11232        4    1136    12372    3054 libffi/src/closures.o
 > 37921368  9304904  468848 47695120 2d7c510 libjava/.libs/libgcj.so
 > 
 > Sure, every 11KiB counts, and it's easy enough to shave them off.  But
 > does it justify yet another obscure configure option, if you probably
 > already have a number of changes in place to achieve the
 > apparently-impossible goal of fitting this in 16MiB? :-)

You aren't taking into account the embedded gcj users who strip the
library down to what they need.  I'm not such a user, but David Daney
-- the guy who made this request -- is.  I assume he has some idea
what he's talking about.

David, what say you?

Andrew.