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

[JF Bastien]

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:

http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-August/065153.html


I'm still not sure I understand: do you think this mitigation is useless
when combined with other randomization mitigations?

On Mon, Jan 5, 2015 at 8:40 PM, Chandler Carruth <chandlerc at google.com>
wrote:

>
> 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/9e803b24/attachment.html>