<div dir="ltr"><div class="gmail_extra">Jumping to the relevant bits:</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 6, 2015 at 3:39 PM, PaX Team <span dir="ltr"><<a href="mailto:pageexec@gmail.com" target="_blank">pageexec@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> NOP insertion is just a simple start to fine-grained diversity. We've<br>
> implemented more involved randomizations, such as function/BB<br>
> shuffling and register allocation randomization, and will be cleaning<br>
> up and reviewing these techniques if people are interested.<br>
<br>
</span>if i were you, i'd have submitted those other methods instead, especially<br>
those without a performance impact.<br></blockquote><div><br></div><div>See below.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> > 2. i'm not sure what combinations you meant but whatever i can think of<br>
> > (ASLR, NX pages, CFI, etc) are all already strong (or weak) enough on their<br>
> > own, nop insertion doesn't change the cost/benefit equation in any significant<br>
> > way (again i refer to the BROP paper that describes how much it takes to<br>
> > perform the BROP attack).<br>
><br>
> I think the middle spot we're aiming against is attacks which can<br>
> disclose a pointer and therefore bypass ASLR, but are unable (or<br>
> unwilling due to difficulty) to disclose or brute-force the entire<br>
> code segment. The utility of this defense relies not in making all<br>
> attacks impossible, but in making them significantly harder, just like<br>
> ASLR.<br>
<br>
</span>ok, so this is the closest description so far for the situation where<br>
your work makes a difference</blockquote><div><br></div><div>For reference, this is the same scenario I was imagining.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> and my comment then is to concentrate on<br>
methods that have no performance impact for practical purposes (i.e.,<br>
not nop insertion but stuff like randomized register allocation, random<br>
gaps between functions, basic blocks, stack variables, etc).</blockquote></div><br></div><div class="gmail_extra">So, while I understand that from a security perspective only these kinds of techniques are really interesting, from the perspective of how LLVM development should proceed, I think it is a really good thing to start off with a naive approach that gets all of the infrastructure into place. And there was a reasonable amount of infrastructure just to get entropy reasonably designed into the code generator at all.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Once this framework is in place, I absolutely agree that there needs to be a focus on lower performance impact strategies next, but for LLVM development we work hard to encourage incremental approaches.</div><div class="gmail_extra"><br></div><div class="gmail_extra">-Chandler</div></div>