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

Jim Grosbach grosbach at apple.com
Wed Nov 14 11:22:07 PST 2012


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] 
> 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/51daf26e/attachment.html>


More information about the llvm-commits mailing list