Use of Models in Analysis and Design

1. Use of Models in Analysis and Design Sriram K. Rajamani Rigorous Software Engineering Microsoft Research, India

2. Models • Abstractions of reality • All branches of science and engineering use models. Some examples: • Differential equations • State machines • Models enable conquering complexity • Allow focus on one issue at a time, while ignoring others

3. Models in software engineering • Mainstream mantra: • “Code is truth, and only truth” • Models are used, but not widely • Requirements capturing (UML): • Used specialized domains: telcom, automotive, embedded sytstems • Development tools: • Testing and verification • Design • Model driven development

4. This talk • Use of models in analysis and design • Personal experience • Analysis: • Extracting analyzable models from source code using iterative refinement • Design: • My assessment of state of the art and important research problems

5. Models in Analysis

6. Software Validation • Large scale reliable software is hard to build and test. • Different groups of programmers write different components. • Integration testing is a nightmare.

7. Property Checking • Programmer provides redundant partial specifications • Code is automatically checked for consistency • Different from proving whole program correctness • Specifications are not complete

8. Interface Usage Rules • Rules in documentation • Incomplete, unenforced, wordy • Order of operations & data access • Resource management • Disobeying rules causes bad behavior • System crash or deadlock • Unexpected exceptions • Failed runtime checks

9. Does a given usage rule hold? • Checking this is computationally impossible! • Equivalent to solving Turing’s halting problem (undecidable) • Even restricted computable versions of the problem (finite state programs) are prohibitively expensive

10. Why bother? Just because a problem is undecidable, it doesn’t go away!

11. Automatic property checking = Study of tradeoffs • Soundness vs completeness • Missing errors vs reporting false alarms • Annotation burden on the programmer • Complexity of the analysis • Local vs Global • Precision vs Efficiency • Space vs Time

12. Broad classification • Underapproximations • Testing • After passing testing, a program may still violate a given property • Overapproximations • Type checking • Even if a program satisfies a property, the type checker for the property could still reject it

13. Current trend • Confluence of techniques from different fields: • Model checking • Automatic theorem proving • Program analysis • Significant emphasis on practicality • Several new projects in academia and industry

14. Model Checking • Algorithmic exploration of state space of the system • Several advances in the past decade: • symbolic model checking • symmetry reductions • partial order reductions • compositional model checking • bounded model checking using SAT solvers • Most hardware companies use a model checker in the validation cycle

15. enum{N, T, C} state[1..2] int turn init state[1] = N; state[2] = N turn = 0 trans state[i]= N & turn = 0 -> state[i] = T; turn = i state[i] = N & turn !=0 -> state[i] = T state[i] = T & turn = i -> state[i] = C state[i] = C & state[2-i] = N -> state[i] = N state[i] = C & state[2-i] != N -> state[i] = N; turn = 2-i

16. T1,N2 turn=1 N1,T2 turn=2 C1,N2 turn=1 N1,C2 turn=2 T1,T2 turn=1 T1,T2 turn=2 C1,T2 turn=1 T1,C2 turn=2 N1,N2 turn=0 N = noncritical, T = trying, C = critical

17. Model Checking • Strengths • Fully automatic (when it works) • Computes inductive invariants • I such that F(I)  I • Provides error traces • Weaknesses • Scale • Operates only on models • How do you get from the program to the model?

18. Theorem proving • Early theorem provers were proof checkers • They were built to support asssertional reasoning in the Hoare-Dijkstra style • Cumbersome and hard to use • Greg Nelson’s thesis in early 80s paved the way for automatic theorem provers • Theory of equality with uninterpreted functions • Theory of lists • Theory of linear arithmetic • Combination of the above ! • Automatic theorem provers based on Nelson’s work are widely used • ESC • Proof Carrying Code

19. Theory of Equality. • Symbols: =, ¹, f, g, … • Axiomatically defined: • Example of a satisfiability problem: • g(g(g(x)) = x  g(g(g(g(g(x))))) = x  g(x) ¹ x • Satisfiability problem decidable in O(n log n)

20. a : array [1..len] of int; int max := -MAXINT; i := 1; {  1  j  i. a[j]  max} while (i  len) if( a[i] > max) max := a[i]; i := i+1; endwhile {  1  j  len. a[j]  max} • (  1  j  i. a[j]  max) •  ( i > len) •  • ( 1  j  len. a[j]  max}

21. Automatic theorem proving • Strengths • Handles unbounded domains naturally • Good implementations for • equality with uninterpreted functions • linear inequalities • combination of theories • Weaknesses • Hard to compute fixpoints • Requires inductive invariants • Pre and post conditions • Loop invariants

22. Program analysis • Originated in optimizing compilers • constant propagation • live variable analysis • dead code elimination • loop index optimization • Type systems use similar analysis • Are the type annotations consistent?

23. Program analysis • Strengths • Works on code • Pointer aware • Integrated into compilers • Precision efficiency tradeoffs well studied • flow (in)sensitive • context (in)sensitive • Weakenesses • Abstraction is hardwired and done by the designer of the analysis • Not targeted at property checking (traditionally)

24. Model Checking, Theorem Proving and Program Analysis • Very related to each other • Different histories • different emphasis • different tradeoffs • Complementary, in some ways • Combination can be extremely powerful

25. What is the key design challenge in a model checker for software? It is the model!

26. Model Checking Hardware Primitive values are booleans States are boolean vectors of fixed size Models are finite state machines !!

27. Characteristics of Software Primitive values are more complicated • Pointers • Objects Control flow (transition relation) is more complicated • Functions • Function pointers • Exceptions States are more complicated • Unbounded graphs over values Variables are scoped • Locals • Shared scopes Much richer modularity constructs • Functions • Classes

28. Traditional approach model checker FSM Finite state machines Source code Sequential C program

29. Automatic abstraction SLAM model checker Data flow analysis implemented using BDDs Finite state machines Push down model Boolean program FSM abstraction C data structures, pointers, procedure calls, parameter passing, scoping,control flow Source code Sequential C program

30. Computing power doubles every 18 months -Gordon Moore An optimizing compiler doubles performance every 18 years -Todd Proebsting

31. When I use a model checker, it runs and runs for ever and never comes back… when I use a static analysis tool, it comes back immediately and says “I don’t know” - Patrick Cousot

32. Read for understanding Drive testing tools Precise API Usage Rules (SLIC) New API rules Defects Software Model Checking 100% path coverage Rules Static Driver Verifier Development Testing Source Code

33. SLAM – Software Model Checking • SLAM innovations • boolean programs: a new model for software • model creation (c2bp) • model checking (bebop) • model refinement (newton) • SLAM toolkit • built on MSR program analysis infrastructure

34. SLIC • Finite state language for stating rules • monitors behavior of C code • temporal safety properties • familiar C syntax • Suitable for expressing control-dominated properties • e.g. proper sequence of events • can encode data values inside state

35. Locking Rule in SLIC state { enum {Locked,Unlocked} s = Unlocked; } KeAcquireSpinLock.entry { if (s==Locked) abort; else s = Locked; } KeReleaseSpinLock.entry { if (s==Unlocked) abort; else s = Unlocked; } State Machine for Locking Rel Acq Unlocked Locked Rel Acq Error

36. The SLAM Process boolean program c2bp prog. P prog. P’ slic bebop SLIC rule predicates path newton

37. Example Does this code obey the locking rule? do { KeAcquireSpinLock(); nPacketsOld = nPackets; if(request){ request = request->Next; KeReleaseSpinLock(); nPackets++; } } while (nPackets != nPacketsOld); KeReleaseSpinLock();

38. Example Model checking boolean program (bebop) do { KeAcquireSpinLock(); if(*){ KeReleaseSpinLock(); } } while (*); KeReleaseSpinLock(); U L L L U L U L U U E

39. Example Is error path feasible in C program? (newton) do { KeAcquireSpinLock(); nPacketsOld = nPackets; if(request){ request = request->Next; KeReleaseSpinLock(); nPackets++; } } while (nPackets != nPacketsOld); KeReleaseSpinLock(); U L L L U L U L U U E

40. Example Add new predicate to boolean program (c2bp) b : (nPacketsOld == nPackets) do { KeAcquireSpinLock(); nPacketsOld = nPackets;b = true; if(request){ request = request->Next; KeReleaseSpinLock(); nPackets++;b = b ? false : *; } } while (nPackets != nPacketsOld); !b KeReleaseSpinLock(); U L L L U L U L U U E

41. Example Model checking refined boolean program (bebop) b : (nPacketsOld == nPackets) do { KeAcquireSpinLock(); b = true; if(*){ KeReleaseSpinLock(); b = b ? false : *; } } while ( !b); KeReleaseSpinLock(); U L b L b L b U b !b L U b L U b U E

42. Example Model checking refined boolean program (bebop) b : (nPacketsOld == nPackets) do { KeAcquireSpinLock(); b = true; if(*){ KeReleaseSpinLock(); b = b ? false : *; } } while ( !b); KeReleaseSpinLock(); U L b L b L b U b !b L U b L b U

43. Observations about SLAM • Automatic discovery of invariants • driven by property and a finite set of (false) execution paths • predicates are not invariants, but observations • abstraction + model checking computes inductive invariants (boolean combinations of observations) • A hybrid dynamic/static analysis • newton executes path through C code symbolically • c2bp+bebop explore all paths through abstraction • A new form of program slicing • program code and data not relevant to property are dropped • non-determinism allows slices to have more behaviors

44. Current status of SDV • Runs on 100s of Windows drivers • Finds several bugs, proves several properties • SDV now transferred from MSR to Windows division • Used to check several DDK and inbox drivers • Beta Released at WINHEC 2005!

45. Static Driver Verifier

46. Static Driver Verifier • Driver: Parallel port device driver • Rule: Checks that driver dispatch routines do not call IoCompleteRequest(…) twice on the I/O request packet passed to it by the OS or another driver