[LLVMdev] Intel Memory Protection Extensions (and types question)

Kostya Serebryany kcc at google.com
Tue Sep 10 05:53:26 PDT 2013

On Tue, Sep 10, 2013 at 5:29 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk
> wrote:

> On 10 Sep 2013, at 12:13, Kostya Serebryany <kcc at google.com> wrote:
> > Well, ok, you can treat this as a 192-bit fat pointer, but AFAICT this
> is not the real intention of the MPX developers
> > since a fat pointer will break all ABIs, and MPX tries to preserve them.
> MPX is an implementation of the HardBound concept from UPenn, where this
> was a design goal (see also their 'low-fat pointers' work).

This one? http://acg.cis.upenn.edu/papers/asplos08_hardbound.pdf
I didn't know.

> > I don't think we need fat pointers to support MPX in LLVM -- it will
> complicate the implementation beyond necessity. (My 2c)
> Fat pointers, however, are required for other architectures (including
> ours) and it would be nice to use the same general representation for all
> implementations of bounds-checked pointers (whether you call them fat
> pointers or not).

It may be nice to have fat pointers, but this is unrelated to MPX as an
instruction set extension.
Consider, for example, possible uses of MPX not directly related to bound
checking: e.g. implementing a software sandbox.
In this case you need intrinsics to get/set BNDx registers and to call
BNDCU/BNDCL, but you don't need fat pointers at all.


> > All we need is to represent a 128-bit type that will live in BNDx
> registers.
> Only if you want to push all of the work into the front end.
> David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130910/c5dbfe48/attachment.html>

More information about the llvm-dev mailing list