[llvm-dev] Intel MPX support (instrumentation pass similar to gcc's Pointer Checker)

Sun Apr 16 11:31:27 PDT 2017

Just wanted to say thank you for publishing this.  I ran across your 
micro-benchmark numbers a few days ago through another avenue, and found 
them incredibly helpful.  I also found your explanations of the various 
instruction semantics be much easier to understand than the Intel docs.  
Thank you; this has saved me a lot of time and has triggered some 
experimental follow up work of my own.

https://intel-mpx.github.io/microbenchmarks/

Philip

On 02/17/2017 02:04 AM, Oleksii Oleksenko via llvm-dev wrote:
>
> 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 suites), security (RIPE and found 
> bugs in benchmarks), and usability (false positives and required 
> changes in applications). Additionally, we've analyzed various 
> implementation aspects of Intel MPX and tested it on real-world 
> applications.
>
> We would appreciate your feedback.
>
>
> Regards,
> Oleksii Oleksenko
>
> On 02/09/2016 10:27 PM, Kostya Serebryany via llvm-dev wrote:
> >/On Tue, Feb 9, 2016 at 7:22 AM, Dmitrii Kuvaiskii < />/Dmitrii.Kuvaiskii at tu-dresden.de 
> <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>> wrote: />//>>/Thank you Sergey and Konstantin for useful suggestions. We are />>/currently bootstrapping the infrastructure for our experiments. We />>/would like to make a sufficiently comprehensive report, with not only />>/the performance/memory overhead numbers, but also discussing and />>/evaluating security guarantees. I will also examine the available />>/source codes (ASan, gcc-mpx, SoftBound) and will spend some pages on a />>/discussion of the different approaches (trying to do science, you see />>/:)). />>//>>/Btw, I will target only deterministic memory-safety no-code-changes />>/approaches that protect against spatial errors (I will probably />>/include also ASan and SoftBoundCETS with temporal errors' protection />>/in the results as well). The only technique (except Pointer Checker, />>/ASan, and SoftBound) I know of is Baggy Bounds Checking from MSR, but />>/it seems to be closed-source and Windows-oriented. If anyone can />>/suggest some other technique that could be evaluated here, please />>/inform me. />>//>//>/There is also a family of tools originated from Electric Fence />/<http://elinux.org/Electric_Fence>, />/they mostly have historical interest due to huge slowdown/memory />/consumption. /
> I can assure you that they are still widely used for QA :)
>
> >/Are you looking for bug detection mechanisms, or also for production />/hardening techniques? />/ASan is a bug detection tool. ASan can />/<https://blog.torproject.org/blog/tor-browser-55a4-hardened-released> be />/used for hardening, but that's not it's primary purpose. />/Same is true (IMHO) about Pointer Checker and SoftBound. />//>/Hardening is an entirely different subject, although there is a bit of />/intersection, />/e.g. I know that parts of UBSan (-fsanitize=signed-integer-overflow) are />/used for hardening. />/In LLVM, also have a look at 
> clang.llvm.org/docs/ControlFlowIntegrity.html />/and />/http://clang.llvm.org/docs/SafeStack.html />//>>//>>/Anyway, before putting the techreport online, I will send the draft to />>/everyone who took part in this conversation, just to be on the safe />>/side and correct any bugs/wrong conclusions. />>//>//>/I would appreciate this. />//>/--kcc />//>//>>//>>/On Tue, Feb 9, 2016 at 3:24 PM, Sergey Ostanevich <sergos.gnu at 
> gmail.com <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>> />>/wrote: />>>/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 
> <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>> wrote: />>>>//>>>>//>>>>//>>>>/On Thu, Feb 4, 2016 at 10:40 AM, Kostya Serebryany <kcc at google.com 
> <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>> />>/wrote: />>>>>//>>>>>//>>>>>//>>>>>/On Thu, Feb 4, 2016 at 4:59 AM, Dmitrii Kuvaiskii />>>>>/<Dmitrii.Kuvaiskii at tu-dresden.de 
> <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>> 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 of />>/15%-25%! />>>>>>>/That's interesting. />>>>>>>/Are you sure you are instrumenting both reads and writes with icc? />>>>>>//>>>>>>/Yes, here are the exact flags I add to the usual build configuration: />>>>>>/-xHOST -check-pointers-mpx:rw />>>>>//>>>>>//>>>>>/Interesting, looking forward to reading your report! />>>>>>//>>>>>>//>>>>>>/Note "rw" which stands for protecting read and write accesses. In the />>>>>>/future, I will analyze how different flags affect ASan / SoftBoundCETS />>>>>>// gcc-mpx / icc-mpx. />>>>>>/I will also use a set of microbenchmarks/benchmarks (e.g., RIPE) to />>>>>>/test the protection provided. />>>>>>//>>>>>>>/SPEC2006 is well know so it could be useful. Especially />>/483.xalancbmk />>>>>>>/Besides, maybe you could take something that is not strictly a />>>>>>>/benchmark. />>>>>>>/E.g. take pdfium_test (https://pdfium.googlesource.com/pdfium/) and />>>>>>>/feed />>>>>>>/several large pdf files to it. />>>>>>//>>>>>>/Thanks, I will report the SPEC2006 numbers as well. />>>>>>//>>>>>//>>>>>/Note that SPEC2006 has several know bugs that trigger under asan. />>>>>//>>>>>//>>/https://github.com/google/sanitizers/wiki/AddressSanitizerRunningSpecBenchmarks 
> />>>>>/has a patch that makes SPEC2006 pass with asan. />>>>>/Some of these bugs and maybe others may also trigger with an MPX />>/checker. />>>>//>>>>//>>>>/Another note: please also try to document the memory footprint. />>>>/One of unfortunate features of MPX is its large metadata storage which />>/may />>>>/in />>>>/theory consume as much as 4x more RAM than the application itself. />>>>//>>>>/--kcc />>>>//>>>>>//>>>>>//>>>>>/--kcc />>>>>//>>>>>>/-- />>>>>>/Yours sincerely, />>>>>>/Dmitrii Kuvaiskii />>>>>//>>>>>//>>>>//>>>>//>>>>/_______________________________________________ />>>>/LLVM Developers mailing list />>>>/llvm-dev at lists.llvm.org 
> <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> />>>>/http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev />>>>//>>>//>>//>>/-- />>/Yours sincerely, />>/Dmitrii Kuvaiskii />>//>//>//>//>/_______________________________________________ />/LLVM Developers mailing list />/llvm-dev at lists.llvm.org 
> <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> />/http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev />
> -- 
>
> Best Regards,
> Oleksii Oleksenko
>
> TU Dresden
> Faculty of Computer Science
> Chair of Systems Engineering
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170416/f9903b90/attachment.html>