[LLVMdev] LLVM-based address sanity checker

John Criswell criswell at illinois.edu
Wed May 4 07:32:25 PDT 2011


On 5/3/11 1:52 PM, Kostya Serebryany wrote:
> Hello,
>
> We've just released the first version of our LLVM-based address sanity 
> checker: AddressSanitizer (http://code.google.com/p/address-sanitizer/).
> The tool finds out-of-bound and use-after-free bugs (the subset of 
> bugs detectable by Valgrind/Memcheck);
> it consists of a LLVM compiler plugin which performs simple code 
> instrumentation and a malloc replacement library.
> The main advantage of the new tool is high speed: the slowdown is 
> usually within 2x-2.5x.
> Detailed description of the algorithm is found here: 
> http://code.google.com/p/address-sanitizer/wiki/AddressSanitizerAlgorithm
> The tool is young, but it already can run the Chromium browser 
> (interactively!) and find bugs in it.

Interesting.  We've been working on our own open-source memory safety 
tool called SAFECode (http://sva.cs.illinois.edu).  SAFECode has a 
number of nice features, including:

o) It works on both Mac OS X and Linux (and should work on other Unix 
platforms with little/no modification).
o) It has options for performing safety checks on loads/stores and on 
array/struct indexing operations.
o) It can accurately detect array bounds violations on global and stack 
objects as well as heap objects (unlike Valgrind, which must use 
heuristics to identify global/stack object boundaries).
o) It can optionally instrument C library functions to detect memory 
safety errors.
o) It has both simple and sophisticated optimization passes that remove 
unneeded instrumentation.
o) It has a debug instrumentation pass that can use LLVM debug metadata 
to enhance instrumentation to include source filename / line number info 
(although this code needs to be updated).
o) It has features to make dangling pointer dereferences "safe" for 
production code.
o) It has an experimental mode for precise dangling pointer detection.
o) We have a new, faster memory object tracking run-time based on Baggy 
Bounds Checking.

We've been doing a lot of refactoring work so that SAFECode can be used 
without DSA and Automatic Pool Allocation (APA) and could therefore be 
integrated into LLVM and Clang.  Integrating them would make them easier 
to use (because one wouldn't need to change Makefiles in large projects 
to generate bitcode files; just flip a switch on the Clang command-line) 
and would ease our maintenance burden (because there would be less 
out-of-tree code).  An optional, out-of-tree libLTO library including 
DSA and APA could provide the remaining optimization functionality for 
those that want to use it.

Would there be any objections to incorporating portions of SAFECode free 
of DSA/APA dependencies into mainline LLVM and adding a command-line 
option to Clang to tell it to instrument a program using SAFECode?

-- John T.

>
> Would the LLVM community be interested in adopting this code into the 
> LLVM trunk?
> The instrumentation pass is ~350 LOC 
> (http://code.google.com/p/address-sanitizer/source/browse/trunk/llvm/AddressSanitizer.cpp), 
> but may grow over time as we add optimizations.
> The run-time library (malloc replacement, 
> http://code.google.com/p/address-sanitizer/source/browse/trunk/asan/asan_rtl.cc) 
> is ~1500 LOC.
>
> Thanks,
>
> --kcc
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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


More information about the llvm-dev mailing list