search for: mpx

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

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

On Thu, Feb 4, 2016 at 4:59 AM, Dmitrii Kuvaiskii < Dmitrii.Kuvaiskii at tu-dresden.de> wrote: > >> Recently I played with MPX support on Intel C/C++ Compiler (icc). This > >> implementation looks *much* better, with the following example > >> overheads: 1.2X on "raytrace", 1.25X on "bodytrack", 1.08X on > >> "streamcluster". So the common overheads are in the range...

On Wed, Feb 3, 2016 at 6:27 AM, Dmitrii Kuvaiskii < Dmitrii.Kuvaiskii at tu-dresden.de> wrote: > I continue playing with Intel MPX and its support in modern compilers. > All experiments were done on the Alienware (Dell) 15 R2, Ubuntu 15.10 > (linux 4.2.0), gcc version is 5.2.1, icc version 2016.1.150. The > benchmark suite is PARSEC 3.0, all versions with 1 thread and default > configs. > > As I described pre...

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

Hello, even though the study of Intel MPX took much longer than expected, we have finally finished it. Currently, it is published in two formats: * as a technical report: https://arxiv.org/abs/1702.00719 * and as a webpage: https://intel-mpx.github.io/ This work contains evaluation of MPX from perspectives of performance (Phoenix, PA...

...op of whatever overhead SafeStack has. > Do you have any measurements to share? > Here are estimated SPECint_base2006 component runtimes for some relevant test configurations: Runtime in seconds: +--------------+---------+---------+---------+-------+ |Benchmark|Unpatched|Unpatched|Patched|MPX| ||Base|SafeStack|SafeStack|| +--------------+---------+---------+---------+-------+ |400.perlbench |430.82|443.07|442.42|456.34 | +--------------+---------+---------+---------+-------+ |401.bzip2|711.43|716.59|717.35|750.06 | +--------------+---------+---------+---------+-------+ |403.gcc|3...

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

Dmitrii, all, Please note, that GCC 5.3 had a significant update to the MPX code quality - please, use this version as reference. Regards, Sergos On Tue, Feb 9, 2016 at 12:49 AM, Kostya Serebryany via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Thu, Feb 4, 2016 at 10:40 AM, Kostya Serebryany <kcc at google.com> wrote: > >> >&g...

Hi Kevin, Can you explain what kind of abstraction/support do you plan to implement over the MP instructions ? I imagine that you plan to add a few intrinsics, right ? I imagine that you don’t need the register allocator to allocate the BND registers or anything fancy like that. In that case the registers can be an immediate in the intrinsic. Maybe you can start by presenting the kind of

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

Hi, On Monday, September 09, 2013 4:20 PM, Nadav Rotem [mailto:nrotem at apple.com] wrote: > Thanks for working on this. We usually try really hard to avoid adding new > types such as x86mmx. I don't know the memory-protection instruction set at > all but I imagine that you are not expecting other LLVM optimizations to > interact with them right ? (it looks that way from this

...like this. (Or does it?) > The tables impose a very large storage space penalty, so are most likely > to be used with C or similar language where it is difficult to modify the > data layout. For languages where there is no requirement to maintain an > ABI that interoperates with non-MPX code, the metadata can be stored inline > when running in bounds-checked mode. I forgot that when using it in this > mode you needed to store less metadata than when using the bound tables. > > > but why do you call this a fat pointer? > > Because that's what it is: a poin...

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

From 291adaf4ad6174c5641a7239c1801373e92e9975 Mon Sep 17 00:00:00 2001 From: Liu Jinsong <jinsong.liu@intel.com> Date: Thu, 28 Nov 2013 05:26:06 +0800 Subject: [PATCH v4 3/7] X86: MPX IA32_BNDCFGS msr handle When MPX supported, a new guest-state field for IA32_BNDCFGS is added to the VMCS. In addition, two new controls are added: - a VM-exit control called "clear BNDCFGS" - a VM-entry control called "load BNDCFGS." VM exits always save IA32_BNDCFGS into BN...

...to determine whether the compiler (or more specifically, the SafeStack pass) intends that they be allowed to access the safe stack. It then inserts segment override prefixes and related instructions as necessary. I submitted patches today to implement an analogous idea in 64-bit mode using Intel MPX. MPX can be used both to enforce fine-grained per-object bounds and coarse-grained bounds. My patches use it for the latter purpose, so they make no use of the table-related instructions in MPX. The runtime library [1] simply initializes one bounds register, BND0, to have an upper bound that is...

I am a newcomer to Centos and could benefit from some help. I am repurposing an older server and installed Centos 6.7 on a Tyan Tiger MPX 2466 motherboard. The installation went flawlessly but the graphics chip on the motherboard is obviously quite old, a Matrix Millennium MGA 2064W, and the slow default driver (VESA?) was installed. Is a faster video driver available? It would be nice to be able to run the desktop more smoothly......

...cam.ac.uk > wrote: > Hi Kevin, > > We're also interested in support for fat pointers in LLVM/clang and it > would be nice to have some general infrastructure for them (we currently > have a load of hacks). There are a lot of research architectures with fat > pointers, and MPX is likely to be just the first of many to start hitting > real silicon soon. There are a few properties that we'd ideally want to > represent in the IR and back ends: > > - Pointers are now not solely integers, they contain other metadata > - Fat and thin pointers may coexist in...

...er in look-aside tables or explicitly managed. The tables impose a very large storage space penalty, so are most likely to be used with C or similar language where it is difficult to modify the data layout. For languages where there is no requirement to maintain an ABI that interoperates with non-MPX code, the metadata can be stored inline when running in bounds-checked mode. I forgot that when using it in this mode you needed to store less metadata than when using the bound tables. > but why do you call this a fat pointer? Because that's what it is: a pointer + metadata > In MP...

Hi Kevin, We're also interested in support for fat pointers in LLVM/clang and it would be nice to have some general infrastructure for them (we currently have a load of hacks). There are a lot of research architectures with fat pointers, and MPX is likely to be just the first of many to start hitting real silicon soon. There are a few properties that we'd ideally want to represent in the IR and back ends: - Pointers are now not solely integers, they contain other metadata - Fat and thin pointers may coexist in the same program and ha...