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

Hello,

As far as I know, there is no MPX pass in LLVM (though the x86-64
backend already declares MPX registers and instructions). I wonder if
anyone is currently working on the LLVM pass for MPX instrumentation,
similar to Pointer Checker in gcc. If yes, could anyone elaborate on
the status and accessability to other researchers? And if any help is
needed?

Prof. Santosh Nagarakatte, the author of SoftBound/HardBound/WatchDog
Lite, answered that he is not currently
involved in MPX. But he pointed to the SoftBoundCETS prototype at
https://github.com/santoshn/softboundcets-34 . Therefore, I was
thinking about adapting SoftBound to MPX, as a drop-in replacement for
gcc's PointerChecker. Could anyone comment on this?

-- 
Yours sincerely,
Dmitrii Kuvaiskii

On 1/28/16 9:35 AM, Dmitrii Kuvaiskii via llvm-dev
wrote:
> Hello,
>
> As far as I know, there is no MPX pass in LLVM (though the x86-64
> backend already declares MPX registers and instructions). I wonder if
> anyone is currently working on the LLVM pass for MPX instrumentation,
> similar to Pointer Checker in gcc. If yes, could anyone elaborate on
> the status and accessability to other researchers? And if any help is
> needed?
>
> Prof. Santosh Nagarakatte, the author of SoftBound/HardBound/WatchDog
> Lite, answered that he is not currently
> involved in MPX. But he pointed to the SoftBoundCETS prototype at
> https://github.com/santoshn/softboundcets-34 . Therefore, I was
> thinking about adapting SoftBound to MPX, as a drop-in replacement for
> gcc's PointerChecker. Could anyone comment on this?
First, is MPX hardware available now?  I wouldn't mind getting my hands 
on one.

Second, I think you should have a solid understanding of the different 
memory safety approaches (namely, the tradeoffs between referent 
approaches vs. approaches that extend the pointer representation (called 
fat pointer approaches)).  In short, fat pointers provide stronger 
security guarantees but introduce compatibility problems with 
third-party code (even if they don't change the size or representation 
of the pointer).  Referent object approaches can be made more compatible 
but have looser memory safety semantics.

I believe the MPX hardware was designed to implement fat pointer 
approaches, but you can probably do referent approaches or even some 
hybrid of the two.  It is not clear to me what the "best" approach is,
and "best" probably depends on what you are trying to accomplish and 
what assumptions you make about which parts of the system you are 
willing to recompile with the memory safety checks.

I recommend reading up on the different memory safety approaches. The 
Memory Safety Menagerie (http://sva.cs.illinois.edu/menagerie) provides 
some sources though I have let it fall a little out of date.

Third, I think using either the SoftBound and/or SAFECode source bases 
is a good place to start.  SoftBound is probably the best starting place 
since it probably fits the MPX hardware better, but you might find 
useful stuff in the SAFECode source base as well.

If you have more specific questions about the project as you go, please 
feel free to ask.  I've done a little work on memory safety 
(http://llvm.org/pubs/2007-SOSP-SVA.pdf).

Regards,

John Criswell

-- 
John Criswell
Assistant Professor
Department of Computer Science, University of Rochester
http://www.cs.rochester.edu/u/criswell

> 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