This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Get libffi closures to cope with SELinux execmem/execmod
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.