Saturn Overview1 An Overview of the Saturn Project

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

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

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 cores to analyze Linux

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Specification Saturn Overview20 locked unlocked error unlock lock unlock lock

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

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

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

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

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

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

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

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

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 )

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

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)

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

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

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

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

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

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)

Applications Bug finding Verification Software Understanding 38Saturn Overview

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 Saturn Overview

Examples: Null pointer dereferences ApplicationKLOCWarningsBugsFalse AlarmsFA Rate Openssl-0.9.8b % Samba b % Openssh-4.3p % Pine % Mplayer-1.0pre % Sendmail % Linux % Total % 40Saturn Overview

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

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

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

Current Results for Linux 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

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

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

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

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

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

saturn.stanford.edu Saturn Overview50