[Gc] Allocating Executable Memory

BGB cr88192 at hotmail.com
Mon Jul 26 07:37:03 PDT 2010


----- 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>:
>>> On 07/23/2010 07:39 PM, Ivan Maidanski wrote:
>>>> Fri, 23 Jul 2010 13:28:17 -0400 Noah Lavine <noah.b.lavine at gmail.com>:
>>>>>
>>>>> I am writing with a feature request for the next version of your 
>>>>> library.
>>>>>
>>>>> I am working on adding JIT compilation support to GNU Guile (a Scheme
>>>>> implementation), which uses this library for garbage collection. In
>>>>> order to make GC work, we'll need to allocate executable memory.
>
>>>> I like the idea.
>>>> I don't mind adding this feature in this release (probably Hans 
>>>> wouldn't neither since the added coded is small and easily verifiable).
>>>>
>>>> The API should be:
>>>> - GC_set_pages_executable(int) // non-zero means executable
>>>> - GC_get_pages_executable() // returns non-zero if it is allowed to 
>>>> execute code in allocated memory
>>>>
>>>> NO_EXECUTE_PERMISSION controls the initial value only.
>>>>
>>>> If you'd like to add it, I expect you'll provide the patch against the 
>>>> current CVS.
>
>>> 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
>>> root.
>>>
>>> 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 
>> done.
>>
>> 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...).

on systems without this issue, these calls could be no-op.

I guess another option, although more specific to JIT, would be to have a 
specialized linker which manages the executable memory, and itself would 
worry about any such issues (be it mode-changing or multiple mapping).

so, when one wants to submit code, they can do so as a COFF or ELF module 
(or possibly something simpler, like a glob of memory and a 
symbols+relocation table).

in my case, I typically link code via such a linker API, and it is very rare 
that any other code will try to write into the memory.


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

then again, I typically also develop on Windows via MSVC, and it is notable 
in how many ways MS and most OSS people do things differently, ...

or such...



More information about the Gc mailing list