<div dir="ltr">I completely agree with Chandler. To go further, I think you're missing the other randomization mitigations that the UCI folks want to implement afterwards. Nop insertion was the first they tackled because it seemed easier than randomizing register allocation. We had a pretty good discussion on this topic on the mailing list a while back:<blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-August/065153.html">http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-August/065153.html</a></div></blockquote><br><div>I'm still not sure I understand: do you think this mitigation is useless when combined with other randomization mitigations?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 5, 2015 at 8:40 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span class=""><br><div class="gmail_quote">On Mon, Jan 5, 2015 at 8:27 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"><div style="overflow:hidden">what i question is whether this 'harder' property exists<br>
at all, and even if it does, in what situation it holds exactly.</div></blockquote></div><br></span>You have already stated at least one circumstance where it exists: where things are not restartable (above some limit) or where the other requirements of BROP aren't satisfied.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I don't understand why we shouldn't add a nice, working mitigation strategy that at least some security folks have found value in to the set of tools available with the compiler. We're not talking about a massive and/or invasive pile of code that will be a terrible burden to maintain over time. I also don't see why we should reject this form of diversified binary production because there might some day be a contribution of a better strategy. That sounds like perfection being the enemy of the good here.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Again, we are a tools vendor. We don't need to refuse to support some security technique merely because it has weaknesses or limits on its utility. Provided the utility is not zero (and empirically it isn't as some have invested quite some time in producing it, so they see non-zero utility), it doesn't seem unreasonable to accept this kind of code.</div><div class="gmail_extra"><br></div><div class="gmail_extra">You might argue that it would be a burden for us (the LLVM developers) to maintain and support the code that out strips the utility it provides, but there are a few LLVM contributors who have worked to support this code already, so that seems unlikely to be a concern.</div></div>
</blockquote></div><br></div>