Get libffi closures to cope with SELinux execmem/execmod

[Alexandre Oliva]

On Jan 18, 2007, Andrew Haley <aph@redhat.com> wrote:

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

Good point.  Let me summarize the private discussions we've had on
this matter:

- it would have been possible to use a simpler allocator for
  fixed-size objects, and thus require the separation of ffi_closures
  from other data normally carried along with it.  However, this would
  require the closure to carry a pointer to modifyable data, making it
  much easier to corrupt it so as to do something else, defeating at
  least in part the security advantage afforded by the security
  policies.  It would also make allocation less efficient, in that a
  pair of data objects would have to be allocated.

- Storing the closure and the corresponding helper unmodifyable data
  in read-only memory would be much safer in the general case,
  although I ended up keeping a pointer to the modifyable data in the
  read-only data in the libjava side.  But at least that's not a
  choice imposed by libffi.

- Since the data attached to a closure object, at least in the libjava
  case, can grow up to two 2KB, and stop at that only because of
  constraints imposed by the JVM specs, it sounded desirable to use a
  generic memory allocator that could deal with this, even if
  heavily optimized for small objects.

- Modifying boehm-gc so as to support a separate memory space with
  this special mmap magic was considered, but after some investigation
  I didn't get the impression this was feasible without a lot of
  effort, and it didn't seem worth it considering that dlmalloc is a
  well-known memory allocator library, glibc's allocator is based on
  it, I was somewhat familiar with it already, and tweaking it to suit
  our needs proved to be quite simple.
  
> I presume that the allocator is thread-safe.

Yes, given the option I passed to it.

> When a Java object, such as a Class, is being finalized, it is
> reachable.

What I read about boehm-gc's finalization
(boehm-gc/doc/gcdescr.html:Finalization and
http://www.hpl.hp.com/personal/Hans_Boehm/gc/finalization.html) gave
me the impression that this was safe.  The docs said something along
the lines that would run finalizers only when their objects actually
became unreachable, which means it might take multiple collection
cycles for an object with a finalizer to be finalized and discarded if
there's a chain of such objects.  The docs also mentioned that cycles
of such objects wouldn't be discarded.

It would still be possible for such an object to be reconnected in the
finalizer, but our class finalizers don't do this, so I concluded it
was safe.

> Please disable the call to
> _Jv_ClosureList::releaseClosures for the time being,

Given the above, would you still like me to do so?  Can you give me a
hint as to a testcase that might expose this kind of error, such that
I can verify whether the docs and what I'm reading from the code
actually match the behavior I've come to rely upon?

> (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.)

Yes, it would be pretty simple to concat a to-be-disposed list with
the closure list of a class at that point, and dispose of the list at
a later time.  Should I?

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