[LLVMdev] -fbounds-checking vs {SAFECode,ASan}

[John Criswell]

On 5/24/12 5:41 AM, Duncan Sands wrote:
> Hi Kostya, I'm also curious to know where Nuno is going with this, and the
> details of his design.  I'm worried he might be reinventing the wheel.  I'm
> also worried that he may be inventing a square wheel :)

I believe Nuno's goal is to prevent run-time exploitation of software.  
Nuno, please correct me if I'm wrong.

And with all due respect to Nuno, I think he's reinventing the wheel.  I 
implemented what he described using SAFECode in an evening by writing 
two specialized passes that are needed to adjust SAFECode's 
instrumentation to what Nuno needs (one pass removes checks that are too 
expensive; the other inlines the fast checks to remove function call 
overhead).  That code can still be found at 
http://sva.cs.illinois.edu/fastsc-llvm.tar.gz.

I wrote a proposal for a common memory safety instrumentation 
infrastructure and sent it to llvm-commits.  Would it be useful to send 
it to llvmdev as well for discussion, or has everyone who's already 
interested seen it?

Having said all this, if exploit mitigation is the goal, I think it 
might be worth taking a step back and first determining *which* safety 
properties one wants to enforce and what the expected overheads might 
be.  IMHO, if I wanted a technique that could provide the most security 
for the least code complexity and least run-time overhead, I would 
implement control-flow integrity (CFI).  As far as I understand, nearly 
all memory safety exploitation today is done by diverting 
control-flow(*); CFI prevents that and is faster than any other 
non-probabilistic mitigation in the literature.

There's a paper on CFI by Abadi et. al. 
(http://dl.acm.org/citation.cfm?id=1609956.1609960).  However, I don't 
think we'd want to implement it in the same way they do; I'd recommend 
run-time checks on indirect function calls and a split-stack approach 
that allows checks on stores to just mask off bits in the pointer 
address to prevent them from overwriting the return address on the stack.

As an aside, I have a web site called the Memory Safety Menagerie 
(http://sva.cs.illinois.edu/menagerie/index.html) that lists papers on 
the topic of memory safety attack mitigation.  Those interested in 
exploring the mitigation options might find it useful.

-- John T.

(*) Attacks that only change data-flow are possible and practical, but I 
think these are a minority of attacks in the wild.  Attacks that divert 
control-flow are not only common, but researchers have now built tools 
to automate the creation of such attacks.