[llvm-commits] [PATCH for REVIEW] Secure Memory Manager for MCJIT and RuntimeDyld.

[Eric Christopher]

I haven't looked at the whole thing yet, but any reason not to make this
the default (other than it's slightly more complicated)?

-eric


On Tue, Nov 6, 2012 at 8:01 AM, Thirumurthi, Ashok <
ashok.thirumurthi at intel.com> wrote:

>  Currently, RuntimeDyld clients (like MCJIT) cannot restrict the memory
> protection flags for sections that are read-only, RW or RX.  Instead, all
> sections are loaded into RWX memory.  This patch improves the interface of
> RTDyldMemoryManager to allow sections to be allocated as RW and later
> protected as R, RW or RX.  In addition, as RuntimeDyld clients may have
> multiple Modules to load, the interface includes a memory pool ID to pool
> allocations.  This permits RuntimeDyld clients to free a memory pool
> without impacting other loads.  Finally, as RuntimeDyld loads a full
> Module, the RWX attributes of all sections are known prior to the first
> allocation.  As a result, the interface includes the facility to log
> requests for memory.  The goal is to minimize the number of mmap/mprotect
> calls that must be made to load a Module, while also ensuring that no full
> page of memory is wasted.****
>
> ** **
>
> As RTDyldMemoryManager is a base class of JITMemoryManager, this patch
> touches all of the memory managers in the llvm code base.****
>
> ** **
>
> In addition, this patch provides two reference memory managers which can
> be committed separately.  The first, a slightly modified version of
> SectionMemoryManager, is a trivial memory manager that happily ignores the
> call to protectPool. This was previously ripped from lli.cpp and committed
> with tests in unittests/ExecutionEngine/MCJIT.  This memory manager is
> useful for clients that are more interested in efficiency than security.**
> **
>
> ** **
>
> MCJIT and JIT engines allow the client to specify a JITMemoryManager.
> Although this unifies the interface between execution engines, MCJIT
> clients use the methods in the base class RTDyldMemoryManager.
> SectionMemoryManager also provides a convenient implementation of pure
> virtual methods in JITMemoryManager.  In particular, SectionMemoryManager
> is now used by rt-dyld.****
>
> ** **
>
> Alternately, the SecureMemoryManager is a reference memory manager with an
> implementation of protectPool.  This memory manager derives from
> SectionMemoryManager and provides a single class with functionality of
> interest to MCJIT and RuntimeDyld clients.  Specifically, requests with the
> same combination of RWX flags are satisfied by the same allocation.  In
> addition, allocations can be grouped using a pool ID.  The patch includes
> unit tests for all of this functionality.  In addition, this patch modifies
> lli to use the SecureMemoryManager.****
>
> ** **
>
> Looking forwards, options can be provided for lli and rt-dyld to choose
> between secure, fast, and remote memory managers.  In addition, options can
> be provided for MCJIT to determine if protectPool will be called.  Finally,
> MCJIT can be reworked to support multiple Modules.****
>
> ** **
>
> While the patch is large, it has been provided for completeness to support
> reviews at the hackers workshop at llvm-dev.  Reviewers on the list can
> restrict their comments to the interface or the implementation as these can
> easily be performed in two separate commits.  Thanks!****
>
> ** **
>
> **-        **Ashok Thirumurthi****
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20121106/68939cd4/attachment.html>