[PATCH] Insert random noops to increase security against ROP attacks (llvm)

Chandler Carruth chandlerc at google.com
Mon Jan 5 20:40:48 PST 2015


On Mon, Jan 5, 2015 at 8:27 PM, PaX Team <pageexec at gmail.com> wrote:

> what i question is whether this 'harder' property exists
> at all, and even if it does, in what situation it holds exactly.
>

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.

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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150105/05323bb3/attachment.html>


More information about the llvm-commits mailing list