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. Thanks, Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120717/55965434/attachment.html>
On 7/17/12 10: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.I don't work on or with the LLVM JIT, but I do work on memory safety, so I think I can comment. First, I suspect that the choice to leave rwx memory lying around is for convenience and performance. Having to toggle page protections takes time as it requires a system call and some TLB flushes/changes, so I am not surprised that the JIT does not do it. There are other designs that might mitigate this (e.g., running the JIT in a separate process from the C code so that each have different MMU mappings of the same physical memory), but these designs may have other performance issues. I'll let someone more familiar with JIT design discuss that. Second, if you're using the JIT to run memory-unsafe programs (such as C programs), having writable and executable memory may not make matters too much worse than they would be otherwise. Return-to-libc and Return Oriented Programming attacks are effective and do not require writable memory. If you're not using some mitigation technique (e.g., SAFECode or a version of control-flow integrity that doesn't depend on non-wx memory), you have no real security. -- John T.> > Thanks, > Josh > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120717/55972aef/attachment.html>
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
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