similar to: [RFC] Using Intel MPX to harden SafeStack

Displaying 20 results from an estimated 4000 matches similar to: "[RFC] Using Intel MPX to harden SafeStack"

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
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
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
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 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
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:
2016 Jan 28
2
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
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 May 11
2
CentOS 6 / Intel CPU support
> Am 11.05.2017 um 16:29 schrieb Leon Fauster <leonfauster at googlemail.com>: > >> Am 11.05.2017 um 14:48 schrieb Leon Fauster <leonfauster at googlemail.com>: >> >> https://access.redhat.com/support/policy/intel >> >> shows mainly Xeon CPUs. What about >> >> Intel Core i7-6700 Quad-Core Skylake >> >>
2014 Nov 04
4
[LLVMdev] [PATCH] Protection against stack-based memory corruption errors using SafeStack
On 4 Nov 2014, at 00:36, Kostya Serebryany <kcc at google.com> wrote: > You at least increase the memory footprint by doubling the stack sizes. Not quite. The space overhead is constant for each stack frame - you just need to keep track of the top of two stacks, rather than one. The important overhead is that you reduce locality of reference. You will need a minimum of two cache
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
2014 Nov 03
8
[LLVMdev] [PATCH] Protection against stack-based memory corruption errors using SafeStack
Dear LLVM developers, Our team has developed an LLVM-based protection mechanism that (i) prevents control-flow hijack attacks enabled by memory corruption errors and (ii) has very low performance overhead. We would like to contribute the implementation to LLVM. We presented this work at the OSDI 2014 conference, at several software companies, and several US universities. We received positive
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
2013 Sep 10
0
[LLVMdev] Intel Memory Protection Extensions (and types question)
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
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 > >>
2013 Sep 09
2
[LLVMdev] Intel Memory Protection Extensions (and types question)
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
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
2014 Nov 15
3
[LLVMdev] [PATCH] Protection against stack-based memory corruption errors using SafeStack
Hi Kostya, >On Wed, Nov 12, 2014 at 2:50 AM, Volodymyr Kuznetsov <vova.kuznetsov at epfl.ch >> wrote: > >> Dear LLVM developers, >> >> We've applied the feedback we received on Phabricator on the SafeStack >> patches, >> > >Did you investigate the possibility of moving the transformation from >codegen to the LLVM level, i.e. the same level
2014 Nov 17
2
[LLVMdev] [PATCH] Protection against stack-based memory corruption errors using SafeStack
+nlewycky On Mon, Nov 17, 2014 at 9:36 AM, Volodymyr Kuznetsov <vova.kuznetsov at epfl.ch > wrote: > Hi Kostya, > > On Sat, Nov 15, 2014 at 1:53 PM, Volodymyr Kuznetsov < > vova.kuznetsov at epfl.ch> wrote: > > Do you think moving the pass to lib/Transform/Instrumentation but > > scheduling it during code generation would make sense ? If so, we'll