[LLVMdev] rwx pages dangerous?

John Criswell criswell at illinois.edu
Tue Jul 17 21:08:19 PDT 2012


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>


More information about the llvm-dev mailing list