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. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110503/dd4e4f71/attachment.html>
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>
Hello again, The tool we announced 1.5 months ago has matured quite a bit. In addition to heap out-of-bound and use-after-free bugs it also finds stack overruns/underruns. AddressSanitizer is being actively used by the Chromium developers and already found over 20 bugs: http://blog.chromium.org/2011/06/testing-chromium-addresssanitizer-fast.html Question to the LLVM developers: would you consider adding the AddressSanitizer code to the LLVM trunk? Thanks, --kcc On Tue, May 3, 2011 at 10:52 PM, Kostya Serebryany <kcc at google.com> 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. > > 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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110616/e95aacf3/attachment.html>
Rafael Ávila de Espíndola
2011-Jun-16 15:28 UTC
[LLVMdev] LLVM-based address sanity checker
> Would the LLVM community be interested in adopting this code into > the LLVM trunk?I cannot approve it, but I would love to have it :-)> Thanks, > > --kcc >Cheers, Rafael
On Jun 16, 2011, at 1:27 AM, Kostya Serebryany wrote:> Hello again, > > The tool we announced 1.5 months ago has matured quite a bit. > In addition to heap out-of-bound and use-after-free bugs it also finds stack overruns/underruns. > AddressSanitizer is being actively used by the Chromium developers and already found over 20 bugs: http://blog.chromium.org/2011/06/testing-chromium-addresssanitizer-fast.html > > Question to the LLVM developers: would you consider adding the AddressSanitizer code to the LLVM trunk?Having functionality like this in mainline would be really interesting. I haven't looked at your code yet, what are the major components, what impact does it have on the codebase? -Chris> > Thanks, > > --kcc > > On Tue, May 3, 2011 at 10:52 PM, Kostya Serebryany <kcc at google.com> 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. > > 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/20110616/ecbcd103/attachment.html>
On 16 June 2011 09:27, Kostya Serebryany <kcc at google.com> wrote:> Question to the LLVM developers: would you consider adding > the AddressSanitizer code to the LLVM trunk?Do you have an idea how hard would it be to port to non-x86 platforms? I saw some Intel ASM in the C++ file... The run-time library being 1.5k loc is not encouraging, but it didn't look particularly platform specific... cheers, --renato