[LLVMdev] Adding diversity for security (and testing)

[Per Larsen]

On Wed, Aug 28, 2013 at 10:31 PM, John Criswell <criswell at illinois.edu>wrote:

>  Is there a reason why your security guy thinks that diversity is a
> better protection than control-flow integrity (CFI)?  Recent work on CFI
> [1] indicates that even very conservative call graphs remove nearly all
> gadgets from the list of valid function targets (hence they cannot be
> used).  That implementation has an average overhead of 3.6% and a max
> overhead of 8.6%.  A more flexible implementation [2] that already works
> for LLVM has average overhead of 10%.  There's more recent work on CFI
> (including at least one paper that uses LLVM) published this month at
> Usenix Security, but I haven't had time to read it yet.
>

I agree that CFI is a very interesting technique and the fact that the
Usenix best paper award went to a paper on CFI (via binary rewriting
however) just underscores this view. My colleague, Stephen, posted a link
to a paper on our LLVM implementation of diversity which uses the profile
guidance infrastructure to lower the overheads of diversification below the
numbers you cite for CFI-on Spec2006, we report an average overhead of 1%
and a max. overhead of 2.5%. I think this difference matters a lot given
that single core performance is improving much more slowly now and power
consumption matters a lot in mobile. So while both techniques offers good
security, profile guided diversity seems to have an edge w.r.t. efficiency.

I should point out that the initial patch set we are suggesting to upstream
does not use profile guidance; we'd simply like to start out small.


> I think diversity is a nice thing to have to provide defense in depth, but
> I currently think that CFI will provide the most bang for the buck.
>

I'm glad you see the value in diversity. I think these are ultimately
complimentary techniques. If a developer don't mind the higher overhead
from CFI and/or need to continue distributing a single binary to all
end-users, then CFI should be offered, in the opposite case, LLVM should be
able to diversify. Finally, we think schedule-randomization helps tease out
bugs in the compiler and novel micro-architectures.

Cheers,
Per
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130829/6f3d8de8/attachment.html>