Svadev mailing list

[John Criswell <criswell AT illinois.edu>]

On 9/27/12 1:50 PM, Santosh Nagarakatte wrote:
> Hi all,
>
> I was wondering how SAFECode detects use after free errors.  There are
> many use-after-free tests in tests directory.

Really?  Which ones?  Are you sure that they're not invalid free() tests?

> I did a quick scan of the safecode source code. I could not find
> specific checks that performed use-after-free checking.
> Can you point me to documentation that describes how use-after-free
> errors are detected with SAFECode?

SAFECode does not have use-after-free checks in the same way that CETS 
does.  What SAFECode can do is determine if a pointer points to 
unallocated memory; however, if virtual address space used by a freed 
object is reused for a new memory object, a dereference of the dangling 
pointer will not be detected.

Having said that, SAFECode *with* automatic pool allocation can 
guarantee that a dangling pointer dereference will not violate points-to 
analysis(1) (and therefore, won't violate memory safety). Automatic pool 
allocation segregates the heap based on points-to sets; a dangling 
pointer dereference will either access an unallocated but unchanged 
memory object, an uninitialized memory object, or another memory object 
that belongs to the same points-to set.  In essence, automatic pool 
allocation removes any extra "aliasing" behavior that might occur due to 
dangling pointers.

Automatic pool allocation also enables sound type-safe load/store check 
elimination and enforcement of partial type-safety (i.e., if 
type-inference can find memory objects used in a type-safe manner, then 
SAFECode with automatic pool allocation can ensure that dangling 
pointers don't violate that type safety).

There is code within SAFECode to *detect* use-after-free errors(2) using 
MMU tricks, but it has probably suffered bitrot since we integrated 
SAFECode with Clang.

As far as priorities, automatic pool allocation is on our list of things 
to make more robust and to eventually include in the "on by default" 
features of SAFECode.  The dangling pointer detection is not.

> Are all the use-after-errors detected by Valgrind or ASan also
> detected by SAFECode's use after free checking?

No.  I'm not sure how Valgrind does use-after-free checking, but I 
believe ASan simply uses a deferred reuse strategy: freed memory objects 
go on a list and their shadow bits are marked as "not a valid memory 
object."  The virtual addresses of the freed memory objects are not 
reused for as long as possible to increase the likelihood that a 
dangling pointer dereference is caught.

In comparison, the CETS and SAFECode DSN approaches (2) are guaranteed 
to find errors whereas ASan only gives a "best effort." The SAFECode 
Automatic Pool Allocation approach (1) won't do any actual detection, 
but it's probably more suitable for production-time protection as it 
provides a strong safety guarantee without incurring the overhead of 
detection.

-- John T.

> Thanks,
> Santosh

(1) http://llvm.org/pubs/2006-06-12-PLDI-SAFECode.html
(2) http://llvm.org/pubs/2006-DSN-DanglingPointers.html