Get libffi closures to cope with SELinux execmem/execmod

[Andrew Haley]

Alexandre Oliva writes:
 > This is a patch that fixes the bug described at 
 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=202209
 > 
 > The problem is that SELinux security policies are often configured to
 > prevent pages from being mapped as both writable and executable, and
 > even to stop pages that were ever modified from being turned
 > executable.
 > 
 > The recommended way to implement dynamically-generated code is to map
 > pages from a file in an executable filesystem into separate locations
 > in the virtual memory, one writable, one executable.
 > http://people.redhat.com/drepper/selinux-mem.html
 > 
 > This is what I've done in libffi, if mmap fails to allocate anonymous
 > pages that are both writable and executable on GNU/Linux systems.
 > Various changes were need to enable closures to be created at one
 > address that would later be executed at another.
 > 
 > libjava needed changes to cope with these interface changes in libffi,
 > and manual memory management of closures.  Since they were not scanned
 > by the garbage collector, it turned out to be relatively simple to
 > make the change and arrange for class finalizers to deallocate them.
 > 
 > The first patch below adds dlmalloc.c to libffi as downloaded from
 > Doug Lea's web page (except for CRLF->LF conversion).  The second
 > patch does the rest of the work, including the minimal changes needed
 > for dlmalloc.c to support this custom separate-mapping behavior.
 > 
 > Tested on x86_64-linux-gnu.  Ok to install?

A few thoughts.  Firstly, including the entire malloc library seems
heavyweight.  I presume you've explored other solutions, but a word or
two here of explanation for the record would be good.  People will
ask.

I presume that the allocator is thread-safe.

When a Java object, such as a Class, is being finalized, it is
reachable.  So, disposing of the closures at this point is potentially
dangerous.  Please disable the call to
_Jv_ClosureList::releaseClosures for the time being, and we'll
investigate ways to defer the release until the class in unreachable.
I know this will cause a small memory leak, but we'll live with that
for the time being.  (One idea I have is to mark the closures as dead,
and then have a separate loop that reclaims them after all finalizers
have run.)

Andrew.