[llvm-commits] [PATCH] [Review Request] Memory Support changes to enable setting page protection flags

[Kaylor, Andrew]

ping

From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Kaylor, Andrew
Sent: Friday, August 17, 2012 2:36 PM
To: Commit Messages and Patches for LLVM
Subject: [llvm-commits] [PATCH] [Review Request] Memory Support changes to enable setting page protection flags

Hi everyone,

The attached patch enhances the Support/Memory API to enable explicit setting of memory pages protection flags, both at the time of allocation and afterward.  These changes are in preparation for a future patch to allow MCJIT to protect pages of runtime loaded sections in JITed code.  Currently, MCJIT (like the legacy JIT) puts all code and data into pages that are both writable and executable, which is obviously a bit of a security concern.

This patch was prepared by Ashok Thirumurthi.

One sticky area that I'd like to call out for specific consideration is what the new functions do if the caller attempts to allocate memory or (more likely) set protection flags on existing memory with the MF_WRITE flag set, but not the MF_READ flag.  The specification of mprotect indicates that on some architectures enabling write also enables read, but leaves open the possibility that this is not necessarily so (and I believe some architecture do use this for cache optimization).  Windows, on the other hand, makes no provision for setting write-only permissions.

In an attempt to resolve this conflict while still providing relatively consistent behavior, we have made it so that MF_WRITE gets translated to PAGE_READWRITE on Windows, but in the Unix implementation it is translated to just PROT_WRITE, leaving it up to the OS implementation to determine behavior.  Other possibilities we considered were removing MF_WRITE by itself from the flags presented in the API, and always coercing MF_WRITE to MF_READWRITE.  We rejected both of these options in order to make it possible for users to take advantage of the write-only optimization where they had reason to believe it would be available.

Thanks,
Andy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120828/095ad666/attachment.html>