SAFECode: Enforcing Alias Analysis for Weakly Typed Languages

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

2. 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

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

4. Why not use safe languages? Java, C#, safe dialects of C (e.g. CCured, Cyclone) • 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

5. 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)

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

7. Outline • Motivation & Overview • Background • Approach • Formalization • Evaluation • Summary

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

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

10. Outline • Motivation & Overview • Background • Approach • Formalization • Evaluation • Summary

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

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

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

14. 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

15. Insight 2 : Mostly static checking for TK 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)

16. Formalization as a Type System x y ρ Int z ρ’ Int poolinit (ρ, int) PP { int*ρ x,y; int*ρ’ z; x = malloc(4); y = x; free(x); y = malloc(4); 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 } } Soundness theorem ensures core analyses are never invalidated

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

18. Evaluation (Run-time Overhead) 1.0 ≡ no pool allocation + no SAFECode passes • Olden, Ptrdist, 3 system daemons [Full list in the paper] • No source changes necessary • Compared with CCured on Olden [See paper]

19. Related Work Pure C Modified C

20. 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]

21. 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 http://safecode.cs.uiuc.edu