I'm not sure about the legacy JIT interface, but I don't think this can be done cleanly with the current MCJIT interface. I mentioned a while ago that this is one of the improvements we'd like to make to MCJIT. I can definitely see Josh's point about performance, and so we won't want permissions to always be set, but I do think it's worth revising the interface between the RuntimeDyld component and the memory manager to facilitate setting permissions when that is desired. -Andy -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner Sent: Tuesday, July 17, 2012 10:02 PM To: Josh Haberman Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] rwx pages dangerous? On Jul 17, 2012, at 8:07 PM, Josh Haberman wrote:> I noticed that JITMemoryManager allocates its slabs as rwx. Isn't it a security problem to have memory mapped as both writable and executable? I think JITs often avoid this by mapping their memory as rw, then switching it to rx once the data has been written. I was facing a similar problem in a JIT of my own and was curious to see how LLVM addresses this issue.Hi Josh, You're absolutely right that this can be an issue. The LLVM JIT allows you to implement your own JITMemoryManager policy class, and this policy enables you to implement things like this. -Chris _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
In the world of the MCJIT, memory allocation, including permissioning, is the responsibility of the client application. The MCJIT only directly touches memory in the address space of the host. Once the old JIT is removed, all of the allocations done by the included memory manager can become RW. lli's trivial memory manager will then have the RW->X transition for code sections. All of the interfaces regarding permissions and such are solely for the support of the old JIT. -Jim On Jul 18, 2012, at 12:36 PM, "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote:> I'm not sure about the legacy JIT interface, but I don't think this can be done cleanly with the current MCJIT interface. > > I mentioned a while ago that this is one of the improvements we'd like to make to MCJIT. I can definitely see Josh's point about performance, and so we won't want permissions to always be set, but I do think it's worth revising the interface between the RuntimeDyld component and the memory manager to facilitate setting permissions when that is desired. > > -Andy > > > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner > Sent: Tuesday, July 17, 2012 10:02 PM > To: Josh Haberman > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] rwx pages dangerous? > > > On Jul 17, 2012, at 8:07 PM, Josh Haberman wrote: > >> I noticed that JITMemoryManager allocates its slabs as rwx. Isn't it a security problem to have memory mapped as both writable and executable? I think JITs often avoid this by mapping their memory as rw, then switching it to rx once the data has been written. I was facing a similar problem in a JIT of my own and was curious to see how LLVM addresses this issue. > > Hi Josh, > > You're absolutely right that this can be an issue. The LLVM JIT allows you to implement your own JITMemoryManager policy class, and this policy enables you to implement things like this. > > -Chris > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
The main problem, as I see it, is that there's no way for the memory manager to know when it can safely change the protection state of sections apart from making assumptions about the implementation of MCJIT (namely that it will generate code on construction) and receiving some sort of notification outside the standard interface. I believe there's also no provision for handling read-only data sections. These are minor problems, of course, but I think it's a place where there's room for improvement. -Andy -----Original Message----- From: Jim Grosbach [mailto:grosbach at apple.com] Sent: Wednesday, July 18, 2012 2:22 PM To: Kaylor, Andrew Cc: Chris Lattner; Josh Haberman; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] rwx pages dangerous? In the world of the MCJIT, memory allocation, including permissioning, is the responsibility of the client application. The MCJIT only directly touches memory in the address space of the host. Once the old JIT is removed, all of the allocations done by the included memory manager can become RW. lli's trivial memory manager will then have the RW->X transition for code sections. All of the interfaces regarding permissions and such are solely for the support of the old JIT. -Jim On Jul 18, 2012, at 12:36 PM, "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote:> I'm not sure about the legacy JIT interface, but I don't think this can be done cleanly with the current MCJIT interface. > > I mentioned a while ago that this is one of the improvements we'd like to make to MCJIT. I can definitely see Josh's point about performance, and so we won't want permissions to always be set, but I do think it's worth revising the interface between the RuntimeDyld component and the memory manager to facilitate setting permissions when that is desired. > > -Andy > > > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner > Sent: Tuesday, July 17, 2012 10:02 PM > To: Josh Haberman > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] rwx pages dangerous? > > > On Jul 17, 2012, at 8:07 PM, Josh Haberman wrote: > >> I noticed that JITMemoryManager allocates its slabs as rwx. Isn't it a security problem to have memory mapped as both writable and executable? I think JITs often avoid this by mapping their memory as rw, then switching it to rx once the data has been written. I was facing a similar problem in a JIT of my own and was curious to see how LLVM addresses this issue. > > Hi Josh, > > You're absolutely right that this can be an issue. The LLVM JIT allows you to implement your own JITMemoryManager policy class, and this policy enables you to implement things like this. > > -Chris > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev