<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 26, 2015 at 8:49 AM, John Criswell <span dir="ltr"><<a href="mailto:jtcriswel@gmail.com" target="_blank">jtcriswel@gmail.com</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"><span class="">On 2/26/15 9:54 AM, Jyoti Rajendra Allur 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">
Hello All,<br>
I am looking at exploring what benefits SAFECode has to offer over clang S.A and llvm's instrumentation tools like memory sanitizer and address sanitizer.<br>
</blockquote>
<br></span>
Are you looking for an off-the-shelf tool, or are you looking for approaches to use in your own tool?<span class=""><br>
<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">
I could come up with the following that are not provided in ASAN/MSAN/Clang S.A<br>
-> dangling pointer error and detection<br>
</blockquote>
<br></span>
First, Clang's static analyzer is a static analysis bug finding tool.  It won't be able to find every memory safety error in a program.  In contrast, tools like Address Sanitzer and SAFECode instrument programs to detect (or mitigate) memory safety errors at run-time.<br>
<br>
Second, focusing on tools like ASan, SAFECode, etc., a more accurate statement is that:<br>
<br>
a) SAFECode, with automatic pool allocation enabled, can make dangling pointers "harmless" (in that they will either be detected or will not cause a type-safety violation, as defined by DSA's type inference results).<br>
<br>
b) The SoftBound + CETS system (an option currently built into SAFECode) can detect dangling pointer errors (but with much higher overhead).<br>
<br>
Please note that automatic pool allocation is currently disabled by default.<span class=""><br>
<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">
-> crashes in system libraries due to security vulnerabilities.<br>
</blockquote>
<br></span>
SAFECode augments or replaces various C library functions with memory-safe equivalents (that use the SAFECode metadata to do run-time checks).  I would think Address Sanitizer (ASan) would have that as well, but I'm not certain.  If it doesn't, I'm sure it could be added.<br>
<br></blockquote><div><br></div><div>asan replaces a whole bunch of libc functions so that we find bugs where an invalid pointer is passed to libc.   </div><div><br></div><div>This is still not perfect. We also want to find bugs in the system libraries themselves,</div><div>and we've been advocating for instrument-the-world approach.   </div><div>See e.g. <a href="http://www.chromium.org/developers/testing/instrumented-libraries-for-dynamic-tools">http://www.chromium.org/developers/testing/instrumented-libraries-for-dynamic-tools</a><br></div><div><br></div><div>There are scary things lurking in the system libraries.<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">
A third benefit of SAFECode and SoftBound is that they do real bounds checking.  Last I checked, ASan spaces memory objects out so that there is unused space between them; it then uses load and store checks which will detect a bounds violation if it reads or writes invalid memory.  The ASan approach is technically unreliable; it is possible for a pointer to "jump" from one memory object to another undetected.  </blockquote><div><br></div><div>Correct. This is a speed-vs-accuracy-vs-complexity trade-off</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">In contrast, SAFECode and SoftBound add run-time checks to pointer arithmetic operations, so they know when pointers go out of bounds.  That said, I'm not sure if ASan's bounds checking limitation is an issue in practice.<br>
<br></blockquote><div>Depending on the definition of "issue in practice". </div><div>asan finds lots of bugs everywhere we tried,</div><div>but it is by no means a verification tool. </div><div>Neither is any other *dynamic* testing tool for C++ that I am aware of. </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">
A fourth benefit is that, in my opinion, SAFECode's debugging output is easier to read.  However, since I wrote it, I'm a bit biased. :)<br>
<br>
One advantage ASan has over SoftBound and SAFECode is that it is integrated into LLVM and has industry developers dedicated to it. SAFECode and SoftBound are currently maintained by research groups.<span class=""><br>
<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">
In the process, I wanted to run the testsuite of safecode and poolalloc but could not find any documentation about how to run those testsuite. It would be great if someone pointed that out for me.<br>
</blockquote>
<br></span>
For the lit tests, cd into the test directory and type "make lit". These tests verify basic functionality and run some buffer overflow benchmark tests on SAFECode.<br>
<br>
To run SAFECode on the LLVM test suite, I believe the progdebug target is the one you want to use.<span class=""><br>
<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">
Also, were there any design scalability issues due to which SAFECode has not been supported beyond llvm 3.2 ?<br>
If yes, could someone let me know about them?<br>
</blockquote>
<br></span>
There is no fundamental reason why SAFECode and SoftBound cannot work with newer versions of LLVM.  Someone just needs to take the time to update the code to use the new LLVM C++ API.<br>
<br>
Regards,<br>
<br>
John Criswell<span class=""><font color="#888888"><br>
<br>
-- <br>
John Criswell<br>
Assistant Professor<br>
Department of Computer Science, University of Rochester<br>
<a href="http://www.cs.rochester.edu/u/criswell" target="_blank">http://www.cs.rochester.edu/u/<u></u>criswell</a></font></span><div class=""><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div></div>