[LLVMdev] summer of code idea — checking bounds overflow bugs

[Adve, Vikram Sadanand]

On Mar 30, 2010, at 11:33 AM, John Regehr wrote:

> John-- a couple questions:
> 
> Can you explain the SAFECode model in a bit more detail?  I am getting 
> conflicting information.  On one hand, some of the papers describe a 
> system that is primarily designed to hide safety violations.  On the other 
> hand, the 2006 ICSE paper that I cited earlier today seems to be talking 
> about catching violations.  

SAFECode has both capabilities.  The complete array bounds checking described in the ICSE paper is an option.  So are the complete dangling pointer checks described in a DSN 2006 paper (that one has higher overhead for many programs).  The guarantees in the PLDI 2006 paper -- partial type safety, control flow integrity, and a sound operational semantics -- hold regardless of whether those two options are enabled or not.

The code in the public repository defaults to a debugging version that (a) turns on complete bounds checking;     (b) I think turns on dangling pointer checks; but (c) does not use Automatic Pool Allocation, so it does not guarantee the soundness of pointer analysis.  It also does much more information tracking to give useful feedback on bugs.  Of course, it has much higher overhead than if we had made other choices, e.g., for use in production code.

--Vikram


> These are very different goals!  What does the 
> code in the SAFECode repository actually do?
> 
> Can you comment on the speed of LLVM when shelling out to Omega?  My guess 
> would be that this will result in unacceptable compile times for large 
> software, and that something fast and relatively simple like ABCD is a 
> better choice for general usage.
> 
> Finally a comment: it's a clear that a comprehensive system for trapping 
> undefined behavior in Clang is a multi-year project.  Some parts of this 
> must live in Clang.  Some parts, such as bounds check optimizations, 
> should go into LLVM passes.  Anyway I'm just saying that the project you 
> outlines seems to fit very well into the overall vision of detecting 
> undefined behavior in C programs.
> 
> John
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev