This is the mail archive of the
libffi-discuss@sourceware.org
mailing list for the libffi project.
Re: Avoid stack/heap executable memory
- From: Andrew Haley <aph at redhat dot com>
- To: Richard Henderson <rth at redhat dot com>, libffi-discuss at sourceware dot org
- Date: Wed, 4 May 2016 11:17:40 +0100
- Subject: Re: Avoid stack/heap executable memory
- Authentication-results: sourceware.org; auth=none
- References: <1462310910 dot 16919 dot 2 dot camel at gmail dot com> <84bfffeb-8172-85fd-6631-d2199eb21d94 at redhat dot com>
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.