<div dir="ltr"><div class="gmail_extra"><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 id=":6lf" class="a3s" 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>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>