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

[Kostya Serebryany via llvm-dev]

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>