SAFECode SAFECode: Enforcing Alias Analysis for Weakly Typed Languages Dinakar Dhurjati University of Illinois at Urbana-Champaign Joint work with Sumant Kowshik, Vikram Adve

SAFECode Weakly Typed Languages (C/C++) Weak semantic guarantees –Undetected array bounds errors, dangling pointer errors, type cast errors, uninitialized pointers, etc.  Memory safety violations  Any static analysis is suspect Widely Ignored

SAFECode Static Analysis Tools Memory errors invalidate core analyses Yes or No property Software Tools (e.g. ESP, BLAST) C program Normal Compiler Alias analysis, Call graph, Type information Core Analyses ≈

SAFECode Why not use safe languages? Large body of legacy applications in C/C++ Porting is not easy –Automatic memory management or GC –Wrappers for library calls because of metadata on pointers Java, C#, safe dialects of C (e.g. CCured, Cyclone)

SAFECode Our Solution: SAFECode Not a safe language : tolerates errors Completely automatic, no wrappers, no GC Works for nearly all C programs Low overhead (less than 30% in our expts) Provides sound analysis platform –Sound operational semantics for C based on core analyses Masks dangling pointer, array bounds errors Ensures memory safety (defined later)

SAFECode SAFECode as Analysis Platform C program Normal Compiler Alias analysis, Call graph, Type information SAFECode C program with checks property Yes or No Software Verification e.g. ESP, BLAST SAFECode enforces core analyses, memory safety Core Analyses ≈

SAFECode Outline Motivation & Overview Background Approach Formalization Evaluation Summary

SAFECode Background - Alias Analysis P = malloc(2 * sizeof(int)); P[i] = …. struct BigT *Q = (Struct BigT *)P; TU S,A P Q field TK : Type Known, TU : Type Unknown struct List* head = makeList(20); struct List (TK) H next val head A static summary of memory objects and their connectivity Restriction: flow-insensitive, unification based Q->field8 = …

SAFECode Background - Automatic Pool Allocation (APA) [LattnerAdve:PLDI05] Each node instance uses separate pool Pool is destroyed if not accessible Pool 1Pool 2 List H next val head Partitions heap into pools based on alias analysis List H next val x y

SAFECode Outline Motivation & Overview Background Approach Formalization Evaluation Summary

SAFECode SAFECode Approach : Enforce Core Analyses Alias analysis Call graph –Run-time checks on indirect calls Type information –Subset of alias analysis

SAFECode Enforcing Alias Analysis Check if tmp points to corresponding node Normal allocators –Memory objects are scattered in the heap –Each check at run-time is extremely expensive struct List (TK) H next val tmp

SAFECode Insight 1 – Use Automatic Pool Allocation (APA) Each node instance uses separate pool Pool is destroyed if not accessible Pool 1Pool 2 List H next val head Partitions heap into pools based on alias analysis List H next val x y

SAFECode The Pool Bounds Check Pool is a list of pages (2^k) Pool maintains a hash table of the start addresses of the pages Poolcheck on a pointer p –Mask lower k bits of p, see if it is in the hash table –Alignment check for TK pools Poolcheck : involves hash lookups

SAFECode Insight 2 : Mostly static checking for TK pools 3 sufficient properties Type Known Pools Typed accessesfree Correct alignment free No pool bounds violations Pool bounds checks Type Unknown Pools Pool bounds checks on all operations Solution –Type homogeneity, do not release memory from pool ( Insight 3 ) Release memory from pool when pool is inaccessible (Insight 4)

SAFECode poolinit (ρ, int) PP { int* ρ x,y; int*ρ’ z; x = malloc(4); y = x; free(x); y = malloc(4); Formalization as a Type System Soundness theorem ensures core analyses are never invalidated Int xy ρ poolinit( ρ’, int) PP’ { poolinit (ρ, int) PP { int* ρ x,y; int*ρ’ z; x = poolalloc(PP, 1); //allocate one element y = x; //type checks poolfree(PP,x) y = poolalloc(PP,1); // malloc semantics different } ρ’ρ’ Int z

SAFECode Static Analysis Using SAFECode Flow-sensitive analysis –Only change is in malloc semantics Flow insensitive analyses –don’t require any changes e.g., ESP, BLAST Sound Analyses for C are now possible

SAFECode Evaluation (Run-time Overhead) Olden, Ptrdist, 3 system daemons [Full list in the paper] No source changes necessary Compared with CCured on Olden [See paper] ProgramSAFECode ratio bh1.03 bisort1.00 em3d1.27 treeadd0.99 tsp0.99 Yacr21.30 Ks1.12 anagram1.23 ftpd1.00 fingerd1.03 ghttpd ≡ no pool allocation + no SAFECode passes

SAFECode Related Work Modified C Pure C SolutionPerformance Error detection/ prevention Sound analysis Memory Management Purify, Valgrind Several 100xSome- - SafeC5xSome- - Jones-Kelley5-6xSome- - SFIOver 2xFew- - YongOver 2xSome- - SAFECodeUpto 1.30SomeYes - CCuredUpto 1.87AllYes GC Cyclone1x-2xAllYes Regions +GC

SAFECode Two errors we don’t detect Detecting array bounds overflow – A low overhead backwards-compatible solution [ICSE 2006] Detecting dangling pointer dereference –Efficient detection for some kinds of programs [DSN 2006]

SAFECode Conclusion Sound operational semantics for C + core analyses Guarantee alias analysis with low over head  We guarantee memory safety without detecting some errors - Control flow integrity - Data access integrity (type information) - Analysis integrity

SAFECode