<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Sep 14, 2014 at 2:07 AM, Szabolcs Nagy <span dir="ltr"><<a href="mailto:nsz@port70.net" target="_blank">nsz@port70.net</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">* Reid Kleckner <<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>> [2014-09-13 18:37:57 -0700]:<br>
<span>> Not that I know of. So far as I know, ASan is superior to any MIX based<br>
> instrumentation. The only class of false negatives I know of is arrays in<br>
> structs, which there are plans for.<br>
><br>
<br>
</span>mpx is new to me, but looking at the docs it solves a different<br>
problem than asan<br>
<br>
asan must not be used in production code, it's not a hardening<br>
solution, but a debugging one</blockquote><div><br></div><div>We prefer to say "asan is for testing" instead of "for debugging". </div><div>You are right, asan is not a way to protect your code from attackers in production.</div><div>There is NaCl for that. </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"> (it actually increases the attack<br>
surface by all its instrumentations, its own set of reliance on<br>
ub and strong interdependency on libc internals)<br></blockquote><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">
<br>
mpx is for hardening deployed code with bounds check instructions<br></blockquote><div><br></div><div>[Note: I have a very biased opinion on MPX...]</div><div>Here is my impression from MPX (last updated 10 months ago)</div><div><a href="https://code.google.com/p/address-sanitizer/wiki/IntelMemoryProtectionExtensions" target="_blank">https://code.google.com/p/address-sanitizer/wiki/IntelMemoryProtectionExtensions</a><br></div><div><br></div><div>"mpx is for hardening deployed code" is an overstatement imho. </div><div>MPX is going to incur a huge memory cost for most of the programs.</div><div>And until I see the numbers on the real hardware I am also unconvinced that</div><div>MPX will be fast enough "for hardening deployed code".</div><div><br></div><div>Unless you instrument *all* the code with MPX, this is a very lousy sandbox. </div><div>And even then, it doesn't protect you from heap-use-after-free and stack-use-after-return. </div><div><br></div><div>As Reid mentioned, MPX is good for detecting intra-object buffer overflows,</div><div>which today's asan can't make.</div><div>We have a plan for attack, but MPX's approach is still better for this particular class of bugs, </div><div>so I want to see MPX in LLVM, but I am not ready to invest much time in it </div><div>(including doing the code reviews).</div><div>Another problem is that implementing MPX in a compiler is a major disruption</div><div>(see how long it takes to add MPX support in GCC, and it's not there yet after more than a year of work). </div><div><br></div><div>--kcc </div><div><br></div><div><br></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><div>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div></div>