llvm dev - Jan 2016 - Intel MPX support (instrumentation pass similar to gcc's Pointer Checker)

> First, is MPX hardware available now?  I wouldn't mind getting my hands
on
> one.
It is available at least in the mobile versions of the recent Intel
Skylake CPUs. I am currently playing with Alienware 15 R2 with the
following CPU: Intel(R) Core(TM) i7-6820HK. Interestingly, my
preliminary experiments indicate that adding MPX bounds checking via
Pointer Checker in gcc is usually slower than using software-only
AddressSanitizer.

Thanks for the other pointers!

-- 
Yours sincerely,
Dmitrii Kuvaiskii

On 28 Jan 2016, at 17:03, Dmitrii Kuvaiskii via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Interestingly, my
> preliminary experiments indicate that adding MPX bounds checking via
> Pointer Checker in gcc is usually slower than using software-only
> AddressSanitizer.
This corresponds with other results that I have seen.  The last time I looked at
the output from gcc, it also did not generate pointer updates that were safe in
the presence of concurrency (they must be bracketed in transactions if you want
the MPX metadata and the pointer updates to be atomic) and the overhead of this
is likely to be even more.

I am particularly impressed with Intel for creating a hardware implementation
that is both slower than a software-only version and can not (due to its
fail-open policy being embedded in the hardware) be used for security.

David

I've recently played with the GCC implementation of pointer checker on a
real hardware,
my recent impressions are here:
https://github.com/google/sanitizers/wiki/AddressSanitizerIntelMemoryProtectionExtensions

(there is also some old pre-hardware content).

In short, I totally agree with what David says above: MPX is a disaster.
(Usual disclaimer: my opinion here is too biased)

I am glad that LLVM already has the support for MPX instructions, but I see
no good reason to add the MPX-based checker to LLVM.
Yes, it will allow us to detect intra-object overflows, something that asan can
not do by default
<https://github.com/google/sanitizers/wiki/AddressSanitizerIntraObjectOverflow>,
but it's not worth the extreme complexity of the MPX-based checker.

--kcc

On Thu, Jan 28, 2016 at 9:14 AM, David Chisnall via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 28 Jan 2016, at 17:03, Dmitrii Kuvaiskii via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > Interestingly, my
> > preliminary experiments indicate that adding MPX bounds checking via
> > Pointer Checker in gcc is usually slower than using software-only
> > AddressSanitizer.
>
> This corresponds with other results that I have seen.  The last time I
> looked at the output from gcc, it also did not generate pointer updates
> that were safe in the presence of concurrency (they must be bracketed in
> transactions if you want the MPX metadata and the pointer updates to be
> atomic) and the overhead of this is likely to be even more.
>
> I am particularly impressed with Intel for creating a hardware
> implementation that is both slower than a software-only version and can not
> (due to its fail-open policy being embedded in the hardware) be used for
> security.
>
> David
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160128/9fc58fb6/attachment.html>