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

[Eric Christopher]

Good with me.

-eric


On Wed, Nov 14, 2012 at 11:22 AM, Jim Grosbach <grosbach at apple.com> wrote:

> Hi Ashok,
>
> My understanding from the hacker session at the dev conference is that
> everyone is generally on board with this direction and it's mainly a matter
> of splitting up the patch a bit to help foster discussion about the
> different parts of it. Wanted to go ahead and respond to this email,
> though, and make sure that matches everyone else's take on things, too.
> Sound right to you guys?
>
> -Jim
>
> On Nov 7, 2012, at 7:02 PM, "Thirumurthi, Ashok" <
> ashok.thirumurthi at intel.com> wrote:
>
> Well, there are a few ways to interpret your question.  This patch makes
> SecureMemoryManager the default in lli, and I should probably follow suit
> in rt-dyld.  For MCJIT, there is no default.  That forces users to pick a
> memory manager and think about whether security is worth the premium.  For
> instance, lldb expression evaluation is a case where security might not
> figure over speed.****
>
> MCJIT could also have a secure default if a memory manager wasn’t supplied:
> ****
> ExecutionEngine *MCJIT::createJIT(Module *M,****
>                                   std::string *ErrorStr,****
>                                   JITMemoryManager *JMM,****
>                                   bool GVsWithCode,****
>                                   TargetMachine *TM) {****
>   sys::DynamicLibrary::LoadLibraryPermanently(0, NULL);****
>
>   return new MCJIT(M, TM, JMM, GVsWithCode);****
> ->****
>   return new MCJIT(M, TM, JMM ? JMM : CreateDefaultMemManager(),
> GVsWithCode);****
> }****
>
> -        Ashok****
>
> *From:* Eric Christopher [mailto:echristo at gmail.com <echristo at gmail.com>]
> *Sent:* Tuesday, November 06, 2012 6:53 PM
> *To:* Thirumurthi, Ashok
> *Cc:* llvm-commits at cs.uiuc.edu; Jim Grosbach
> *Subject:* Re: [llvm-commits] [PATCH for REVIEW] Secure Memory Manager
> for MCJIT and RuntimeDyld.****
> ** **
> 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/20121114/79353e24/attachment.html>