1. Software Verification via Refinement Checking Sagar Chaki, Edmund Clarke, Alex Groce, CMU Somesh Jha, Wisconsin

2. Motivation Refinement mappings exist between real code and specifications Potentially cheaper than model checking -Simulation vs. Trace containment Refinement mappings are like proofs

3. Specifications Expressed as Finite Labeled Transition Systems (FLTS) -Locking protocols We use the FSP syntax to describe FLTSs -Concurrency: State Models and Java Programs – Jeff Magee, Jeff Kramer - Wiley

4. Specification: LockUnlock U = (lock -> L | return -> S), L = (unlock -> U). UL lock unlock S return

5. Implementation: Device driver void example() { do { KeAcquireSpinLock();//event lock nPackets = nPacketsOld; if(cond) { KeReleaseSpinLock();//event unlock nPackets++; } } while(nPackets != nPacketsOld); KeReleaseSpinLock();//event unlock }

6. Our Goal To show that Driver refines LockUnlock -Need to keep track of the predicate (nPackets == nPacketsOld) -Data-insensitive analysis will fail Provide diagnostic feedback in case the simulation does not exist

7. Specification: POSIX pthread pthread_mutex_lock() -Acquires lock and returns 0 -Increments user count on lock and returns 0 -Returns non-zero error code S0 S1 S3 S2 ret_err ret_zero lock inc_count

8. Implementation: Glibc pthread int pthread_mutex_lock() { case PTHREAD_MUTEX_RECURSIVE_NP: self = thread_self(); if (mutex->__m_owner == self) { mutex->__m_count++;// inc_count return 0;// ret_zero } pthread_lock(&mutex->__m_lock, self);// lock mutex->__m_owner = self; mutex->__m_count = 0; return 0; }// ret_zero

9. Implementation Collection of C procedure definitions -The pthread library Designated main procedure -The pthread_mutex_lock function -We are interested in behavior observed during an invocation of main

10. Implementation For each procedure called, one of two things must be available -Definition of procedure -Information about behavior observed during invocation of procedure

11. Verification Check that every possible behavior of main is also a behavior of the FLTS -Trace-containment In practice it is sufficient to check for a stronger condition viz. simulation -FLTS ≥ main

12. FLTS: Definition Fix an alphabet: Σ -Assume Σ contains special symbol ε Three-tuple: -Q: finite set of states -I: initial state -δ: transition relation over Q X Σ X Q

13. Example U’ L’ lock S’ return V’ ε M’ ε unlock

14. Simulation FLTSs:, Relation ≥ Q1 X Q2 is simulation if (1)Init: For all t Є I2 exists s Є I1 s.t. s ≥ t (2)Step: s ≥ t and (t,a,t’) Є δ2 => exists s’ s.t. (s,a,s’) Є δ1 and s’ ≥ t’ (3)Stutter: s ≥ t and (t,ε,t’) Є δ2 => s ≥ t’ OR exists s’ s.t. (s,ε,s’) Є δ1 and s’ ≥ t’

15. Overall method Step 1: Compute relation R that satisfies conditions 2 and 3 Step 2: Check that R satisfies condition 1 as well

16. Step 1 Start with R = Q1 X Q2 Iteratively refine R using condition 2 and 3 till a fixed point is reached -If (s,t) Є R and if (t,a,t’) Є δ2 then remove (s,t) if there does not exist s’ s.t. (s,a,s’) Є δ1 and (s’,t’) Є R

17. Example U’ L’ lock S’ return V’ ε M’ ε unlock {U,L,S} lock UL unlock S return

18. Example U’ L’ lock S’ return V’ ε M’ ε unlock {U} {U,L,S} lock UL unlock S return

19. Example U’ L’ lock S’ return V’ ε M’ ε unlock {U} {U,L,S} lock UL unlock S return

20. Example U’ L’ lock S’ return V’ ε M’ ε unlock {U} {U,L,S} {L} {U,L,S} lock UL unlock S return

21. Example U’ L’ lock S’ return V’ ε M’ ε unlock {U} {L} {U,L,S} lock UL unlock S return

22. FLTS from C module Based on a set of predicates Each state of the FLTS consists of a control location of the C module and a valuation to the predicates -Non-context-sensitive Weakest preconditions and theorem proving are used to compute the transitions on-the-fly

23. Example void example() { do { KeAcquireSpinLock(); nPackets = nPacketsOld; if(cond) { KeReleaseSpinLock(); nPackets++; } } while(nPackets != nPacketsOld); KeReleaseSpinLock(); } Θ : nPackets == nPacketsOld Θ’ Θ Θ Θ Θ Θ Θ Θ Θ Θ Θ Θ Loc Unl Ret

24. Challenges Extract event information from C code Provide diagnostic feedback in case simulation is not found Pointers and dynamic memory allocation Introduce context-sensitivity Introduce concurrency

25. Predicates and Property Need to specify predicates to be used -predicate (nPackets == nPacketsOld); Need to specify the simulation relation to be checked -property U simulates example;

26. Additional Info Specify that call to KeAcquireSpinLock() represents a locking action -action call KeAcquireSpinLock = lock; Similarly for KeReleaseSpinLock() -action call KeReleaseSpinLock = unlock;

27. Using Static Analysis Mostly for alias information -Predicate : (x == 4) -Assignment : *y = 5; -WP: ((y == &x)&&(5 == 4)) || ((y != &x)&&(x==4)) -Static analysis could tell us whether (y == &x) before this assignment statement -x = (*y)(100); -What procedures could y potentially point to

28. Java Java source -Object-oriented-ness Java bytecode -Stack based -Need to finitise the state, perhaps by imposing a upper bound on the stack size

29. Refinements as Proofs Class loader obtains bytecode with the spec, refinement relation and set of predicates Checks that the refinement really is valid using the predicates Loads class only if the check passes

30. Refinements as Proofs Tradeoff between bandwidth and computation -Supply just the predicates and let the loader compute the refinement relation -Supply the refinement so that loader just has to check its validity Can we do this for the Linux process loader -Doubtful 

31. Related Work Based on predicate abstraction -Graf & Saidi, Dill et. al. Do not work with C -SLAM, Bandera Specify desired behavior as patterns, or unwanted behavior as monitors -Engler et. al., SLAM, Bandera

32. Major Differences Unlike Engler et. al. -Flow-sensitive, based on predicates -Check arbitrary regular behavior Unlike SLAM -On-the-fly: no boolean programs -Not context-sensitive Unlike Bandera -Work with C -Check arbitrary regular behavior