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

Fri Feb 17 07:42:16 PST 2017

> 1.Code size data. I care it because code size is critical for 
> firmware. If possible, please compare them with and without normal 
> LZMA compression.

Yes, we could measure it.

> 2.Benchmark build flag, especially for the optimization level. And 
> what optimization level do these technologies support? E.g. O1, O3, 
> Oz, Os, LTO, etc. 
It's described on the "Methodology" page: 
https://intel-mpx.github.io/methodology/

Best,
Oleksii

On 02/17/2017 04:12 PM, Shi, Steven wrote:
>
> Hi Oleksenko,
>
> Thanks for the report, I’d like to reading through your report more 
> details. But I hope to know below info as well:
>
> 1.Code size data. I care it because code size is critical for 
> firmware. If possible, please compare them with and without normal 
> LZMA compression.
>
> 2.Benchmark build flag, especially for the optimization level. And 
> what optimization level do these technologies support? E.g. O1, O3, 
> Oz, Os, LTO, etc.
>
> *Steven Shi***
>
> *From:*llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of 
> *Oleksii Oleksenko via llvm-dev
> *Sent:* Friday, February 17, 2017 6:05 PM
> *To:* llvm-dev at lists.llvm.org
> *Subject:* [llvm-dev] 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 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

-- 

Best Regards,
Oleksii Oleksenko

TU Dresden
Faculty of Computer Science
Chair of Systems Engineering

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