<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 9, 2016 at 7:22 AM, Dmitrii Kuvaiskii <span dir="ltr"><<a href="mailto:Dmitrii.Kuvaiskii@tu-dresden.de" target="_blank">Dmitrii.Kuvaiskii@tu-dresden.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Thank you Sergey and Konstantin for useful suggestions. We are<br>
currently bootstrapping the infrastructure for our experiments. We<br>
would like to make a sufficiently comprehensive report, with not only<br>
the performance/memory overhead numbers, but also discussing and<br>
evaluating security guarantees. I will also examine the available<br>
source codes (ASan, gcc-mpx, SoftBound) and will spend some pages on a<br>
discussion of the different approaches (trying to do science, you see<br>
:)).<br>
<br>
Btw, I will target only deterministic memory-safety no-code-changes<br>
approaches that protect against spatial errors (I will probably<br>
include also ASan and SoftBoundCETS with temporal errors' protection<br>
in the results as well). The only technique (except Pointer Checker,<br>
ASan, and SoftBound) I know of is Baggy Bounds Checking from MSR, but<br>
it seems to be closed-source and Windows-oriented. If anyone can<br>
suggest some other technique that could be evaluated here, please<br>
inform me.<br></blockquote><div><br></div><div>There is also a family of tools originated from <a href="http://elinux.org/Electric_Fence">Electric Fence</a>, </div><div>they mostly have historical interest due to huge slowdown/memory consumption. </div><div><br></div><div>Are you looking for bug detection mechanisms, or also for production hardening techniques? </div><div>ASan is a bug detection tool. ASan <a href="https://blog.torproject.org/blog/tor-browser-55a4-hardened-released">can</a> be used for hardening, but that's not it's primary purpose. </div><div>Same is true (IMHO) about Pointer Checker and SoftBound. </div><div><br></div><div>Hardening is an entirely different subject, although there is a bit of intersection, </div><div>e.g. I know that parts of UBSan (-fsanitize=signed-integer-overflow) are used for hardening. </div><div>In LLVM, also have a look at <a href="http://clang.llvm.org/docs/ControlFlowIntegrity.html">clang.llvm.org/docs/ControlFlowIntegrity.html</a> and </div><div><a href="http://clang.llvm.org/docs/SafeStack.html">http://clang.llvm.org/docs/SafeStack.html</a><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
Anyway, before putting the techreport online, I will send the draft to<br>
everyone who took part in this conversation, just to be on the safe<br>
side and correct any bugs/wrong conclusions.<br></blockquote><div><br></div><div>I would appreciate this. </div><div><br></div><div>--kcc </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5"><br>
On Tue, Feb 9, 2016 at 3:24 PM, Sergey Ostanevich <<a href="mailto:sergos.gnu@gmail.com">sergos.gnu@gmail.com</a>> wrote:<br>
> Dmitrii, all,<br>
><br>
> Please note, that GCC 5.3 had a significant update to the MPX code quality -<br>
> please, use this version as reference.<br>
><br>
> Regards,<br>
> Sergos<br>
><br>
> On Tue, Feb 9, 2016 at 12:49 AM, Kostya Serebryany via llvm-dev<br>
> <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>><br>
>><br>
>> On Thu, Feb 4, 2016 at 10:40 AM, Kostya Serebryany <<a href="mailto:kcc@google.com">kcc@google.com</a>> wrote:<br>
>>><br>
>>><br>
>>><br>
>>> On Thu, Feb 4, 2016 at 4:59 AM, Dmitrii Kuvaiskii<br>
>>> <<a href="mailto:Dmitrii.Kuvaiskii@tu-dresden.de">Dmitrii.Kuvaiskii@tu-dresden.de</a>> wrote:<br>
>>>><br>
>>>> >> Recently I played with MPX support on Intel C/C++ Compiler (icc).<br>
>>>> >> This<br>
>>>> >> implementation looks *much* better, with the following example<br>
>>>> >> overheads: 1.2X on "raytrace", 1.25X on "bodytrack", 1.08X on<br>
>>>> >> "streamcluster". So the common overheads are in the range of 15%-25%!<br>
>>>> > That's interesting.<br>
>>>> > Are you sure you are instrumenting both reads and writes with icc?<br>
>>>><br>
>>>> Yes, here are the exact flags I add to the usual build configuration:<br>
>>>>   -xHOST -check-pointers-mpx:rw<br>
>>><br>
>>><br>
>>> Interesting, looking forward to reading your report!<br>
>>>><br>
>>>><br>
>>>> Note "rw" which stands for protecting read and write accesses. In the<br>
>>>> future, I will analyze how different flags affect ASan / SoftBoundCETS<br>
>>>> / gcc-mpx / icc-mpx.<br>
>>>> I will also use a set of microbenchmarks/benchmarks (e.g., RIPE) to<br>
>>>> test the protection provided.<br>
>>>><br>
>>>> > SPEC2006 is well know so it could be useful. Especially 483.xalancbmk<br>
>>>> > Besides, maybe you could take something that is not strictly a<br>
>>>> > benchmark.<br>
>>>> > E.g. take pdfium_test (<a href="https://pdfium.googlesource.com/pdfium/" rel="noreferrer" target="_blank">https://pdfium.googlesource.com/pdfium/</a>) and<br>
>>>> > feed<br>
>>>> > several large pdf files to it.<br>
>>>><br>
>>>> Thanks, I will report the SPEC2006 numbers as well.<br>
>>>><br>
>>><br>
>>> Note that SPEC2006 has several know bugs that trigger under asan.<br>
>>><br>
>>> <a href="https://github.com/google/sanitizers/wiki/AddressSanitizerRunningSpecBenchmarks" rel="noreferrer" target="_blank">https://github.com/google/sanitizers/wiki/AddressSanitizerRunningSpecBenchmarks</a><br>
>>> has a patch that makes SPEC2006 pass with asan.<br>
>>> Some of these bugs and maybe others may also trigger with an MPX checker.<br>
>><br>
>><br>
>> Another note: please also try to document the memory footprint.<br>
>> One of unfortunate features of MPX is its large metadata storage which may<br>
>> in<br>
>> theory consume as much as 4x more RAM than the application itself.<br>
>><br>
>> --kcc<br>
>><br>
>>><br>
>>><br>
>>> --kcc<br>
>>><br>
>>>> --<br>
>>>> Yours sincerely,<br>
>>>> Dmitrii Kuvaiskii<br>
>>><br>
>>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
>><br>
><br>
<br>
--<br>
Yours sincerely,<br>
Dmitrii Kuvaiskii<br>
</div></div></blockquote></div><br></div></div>