<div dir="ltr">On Wed, Aug 28, 2013 at 10:31 PM, John Criswell <span dir="ltr"><<a href="mailto:criswell@illinois.edu" target="_blank">criswell@illinois.edu</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><div><div class="h5">
    <div><span style="color:rgb(34,34,34)">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.</span></div></div></div></div></blockquote><div><br></div><div>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. </div>

<div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div bgcolor="#FFFFFF" text="#000000">
    <br>
    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.<br></div></blockquote><div><br></div><div>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.</div>

<div><br></div><div>Cheers,</div><div>Per</div></div></div></div>