similar to: Intel MPX support (instrumentation pass similar to gcc's Pointer Checker)

Displaying 20 results from an estimated 600 matches similar to: "Intel MPX support (instrumentation pass similar to gcc's Pointer Checker)"

2016 Feb 09
2
Intel MPX support (instrumentation pass similar to gcc's Pointer Checker)
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: > >> >> >> On Thu, Feb
2017 Feb 17
6
Intel MPX support (instrumentation pass similar to gcc's Pointer Checker)
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, PARSEC, and SPEC benchmark
2016 Feb 04
2
Intel MPX support (instrumentation pass similar to gcc's Pointer Checker)
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 > >>
2016 Feb 03
2
Intel MPX support (instrumentation pass similar to gcc's Pointer Checker)
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
2016 Jan 28
3
Intel MPX support (instrumentation pass similar to gcc's Pointer Checker)
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
2016 Jan 28
2
Intel MPX support (instrumentation pass similar to gcc's Pointer Checker)
> 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
2016 Sep 02
2
ScalarEvolution pass and interprocedural analysis
Hello all, I was looking for an analysis pass that could provide comprehensive information on pointer arithmetic in the context of whole-program optimization. It seems that Scalar Evolution provides exactly what I'm looking for, but it is restricted to only intraprocedural analysis. E.g., consider this toy snippet: void foo(int* p) { (*p)++; } int bar() { int i; for (i = 0; i < n;
2013 Sep 10
3
[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
2013 Sep 10
0
[LLVMdev] Intel Memory Protection Extensions (and types question)
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
2017 Feb 18
2
[RFC] Using Intel MPX to harden SafeStack
On 2/7/2017 20:02, Kostya Serebryany wrote: > ... > > My understanding is that BNDCU is the cheapest possible instruction, > just like XOR or ADD, > so the overhead should be relatively small. > Still my guesstimate would be >= 5% since stores are very numerous. > And such overhead will be on top of whatever overhead SafeStack has. > Do you have any measurements
2013 Sep 10
0
[LLVMdev] Intel Memory Protection Extensions (and types question)
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
2013 Sep 10
2
[LLVMdev] Intel Memory Protection Extensions (and types question)
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
2017 Feb 08
4
[RFC] Using Intel MPX to harden SafeStack
Hi, I previously posted about using 32-bit X86 segmentation to harden SafeStack: http://lists.llvm.org/pipermail/llvm-dev/2016-May/100346.html That involves lowering the limits of the DS and ES segments that are used for ordinary data accesses while leaving the limit for SS, the stack segment, set to its maximum value. The safe stacks were clustered above the limits of
2013 Sep 10
2
[LLVMdev] Intel Memory Protection Extensions (and types question)
On Tue, Sep 10, 2013 at 1:04 PM, David Chisnall <David.Chisnall at cl.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
2013 Sep 10
0
[LLVMdev] Intel Memory Protection Extensions (and types question)
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
2016 May 26
1
Runtime interception: design problem
Hi John, On 25 May 2016 at 16:11, John Criswell <jtcriswel at gmail.com> wrote: > Dear Pierre, > > Stepping up a level, what is your goal in replacing calls to malloc() and > free()? Is it any different than what SAFECode, SoftBound, or ASan do? > That's a good question. I didn't knew about SoftBound until now, so thank you for the name =). Anyway here is what I
2018 Jun 30
2
Using BuildMI to insert Intel MPX instruction BNDCU failed
Hello everyone, I'm a newbie of llvm. I'm trying to insert Intel MPX instruction BNDCU with BuildMI. I add my machinefunctionpass at addPreEmitPass2. Here is the code of insertion: BuildMI(MBB, MI, DL, TII->get(X86::BNDCU64rr)).addReg(X86::BND2, RegState::Define).addReg(X86::R10); And here is to stack track when I compiler program with modified llc:
2015 Oct 13
0
Centos 6.7 on Tyan Tiger MPX, Graphics and eArrayDirector
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
2013 Sep 10
0
[LLVMdev] Intel Memory Protection Extensions (and types question)
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. The tables impose a very large storage space penalty, so are
2013 Sep 09
4
[LLVMdev] Intel Memory Protection Extensions (and types question)
Hi all, I'm currently adding new instructions and registers to the X86 code generator for Intel Memory Protection Extensions [1]. A class of special-purpose registers BNDx each holds 2 x 64-bit values. The components are not individually readable or writable (except by going through memory) but there are instructions that read only one of the two elements. The two 64-bit values can be