[Gc] Allocating Executable Memory
aph at redhat.com
Mon Jul 26 07:55:58 PDT 2010
On 07/26/2010 03:37 PM, BGB wrote:
> ----- Original Message ----- From: "Andrew Haley" <aph at redhat.com>
> To: <gc at linux.hpl.hp.com>
> Sent: Monday, July 26, 2010 6:29 AM
> Subject: Re: [Gc] Allocating Executable Memory
>> On 07/24/2010 11:04 AM, Ivan Maidanski wrote:
>>> Sat, 24 Jul 2010 09:50:38 +0100 Andrew Haley <aph at redhat.com>:
>>>> I think you'll find this problematic in practice, at least on
>>>> GNU/Linux. Some distributions forbid the allocation of memory that is
>>>> mapped writable and executable, and I think the number of such
>>>> distributions will increase over time. On such systems Java is marked
>>>> with a special file attribute, and that attribute is writeable only by
>>>> The way around this is supposed to be to map pages twice, with
>>>> writable and executable permissions.
>>> Okey. Another patch is needed which adjust the method how mmaping is
>>> If I understand correctly, we just need to duplicate all relevant
>>> mmap and munmap calls (RW + E), right?
>>> If yes, we also need some config option to enable this feature
>>> (otherwise retain old behavior).
>> Unfortunately, it's harder than that. On such systems, the only way
>> to solve the problem is to map each page twice, at different
>> addresses. As far as I know, the only way to do that is to use mmap()
>> on a named file on some device.
>> In practice the easiest way to do this is to map the pages
>> independently of the gc and use finalizers to recycle pages once
>> they're no longer reachable.
> how about mode changing?...
> like, a call is used to mark the memory object writable, and another to
> mark it executable? (via mprotect or similar...).
That works too. It's kinda hard if some other thread is executing
that page, though.
> admittedly, I don't really know why distros would make this restriction,
> as personally it seems restrictive and ill-concieved (and liable to
> break many otherwise functional apps).
Surprisingly, it breaks very few apps, because very few apps ever need
to do this sort of thing. However, it prevents the use of one of the
most common techniques used by security exploits.
> one could almost just ignore the issue and make the app break on
> these targets, as a sort of protest against this "feature" (users
> have to patch themselves, and one can refuse to accept patches to
> "fix" this feature as a matter of project policy), and if the apps
> become popular, then it puts pressure on them to forsake such a
Yes, it is a pain, and I accept your point in general.
More information about the Gc