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

[Michael Spencer]

On Fri, Aug 17, 2012 at 2:35 PM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote:
> 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
>
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>

Looks fine except for using std::string for error handling. Please use
error_code, as most of the errors you are handling are already in
there.

- Michael Spencer