similar to: 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

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

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

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

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 too biased) I am glad

> 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

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;

Trying to use built-in iexplore.exe (wine-0.9.14, FreeBSD-5.3? KDE-3.5.2). I get: $ wine iexplore fixme:shdocvw:IEWinMain "" 1 fixme:ole:CoResumeClassObjects stub Could not load Mozilla. HTML rendering will be disabled. fixme:shdocvw:ClOleCommandTarget_QueryStatus (0x17df9c)->((null) 1 0x34fba8 0x0) fixme:shdocvw:ClOleCommandTarget_Exec (0x17df9c)->((null) 25 0 0x34fbd0 0x0)

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

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

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

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

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 to

Hello All, I am looking at exploring what benefits SAFECode has to offer over clang S.A and llvm's instrumentation tools like memory sanitizer and address sanitizer. I could come up with the following that are not provided in ASAN/MSAN/Clang S.A -> dangling pointer error and detection -> crashes in system libraries due to security vulnerabilities. In the process, I wanted to run the

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

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

On 2/26/15 9:54 AM, Jyoti Rajendra Allur wrote: > Hello All, > I am looking at exploring what benefits SAFECode has to offer over clang S.A and llvm's instrumentation tools like memory sanitizer and address sanitizer. Are you looking for an off-the-shelf tool, or are you looking for approaches to use in your own tool? > I could come up with the following that are not provided in

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 DS and ES. Thus, by

https://bugs.freedesktop.org/show_bug.cgi?id=96307 Bug ID: 96307 Summary: Kernel 4.7-rc1 oops when starting X Product: xorg Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at

ruby script/generate controller Tools::Search - ok in views/layouts/application.rhtml: <%= render_component :controller => ''tools/search'', :action => ''searchbox'', :params => {:context => ''header-section''} %> in