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

[Chandler Carruth]

Jumping to the relevant bits:

On Tue, Jan 6, 2015 at 3:39 PM, PaX Team <pageexec at gmail.com> wrote:

> > NOP insertion is just a simple start to fine-grained diversity. We've
> > implemented more involved randomizations, such as function/BB
> > shuffling and register allocation randomization, and will be cleaning
> > up and reviewing these techniques if people are interested.
>
> if i were you, i'd have submitted those other methods instead, especially
> those without a performance impact.
>

See below.


>
> > > 2. i'm not sure what combinations you meant but whatever i can think of
> > > (ASLR, NX pages, CFI, etc) are all already strong (or weak) enough on
> their
> > > own, nop insertion doesn't change the cost/benefit equation in any
> significant
> > > way (again i refer to the BROP paper that describes how much it takes
> to
> > > perform the BROP attack).
> >
> > I think the middle spot we're aiming against is attacks which can
> > disclose a pointer and therefore bypass ASLR, but are unable (or
> > unwilling due to difficulty) to disclose or brute-force the entire
> > code segment. The utility of this defense relies not in making all
> > attacks impossible, but in making them significantly harder, just like
> > ASLR.
>
> ok, so this is the closest description so far for the situation where
> your work makes a difference


For reference, this is the same scenario I was imagining.


> and my comment then is to concentrate on
> methods that have no performance impact for practical purposes (i.e.,
> not nop insertion but stuff like randomized register allocation, random
> gaps between functions, basic blocks, stack variables, etc).


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.

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.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150106/5c2e539e/attachment.html>