1. Specifying and Checking Properties of Programs Thomas Ball Sriram K. Rajamani Software Productivity Tools Microsoft Research

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

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

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

5. Example: Sockets the "communication domain" in which communication is to take place; see protocols(5). Sockets of type SOCK_STREAM are full-duplex byte streams, similar to pipes. A stream socket must be in a connected state before any data may be sent or received on it. A con- nection to another socket is created with a connect(2) call. Once connected, data may be transferred using read(2V) and write(2V) calls or some variant of the send(2) and recv(2) calls. When a session has been completed a close(2V), may be performed. Out-of-band data may also be transmitted as described in send(2) and received as described in recv(2). The communications protocols used to implement a SOCK_STREAM insure that data is not lost or duplicated. If a piece of

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

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

8. Scientific curiosity Undecidability and complexity theory are the most significant contributions of theoretical computer science. Software property checking, a very practical and pressing problem is undecidable.

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

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

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

12. Outline Property checking of software Undecidable Important Techniques –Model checking –Automatic theorem proving –Program analysis Current projects

13. Model Checking Algorithmic exploration of state space of the system Started by [Clarke-Emerson][Quille-Sifakis] in the early 80s Had a breakthrough with Ken McMillan’s thesis in 92 (symbolic model checking with Binary Decision Diagrams) Several advances: symmetry reductions, partial order reductions, compositional model checking Most hardware companies use a model checker in the validation cycle

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

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

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

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

18. Theory of Equality. Symbols: =, , f, g, … Axiomatically defined: E = E E 2 = E 1 E 1 = E 2 E 1 = E 2 E 2 = E 3 E 1 = E 3 E 1 = E 2 f(E 1 ) = f(E 2 ) 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)

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

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

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

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

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

24. Model Checking, Theorem Proving and Program Analysis –Very related to each other –Different histories different emphasis different tradeoffs – Complementary, in some ways

25. Outline Property checking of software Undecidable Important Techniques –Model checking –Automatic theorem proving –Program Analysis Current projects

26. Industrial successes with software validation PREfix –Statically simulate a small number of paths symbolically inside each function theorem proving with under-approximations –Scale by “summarizing” at function boundaries –Works on Windows NT (several million lines of code) Other projects –ESC project at Compqq SRC –SPIN model checker and the Feaver project at Bell Labs –Verisoft model checker at Bell labs

27. Current trend.. Code Intent Model Use program analysis and automated theorem proving for model extraction User annotations simplify the model extraction problem Use model checking on the model

28. Some current projects -Software productivity tools (MSR) -SLAM, Vault, ESP, Behave! -Stanford MC project -Berkeley Open Source Quality -KSU’s Bandera -IBM’s CANVAS -SRI Symbolic analysis laboratory (SAL ) -Verimag IF language and Tool Set -NASA Ames’ JavaPathfinder -Compaq SRC’s ESC-Java -Bell Labs’ Verisoft and FeaVer -UMass Amherst LASER

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

30. Predictions –The holy grail of full program verification has been abandoned. It will probably remain abandoned – Less ambitious tools like powerful type checkers will emerge and become more widely used –These tools will exploit ideas from various analysis disciplines –Tools will alleviate the “chicken-and-egg” problem of writing specifications