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

Fri Feb 17 11:17:39 PST 2017

I LOVE this paper!

>From the comments I've sent you earlier you did not address just two:

* I've heard that MPX is incompatible with ILP32 (64-bit registers, 32-bit
pointers),
but I don't know the details.

* Did you investigate a possibility of false positives in cases where
MPX-instrumented
and non-instrumented code is mixed?
Here are the examples from 3+ years ago:
https://github.com/google/sanitizers/wiki/AddressSanitizerIntelMemoryPro
tectionExtensions#false-positive-with-un-instrumented-code
They might have been fixed already, but the general problem may remain.

Or did I miss these in the final paper?
Anyway, these are two additional subjects I'd like to see covered, and
their absence doesn't undermine the paper usefulness.
Thanks for the amazing work!

--kcc

On Fri, Feb 17, 2017 at 2:04 AM, Oleksii Oleksenko via llvm-dev <
llvm-dev at lists.llvm.org> 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 <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 <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 <http://clang.llvm.org/docs/ControlFlowIntegrity.html>
> *>* and
> *>* http://clang.llvm.org/docs/SafeStack.html <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/ <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 <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 <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 <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/20170217/c2ea4d2b/attachment.html>