Get libffi closures to cope with SELinux execmem/execmod

Alexandre Oliva aoliva@redhat.com
Fri Jan 26 07:14:00 GMT 2007


On Jan 25, 2007, David Daney <ddaney@avtrex.com> wrote:

> I guess Alexandre should commit the patch.  We are still using GCC
> 3.4.3 for 'production' code, so it does not immediately affect us.  I
> may prepare a patch in the future for a configure option

Sounds like a fair compromise, thanks

> that reduces the code size if there is an executable stack.

Note that this is not just about executable stack, it's about not
turning writable memory into executable memory, so as to remedy a
large class of security exploits.

> Currently for mips[el]-linux the stack is always executable because
> the signal trampolines are on the stack.

If this is so, I guess it doesn't make much sense to enable this
split-map memory allocator for GNU/Linux/mips.  Would you care to let
me know the proper preprocessor magic to recognize the affected
platforms such that I can adjust the default for it in the following
portion of the patch, in libffi/closures.c?

+#ifndef FFI_MMAP_EXEC_WRIT
+# if __gnu_linux__
+/* This macro indicates it may be forbidden to map anonymous memory
+   with both write and execute permission.  Code compiled when this
+   option is defined will attempt to map such pages once, but if it
+   fails, it falls back to creating a temporary file in a writable and
+   executable filesystem and mapping pages from it into separate
+   locations in the virtual memory space, one location writable and
+   another executable.  */
+#  define FFI_MMAP_EXEC_WRIT 1
+# endif
+#endif


Thanks,

-- 
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}



More information about the Java-patches mailing list