[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