#885: GHC doesn't work with Data Execution Prevention on Windows
-----------------------+----------------------------------------------------
Reporter: guest | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 6.6.1
Component: Compiler | Version: 6.4.2
Severity: major | Resolution:
Keywords: | Os: Windows
Difficulty: Unknown | Architecture: x86
-----------------------+----------------------------------------------------
Comment (by briansmith):
My interpretation of the DEP failuers and the MS documentation regarding
VirtualProtect was wrong. I will attach a C program that verifies that it
is indeed possible to go from PAGE_READWRITE -> PAGE_EXECUTe[_READWRITE]
via VirtualProtect--the memory does not have to be initially allocated
using PAGE_EXECUTE[_READWRITE] as the docs say.
I will attach a patch for ByteCodeFFI that resolves the other cause of DEP
violations that I could find. But, although I changed the call from
newArray to allocateExec, I cannot figure if I should be calling freeExec
somewhere, and if so, where?
I propose that the allocateExec API be modified, so that allocateExec
returns non-executable memory; that is, it does not call setExecutable.
Callers would then work the following way:
{{{ x = allocateExec(n);
/* write code to memory here */
setExecutable(x);
}}} The benefit is that setExecutable could then change the page from
PAGE_READWRITE to PAGE_EXECUTE, removing PAGE_READWRITE. That is, memory
should either be writable or executable but not both at the same time.
This would require that every stub be written on a seperate page of
memory, but I think that is not so bad because the number of stubs is
almost always very, very small. What do you think?
The linker is the only place that needs to allocate a block of executable
memory larger than what allocateExec can handle, and the only place that
would need to have PAGE_EXECUTE_READWRITE. All uses outside the linker of
allocateExec are for very small pieces of memory. Having the linker call
VirtualAlloc directly here is much easier change (for me) than modifying
allocateExec to allow it to allocate large blocks--somebody else would
have to do that.
Please let me know what you want to do.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/885>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
