SLAM Over the Summer Wes Weimer (Tom Ball, Sriram Rajamani, Manuvir Das)

SLAM in 60 seconds Question: does program meet safety policy? –If not, give a counter-example 1. Instrument C program with policy 2. Abstract C program to boolean program 3. Model-check boolean program 4. Is resulting error trace feasible? 5. If not, refine abstraction, goto 2

C program Boolean program c2bp bebop Fail, p Pass newton GOLF SLIC CFG + VFG predicates Error GUI Spec. predicates

The Cunning Plan Study SLAM termination Make SLAM scale to real programs Come up with interesting specifications Run SLAM on device drivers Find bugs Retire to a life of luxury, resting on laurels

SLAM Termination If abstract interpretation with widening terminates, will SLAM with widening terminate as well? Answer: Yes. Andreas Podelski finished this before I arrived …

5 Secrets to Scaling SLAM Don’t fork() 1 theorem prover per query Don’t cache theorem prover results Do cache theorem prover results (even between iterations) Do store the CFG, don’t re-parse Don’t use algorithms that require exponential stack space

Specify, specify, specify SLAM specifications (“slic”) –are like monitors –instrument function calls, returns –can mimic a sort of type state A week or two after I arrived, Manuel Fandrich wrote up a lovely IO spec

MPR3 CallDriver MPR completion synch not pending returned SKIP2 IPC CallDriver Skip return child status DC Complete request return not Pend PPC prop completion CallDriver N/A no prop completion CallDriver start NP return Pending NP MPR1 MPR completion SKIP2 IPC CallDriver DC Complete request PPC prop completion CallDriver N?A no prop completion CallDriver start P Mark Pending IRP accessible N/A synch SKIP1 CallDriver SKIP1 Skip MPR2 MPR1 NP MPR3 CallDriver not pending returned MPR2 synch

SLAMzilla vs. moNThra “Classic” SLAM does not scale –25 iterations on floppy.c (for a simpler spec) –each iter adds a few predicates, repeats work –see “Lazy Abstraction” / BLAST project “Classic” SLAM vs. NT: either SLAM –has an internal error –fails to terminate –exhausts virtual memory

Iterative Predicate Generation Normally SLAM starts with all predicates mentioned in the spec Must rediscover “unintersting” predicates Example: x = y; if (x == FAILURE) abort(); One iteration just to get “ y == FAILURE ”

Value Flow Idea Run some Value Flow algorithm on instrumented program See what values can flow into final important “ if ” statements Generate those predicates in advance Rejoice as SLAM actually terminates

The Magic Bullet Theory For a restricted subset of C Find enough predicates So that SLAM terminates correctly In just 1 iteration If real program not in restricted subset of C, iterate to find remaining predicates

How restricted? v 1 = v 2 v = i// (i  Z) if (*) stmt 1 else stmt 2 v 1 = fun(v 2, …) return v abortif(v 1  v 2 )// some relop sometimes v 1 = v 2  v 3 // some binops

“Simple” Example foo(int a, int b) abortif(a  b) pick(int s) int v; if (*) v = s; else v = 4; return v bar(int c, int d) int p,q; p = c; q = d; foo(p,q) main() int x,y,z; x = 2; x = 3; y = 5; y = pick(3); z = x; bar(z,y);

Value Flow Graph xz sv c y p d a qb Recall the goal: Decide if a  b

The Lofty Ideal If we knew the final values of a and b (e.g., “3” and “5”) we could decide a  b Walk back in the graph from a Take every edge “x  z”, “2  x” Add the predicates “x == z”, “2 == x” Do the same for b Voila!

Theory and Practice xz sv c y p d a qb p==a c==p z==c x==z 2==x 3==x Let’s try it on the a branch …

The Root of the Problem xz sv c y p d a qb p==a// Bad (no scope) c==p // OK z==c // Bad (no scope) x==z // OK 2==x // OK 3==x // OK Let’s try it on the a branch …

Scoping Things Out There is no scope in which “z == c” is a valid predicate. But this predicate is necessary! Solution: link all ground terms to c bar(int c, int d) int p,q; p = c; q = d; foo(p,q) main() int x,y,z; x = 2; x = 3; y = 5; y = pick(3); z = x; bar(z,y);

Value Flow Revised xz sv c y p d a qb Red  represents function calls and returns (crossing scopes)

Value Flow Fixup xz sv c y p d a qb Concentrating just on z  c, conceptually add 3  c and 2  c, thus adding “3==c” and “2==c”

Fixup Bonanza xz sv c y p d a qb

Why does it work? There is no scope in which “z == c” is a valid predicate. However… If we know “z==2” or “z==3” We can easily prove “c==2” or “c==3” at the call-site And “c==2 & z==2” implies “c==z” bar(int c, int d) int p,q; p = c; q = d; foo(p,q) main() int x,y,z; x = 2; x = 3; y = 5; y = pick(3); z = x; bar(z,y);

This is Weak It relies on having a constant, finite set of “ground terms” (like “2” and “3”) It will generate many more predicates than necessary (it ignores control-flow) a  b only works if the result is a ground term that reaches a or b (e.g., no *p) But we have iteration to pick up the pieces

Extensions If we know more about the predicate a  b, we can do better: a  b, a < b, etc. –Run algorithm as before, generate “x  5” instead of “x == 5”, keep “v i == v j ” a = 5 –Run algorithm as before, ignore actual set of ground terms, always generate “v i == 5”

Variable Equality (a==b) xz sv c y p d a qb Consider the intersection of the ground terms: “a==3” and “b==3”, etc., should suffice, right? Sadly, no.

Results?  Floppy driver (1 bug) (3 iterations instead of 25)  6500 lines, simple spec  21 global predicates  741 local predicates  72 max local in scope  Battery driver (2 bugs) (8 iterations instead of crashing)  2410 lines, that complex spec  18 global predicates  137 local predicates  24 max local in scope

SLAM-PCC Perhaps not of general interest Verify bprog=c2bp(preds,cprog) –requires O(|CFG|*2 |preds| ) proofs Verify final result: –Standard VCGen(cprog,property) –Get loop invariants, function pre-post from model checker

Questions?