Avoid stack/heap executable memory

Andrew Haley aph@redhat.com
Wed May 4 10:17:00 GMT 2016


On 05/04/2016 12:32 AM, Richard Henderson wrote:
> Of course, this will change the ABI, but I think we can work around that (at 
> least for ELF with symbol versioning), and also preserve the API.  Of course, 
> there's a *lot* that can be cleaned up if we're willing to change the API...

For a long while now I've wanted to go in the opposite direction: to
use a small JIT compiler to generate efficient code for invocations in
both directions.  It doesn't have to be very complicated, and once
you've generated code for any particular set of arguments that shim
can be cached for use by any function with the same argument types.
This could either use an existing JIT library or a custom JIT created
just for libffi.  It would often be way more efficient than what we do
at present.

But it would keep bumping up against the "no executable and writable
memory!" meme.  Of course security is important, but I can't help
thinking that by being rigid about this we're performing a DOS attack
on ourselves.

Andrew.



More information about the Libffi-discuss mailing list