search for: vm_protect

Hi, Can anyone tell me something about mmap and vm_protect on ARM+Apple systems? I'm working on a new memory manager implementation for MCJIT and I want to replace calls to Memory::AllocateRWX with calls to Memory::allocateMappedMemory, possibly still with the RWX flags. However, looking at the Memory::AllocateRWX implementation I see that it's j...

Hi Andy, On Nov 16, 2012, at 1:56 PM, "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote: > Hi, > > Can anyone tell me something about mmap and vm_protect on ARM+Apple systems? Some. :) > > I’m working on a new memory manager implementation for MCJIT and I want to replace calls to Memory::AllocateRWX with calls to Memory::allocateMappedMemory, possibly still with the RWX flags. However, looking at the Memory::AllocateRWX implementation I s...

...ot;ARM Darwin can't do this. Memory is never allowed to be both writable and executable at the same time." That seems very sensible. So do the JIT engines just not work there now? Currently both MCJIT and JIT are using AllocateRWX which on that platform mmap's the memory as RX, then vm_protect's it as RX+VM_PROT_COPY, then vm_protect's it as RW. My best guess is that this is trying to set up something that's actually backed by two pages where whatever is written to the RW page will be copied to the RX page, though if that's possible it would seem to defeat the purpose of...

...ines just not work there now? They work by allocating RW memory, then switching the permissions to RX before running any code stored there. That requires special process permissions. > > Currently both MCJIT and JIT are using AllocateRWX which on that platform mmap’s the memory as RX, then vm_protect’s it as RX+VM_PROT_COPY, then vm_protect’s it as RW. > > My best guess is that this is trying to set up something that’s actually backed by two pages where whatever is written to the RW page will be copied to the RX page, though if that’s possible it would seem to defeat the purpose of not...

On 17 Nov 2012, at 00:12, Kaylor, Andrew wrote: > My best guess is that this is trying to set up something that’s actually backed by two pages where whatever is written to the RW page will be copied to the RX page, though if that’s possible it would seem to defeat the purpose of not allowing RWX. The correct way of implementing this is to have one physical page mapped to two locations in

On 27 Nov 2012, at 01:20, Jim Grosbach wrote: > They work by allocating RW memory, then switching the permissions to RX before running any code stored there. That requires special process permissions. Is this really required? The canonical way of getting around this restriction is to mmap the same physical page as RW in one location and RX in another. I've not tested this on ARM/Darwin,

...e The installer log looks like: Nov 17 21:32:39 brad-prices-macbook /System/Library/CoreServices/Installer.app/Contents/MacOS/Installer[1503]: vm_allocate: 0, 0x5800000 - 0x25800000 Nov 17 21:32:39 brad-prices-macbook /System/Library/CoreServices/Installer.app/Contents/MacOS/Installer[1503]: vm_protect: 0 Nov 17 21:32:39 brad-prices-macbook Installer[1503]: @(#)PROGRAM:Install PROJECT:Install-388 Nov 17 21:32:39 brad-prices-macbook Installer[1503]: @(#)PROGRAM:Installer PROJECT:Installer-281 Nov 17 21:32:39 brad-prices-macbook Installer[1503]: Hardware: MacBook3,1 @ 2.20 GHz (x 2), 2048 MB R...