thr3ads.net - llvm dev - [llvm-dev] Intel MPX support (instrumentation pass similar to gcc's Pointer Checker) [Feb 2017]

If this information is useful, please help other people find it:
Share via:

Oleksii Oleksenko via llvm-dev

2017-Feb-17 10:04 UTC

[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 atgmail.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

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

Shi, Steven via llvm-dev

2017-Feb-17 15:12 UTC

head link

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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170217/fb103328/attachment.html>

Oleksii Oleksenko via llvm-dev

2017-Feb-17 15:35 UTC

head link

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

****Sorry for such a weird text above, it was meant to be posted as a 
continuation of an old thread.

> *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/76f383fb/attachment-0001.html>

Oleksii Oleksenko via llvm-dev

2017-Feb-17 15:42 UTC

head link

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

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

Kostya Serebryany via llvm-dev

2017-Feb-17 19:17 UTC

head link

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

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>

Oleksii Oleksenko via llvm-dev

2017-Feb-18 12:45 UTC

head link

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

Thank you!
> * I've heard that MPX is incompatible with ILP32 (64-bit registers, 
> 32-bit pointers),
> but I don't know the details.
Maybe there are some corner cases that I'm not aware of, but in most 
cases it does support 32-bit mode. At some point, we even tried running 
32-bit version of RIPE and GCC-MPX successfully detected 262 out of 417 
attacks (155 were probably undetected because of suboptimal default 
compilation flags).
> * 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/AddressSanitizerIntelMemoryProtectionExtensions#false-positive-with-un-instrumented-code
>
<https://github.com/google/sanitizers/wiki/AddressSanitizerIntelMemoryProtectionExtensions#false-positive-with-un-instrumented-code>
> They might have been fixed already, but the general problem may remain.It is buried deep in the text, but we mention this issue. It's in the 
end of 3.1.Hardware-Instruction set: "[...] the pointer created/altered 
in legacy code is considered “boundless”: this
allows for interoperability but also creates holes in Intel MPX defense" 
+ footnote on the same page.

Yet, you are right: (1) we've mentioned only false negatives, not false 
positives and (2) we should make it more explicit because it's an 
important issue which appears in real applications (e.g., x264 from 
PARSEC).

We will add this notes to the updated version of the report.

Best,
Oleksii


On 17.02.2017 20:17, Kostya Serebryany wrote:> 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/AddressSanitizerIntelMemoryProtectionExtensions#false-positive-with-un-instrumented-code
>
<https://github.com/google/sanitizers/wiki/AddressSanitizerIntelMemoryProtectionExtensions#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 <mailto: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
>     <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
>     <mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170218/a9f3ca96/attachment-0001.html>

Philip Reames via llvm-dev

2017-Apr-16 18:31 UTC

head link

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

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>

Possibly Parallel Threads

Search for more maybe matching threads

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

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

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

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

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

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

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

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

Possibly Parallel Threads