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

[Alexandre Oliva <aoliva at redhat dot com>]

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.

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? :-)

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}