llvm dev - Sep 2013 - [LLVMdev] Intel Memory Protection Extensions (and types question)

On Tue, Sep 10, 2013 at 1:47 PM, David Chisnall <David.Chisnall at
cl.cam.ac.uk
> wrote:
> On 10 Sep 2013, at 10:28, Kostya Serebryany <kcc at google.com>
wrote:
>
> >
> >
> >
> > On Tue, Sep 10, 2013 at 1:19 PM, David Chisnall <
> David.Chisnall at cl.cam.ac.uk> wrote:
> > On 10 Sep 2013, at 10:13, Kostya Serebryany <kcc at google.com>
wrote:
> >
> > > How did you come with 320 bits?
> > > 320=64*4+64, which is the size of the metadata table entry plus
> pointer size,
> >
> >
> >
> > Sorry, that should have been 192.  The specification allows the
metadata
> to be stored either in look-aside tables or explicitly managed.
> >
> > Is it? Which specification are you referring to?
> >
http://download-software.intel.com/sites/default/files/319433-015.pdf(chapter 9)
doesn't say anything like this. (Or does it?)
>
> See the BNDMOV instruction, which allows the bounds to be explicitly
> loaded and stored to bounds registers.  Contrast with BNDLDX / BNDSTX,
> where the location is implicit.  The BNDMOV instruction is also used for
> stack spills of the bounds registers.  This allows MPX to be used for range
> checking in a similar way to the Thumb-2EE extensions.
>
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.
I don't think we need fat pointers to support MPX in LLVM -- it will
complicate the implementation beyond necessity. (My 2c)
All we need is to represent a 128-bit type that will live in BNDx registers.

--kcc

>
> >>  The pointer and metadata exist in separate registers, but single
> instructions (loads and stores) operate on the pointer + metadata.
> > Which MPX instructions do you mean here?
>
> Ah, sorry, I was confusing MPX with one of the other HardBound-like
> schemes here.  In MPX, you must implicitly insert the BNDCU and BNDCL
> instructions.  I would expect that you'd want to model the BNDCU +
BNDCL +
> MOV sequence as a single pseudo for as long as possible to ensure that the
> bounds checks were performed at the correct time and not elided, but they
> are separate instructions (although if they don't do micro-op fusion on
the
> sequence I'd be shocked, since you can trivially do both bounds checks
in a
> single cycle and speculatively enqueue the memory operation with enough
> time to cancel it if it turned out that the bounds checks should trap).
>
> David
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130910/aaae51ca/attachment.html>

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).
> 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).
> 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

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.

--kcc

>
> > 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>

Hi David,

Dr D. Chisnall [mailto:dc552 at hermes.cam.ac.uk] wrote:
> [...]
> I believe that our case and MPX (which is quite close to HardBounds) are
> close to being opposite end of the spectrum, so it would be nice if we
could
> come up with a generic design that can support both [...]
I'm sure we'd be interested in participating in this discussion,
and migrating MPX support to use any infrastructure that comes out
of it. I personally favor the St Exupery view of engineering elegance
("perfection is finally attained not when there is no longer anything
to add, but when there is no longer anything to take away") and would
support any simplifying unification.

In the short term, though, since MPX has its pointer fat liposuctioned
and stored in ziploc bags, we can manage quite well without new
infrastructure, and our short term goals are
- being able to generate the machine instructions
- supporting the MPX 'standard model' interoperably with gcc and icc
Pragmatically, it seems that this is most likely to be acceptable to
the LLVM community if the impact is essentially zero outside of where
it's absolutely necessary (X86 code generator and optional MPX pass).
> [...]
> See the BNDMOV instruction, which allows the bounds to be explicitly loaded
> and stored to bounds registers.  Contrast with BNDLDX / BNDSTX, where the
> location is implicit.  The BNDMOV instruction is also used for stack spills
> of the bounds registers.  This allows MPX to be used for range checking in
a
> similar way to the Thumb-2EE extensions.
And similar to the x86 BOUND instruction (80186 forward IIRC) with
the need for the ABI to accommodate passing bounds. Although BNDLDX /
BNDSTX / BNDMOV can be used in this fashion in a system with a new ABI,
that will probably happen just about as often as BOUND actually gets
used, and the meat of the MPX model lies in supporting C/C++-oriented
systems transparently to code using the established ABI.
> [...]
> I would expect that you'd want to model the BNDCU + BNDCL + MOV
sequence as a
> single pseudo for as long as possible to ensure that the bounds checks were
> performed at the correct time and not elided
Actually, we'd like to checks and loads/stores to be split and elided
as much as possible, subject to data dependencies determining the
'correct time' - the canonical example being a loop whose range is
dynamically known at the start. Maybe I'm misunderstanding you.
> [...]
> MPX is an implementation of the HardBound concept from UPenn, where this
was
> a design goal (see also their 'low-fat pointers' work).
There has been some interesting discussion on comp.arch relating to
the background of MPX, which (however fascinating I find the history of
capability architectures) I am not willing to join here or elsewhere;
I've only been personally aware of MPX myself for a matter of months,
and besides, the law-talking guys would probably slap me silly.

-- 
Kevin Schoedel, Software Developer, Intel of Canada
<kevin.p.schoedel at intel.com>      +1 (519) 772-2580