[cfe-dev] GCC's -fmpx in clang?

[Kostya Serebryany]

On Sun, Sep 14, 2014 at 2:07 AM, Szabolcs Nagy <nsz at port70.net> wrote:

> * Reid Kleckner <rnk at google.com> [2014-09-13 18:37:57 -0700]:
> > Not that I know of. So far as I know, ASan is superior to any MIX based
> > instrumentation. The only class of false negatives I know of is arrays in
> > structs, which there are plans for.
> >
>
> mpx is new to me, but looking at the docs it solves a different
> problem than asan
>
> asan must not be used in production code, it's not a hardening
> solution, but a debugging one


We prefer to say "asan is for testing" instead of "for debugging".
You are right, asan is not a way to protect your code from attackers in
production.
There is NaCl for that.


> (it actually increases the attack
> surface by all its instrumentations, its own set of reliance on
> ub and strong interdependency on libc internals)
>


>
> mpx is for hardening deployed code with bounds check instructions
>

[Note: I have a very biased opinion on MPX...]
Here is my impression from MPX (last updated 10 months ago)
https://code.google.com/p/address-sanitizer/wiki/IntelMemoryProtectionExtensions

"mpx is for hardening deployed code" is an overstatement imho.
MPX is going to incur a huge memory cost for most of the programs.
And until I see the numbers on the real hardware I am also unconvinced that
MPX will be fast enough "for hardening deployed code".

Unless you instrument *all* the code with MPX, this is a very lousy
sandbox.
And even then, it doesn't protect you from heap-use-after-free and
stack-use-after-return.

As Reid mentioned, MPX is good for detecting intra-object buffer overflows,
which today's asan can't make.
We have a plan for attack, but MPX's approach is still better for this
particular class of bugs,
so I want to see MPX in LLVM, but I am not ready to invest much time in it
(including doing the code reviews).
Another problem is that implementing MPX in a compiler is a major disruption
(see how long it takes to add MPX support in GCC, and it's not there yet
after more than a year of work).

--kcc




> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140915/6ff8cb61/attachment.html>