1. Saturn Overview1 An Overview of the Saturn Project

2. The Three-Way Trade-Off Precision –Modeling programs accurately enough to be useful Scalability –Saying anything at all about large programs Human Effort –How much work must the user do? –Either giving specifications, or interpreting results Saturn Overview2 Today’s focus Not so much about this...

3. Saturn Overview3 Precision int f(int x) {... } Intraprocedural analysis with minimal abstraction. Ff Ff A(F g ) A(F h ) Primary abstraction is done at function boundaries. [A(F f ), A(F g ), A(F h )] A(F f ) [A(F f ), A(F g ), A(F h )] formula

4. Saturn Overview4 Scalability Design constraint: SAT formula size ~ function size Analyze one function at a time Parallel implementation –Server sends functions to clients to analyze –Typically use 50-100 cores to analyze Linux

5. Summaries Abstract at function boundaries –Compute a summary for function’s behavior Summaries should be small –Ideally linear in the size of the function’s interface Summaries are our primary form of abstraction –Saturn delays abstraction to function boundaries Slogan: Analysis design is summary design! Saturn Overview5

6. Expressiveness Analyses written in Calypso Logic programs –Express traversals of the program –E.g., backwards/forwards propagation Constraints –For when we don’t know traversal order Written ~40,000 lines of Calypso code Saturn Overview6

7. Availability An open source project –BSD license All Calypso code available for published experiments saturn.stanford.edu Saturn Overview7

8. People Saturn Overview8 Brian Hackett Alex Aiken Suhabe Bugrara Isil Dillig Thomas Dillig Peter Hawkins Yichen Xie (past)

9. Outline Saturn overview An example analysis –Intraprocedural –Interprocedural What else can you do? Survey of results Saturn Overview9

10. Saturn Architecture C Program C Frontend C Syntax Databases Calypso Interpreter Calypso analyses Constraint Solvers Summary Databases Summary Reports UI 10Saturn Overview

11. Parsing and C Frontend Source Code Build Interceptor Preprocessed Source Code CIL frontend Abstract Syntax Tree Databases Other possible frontends 11Saturn Overview

12. Calypso General purpose logic programming language –Pure –Prolog-like syntax Bottom-up evaluation –Magic sets transformation Also a (minor) moon of Saturn 12Saturn Overview

13. Helpful Features Strong static type and mode checking Permanent data (sessions) –stored as Berkeley DB databases –Sessions are just a named bundle of predicates Support for unit-at-a-time analysis 13Saturn Overview

14. Extensible Interpreter Logic Program Interpreter SAT Solver #sat predicate, … LP Solver DOT graph package UI package 14Saturn Overview

15. Scalability Interpreter is not very efficient OK, it’s slow But can run distributed analyses –50-100 CPUs Scalability is more important than raw speed –Can run intensive analyses of the entire Linux kernel (>6MLOC) in a few hours. 15Saturn Overview

16. Cluster Architecture Master Node Worker Node 1 Worker Node 100 Calypso DB Calypso DB Databases 16Saturn Overview

17. Job Scheduling Saturn Overview17 Dynamically track dependencies between jobs Rerun jobs if new dependencies found Optimistic concurrency control Job = a function body Iterate to fixpoint for circular dependencies

18. Constraint Solvers Calypso Analyses Alias Analysis Function Pointer Analysis C Syntax Predicates CFG Construction Memory Model NULL checker Typestate verifier 18Saturn Overview

19. Check that a thread does not: –acquire the same lock twice –release the lock twice Otherwise the application may deadlock or crash. The Paradigmatic Locking Analysis 19Saturn Overview

20. Specification Saturn Overview20 locked unlocked error unlock lock unlock lock

21. We assume –one locking function lock(l) –one unlocking function unlock(l). We analyze one function at a time –produce locking summary describing the FSM transitions associated with a given lock. Basic Setup 21Saturn Overview

22. An Example Function & Summary Saturn Overview22 f(..., lock *L,...) { lock(L);... unlock(L); } L: unlocked -> unlocked locked -> error Summaries are input state -> output state The net effect of the function on the lock Summary size is independent of function size Bounded by the square of the number of states

23. type lockstate ::= locked | unlocked | error. Predicates to describe lock states on nodes and edges of the CFG: predicate node_state(P:pp,L:t_trace,S:lockstate,G:g_guard). predicate edge_state(P:pp,L:t_trace,S:lockstate,G:g_guard). Program point pp is a unique id for each point in the program Trace t_trace is a unique name for a memory location Guard g_guard is a boolean constraint Lock States 23Saturn Overview

24. 1. Initialize lock states at function entry 2. Join operator: – Combine edges to produce successor’s node_state 3. Transfer functions for every primitive: –assignments –tests –function calls The Intraprocedural Analysis 24Saturn Overview

25. Initializing a Lock Use fresh boolean variable  Interpretation: –  is true ) L is locked – :  is true ) L is unlocked Enforces that L cannot be both locked and unlocked simultaneously 25Saturn Overview

26. Notation 26Saturn Overview (lock, state, guard) At program point P, the lock is in state if guard is true. P

27. node_state(P0,L,locked,LG):- entry(P0), is_lock(L), fresh_variable(L, LG). node_state(P0,L,unlocked,UG) :- entry(P0), node_state(P0,L,locked,LG), #not(LG, UG). Initialization Rules 27Saturn Overview f(..., lock *L,...) {... } (L, locked, LG) (L, unlocked, UG) Allocates new boolean variable associated with lock L. P0P0

28. 1. Initialize lock states at function entry 2. Join operator: – Combine edges to produce successor’s node_state 3. Transfer functions for every primitive: –assignments –tests –function calls The Intraprocedural Analysis 28Saturn Overview

29. node_state(P,L,S,G) :- edge_state(P,L,S,_), \/edge_state(P,L,S,EG):#or_all(EG,G). Joins Note: There is no abstraction in the join... 29Saturn Overview (L, locked, F 1 ) (L, locked, F 2 ) if (…) (L, locked, F 1 Ç F 2 )

30. 1. Initialize lock states at function entry 2. Join operator: – Combine edges to produce successor’s node_state 3. Transfer functions for every primitive: –assignments –function calls –etc. The Intraprocedural Analysis 30Saturn Overview

31. Assignments do not affect lock state: edge_state(P1,L,S,G) :- assign(P0,P1,_), node_state(P0,L,S,G). Assignments 31Saturn Overview X = E; P0P0 P1P1 (L, S, G)

32. Function summaries are the building blocks of interprocedural analysis. Generating a function summary requires: –Predicates encoding relevant facts –A session to store these predicates. Interprocedural Analysis Basics 32Saturn Overview

33. 1. Generating function summaries 2. Using function summaries –How do we retrieve the summary of a callee? –How do we map facts associated with a callee to the namespace of the currently analyzed function? Interprocedural Analysis Outline 33Saturn Overview

34. session sum_locking(FN:string) containing[lock_trans]. predicate lock_trans(L: t_trace, S0: lockstate, S1: lockstate). Summary Declaration 34Saturn Overview sum_locking Declares a persistent database sum_locking (function name) holding lock_trans facts

35. Summaries for lock and unlock: sum_locking("lock")->lock_trans(*arg0,locked,error) :-. sum_locking("lock")->lock_trans(*arg0,unlocked,locked) :-. sum_locking("unlock")->lock_trans(*arg0,unlocked,error) :-. sum_locking("unlock")->lock_trans(*arg0,locked,unlocked) :-. *arg0 is the memory location modified by lock and unlock Summary Generation: Primitives 35Saturn Overview

36. sum_locking(F)->lock_trans(L, S0, S1) :- current_function(F), entry(P0), node_state(P0, L, S0, G0), exit(P1), node_state(P1, L, S1, G1), #and(G0, G1, G), guard_satisfiable(G). Summary Generation: Other Functions 36Saturn Overview F(..., lock *L,...) {... } P0P0 P1P1 (L, S 0, G 0 ) (L, S 1, G 1 ) if SAT(G 1 Æ G 2 ), then... F: S 0 ! S 1 h

37. call_transfer(I, L, S0, S1, G) :- direct_call(I, F), call(P0, _, I), sum_locking(F)->lock_trans(CL, S0, S1), instantiate(s_call{I}, P0, CL, L, G). Summary Application Rule 37Saturn Overview G(...) { F(...) } F: S 0 ! S 1 P0P0 (S 0, L, G) (S 1, L, G)

38. Applications Bug finding Verification Software Understanding 38Saturn Overview

39. Saturn Bug Finding Early work –Locking Scalable Error Detection using Boolean Satisfiability. POPL 2005 –Memory leaks Context- and Path-Sensitive Memory Leak Detection. FSE 2005 –Scripting languages Static Detection of Security Vulnerabilities in Scripting Languages. 15 th USENIX Security Symposium, 2006 Recent work –Inconsistency Checking Static Error Detection Using Semantic Inconsistency Inference. PLDI 2007 39Saturn Overview

40. Examples: Null pointer dereferences ApplicationKLOCWarningsBugsFalse AlarmsFA Rate Openssl-0.9.8b3395547611.30% Samba-3.0.23b51668461929.20% Openssh-4.3p215598111.10% Pine-4.643721501192819.00% Mplayer-1.0pre8762119892823.90% Sendmail-8.13.836598111.10% Linux-2.6.17.162003732996618.10% Total879378361614919.50% 40Saturn Overview

41. Lessons Learned Saturn-based tools improve bug-finding –Multiple times more bugs than previous results –Lower false positive rate Why? –“Sounder” than previous bug finding tools bit-level modeling, handling casts, aliasing, etc. –Precise Fully intraprocedurally path-sensitive Partially interprocedurally path-sensitive Saturn Overview41

42. Lessons Learned (Cont.) Design of function summary is key to scalability and precision Summary-based analysis only looks at the relevant parts of the heap for a given function Programmers write functions with simple interfaces Saturn Overview42

43. Saturn Verification Unchecked user pointer dereferences –Important OS security property –Also called “probing” or “user/kernel pointers” Precision requirements –Context-sensitive –Flow-sensitive –Field-sensitive –Intraprocedurally path-sensitive 43Saturn Overview

44. Current Results for Linux-2.6.1 6.2 MLOC with 91,543 functions Verified 616 / 627 system call arguments –98.2% –11 false alarms Verified 851,686 / 852,092 dereferences –99.95% –406 false alarms 44Saturn Overview

45. Preliminary Lessons Learned Bug finders can be sloppy: ignore functions or points- edges that inhibit scalability or precision Soundness substantially more difficult than finding bugs Lightweight, sparsely placed annotations –Have programmers add some information –Makes verification tractable –Only 22 annotations need for user pointer analysis 45Saturn Overview

46. Saturn for Software Understanding A program analysis is a code search engine Generic question: Do programmers ever do X? –Write an analysis to find out –Run it on lots of code –Classify the results –Write a paper... 46Saturn Overview

47. Examples Aliasing is used in very stylized ways, at least in C –Cursors into data structures –Parent/child pointers –And 7 other idioms How is Aliasing Used in Systems Software? FSE 2006 Do programmers take the address of function ptrs? –Answer: Almost never. –Allows simpler analysis of function pointers 47Saturn Overview

48. Other Things We’ve Thought About Shape analysis –We notice the lack of shape information Interprocedural path-sensitivity –Needed for some common programming patterns Proving correctness of Saturn analyses 48Saturn Overview

49. Related Work Lots –All bug finding and verification tools of the last 10 years Particularly, though –Systems using logic programming (bddbddb) –ESP –Metal –CQual –Blast Saturn Overview49

50. saturn.stanford.edu Saturn Overview50