Specifying and Checking Properties of Programs

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 Turings 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 doesnt
  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-EmersonQuille-Sifakis in
  the early 80s
• Had a breakthrough with Ken McMillans 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 state1..2
• int turn
• init
• state1 N state2 N
• turn 0
• trans
• statei N turn 0 -gt statei
  T turn i
• statei N turn !0 -gt statei
  T
• statei T turn i -gt statei
  C
• statei C state2-i N -gt statei
  N
• statei C state2-i ! N -gt statei
  N turn 2-i

15
N1,N2 turn0
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 Nelsons 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 Nelsons work
  are widely used
• ESC
• Proof Carrying Code

18
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)

19

• a array 1..len of int
• int max -MAXINT
• i 1
• ? 1 ? j ? i. aj ? max
• while (i ? len)
• if( ai gt max)
• max ai
• i i1
• endwhile
• ? 1 ? j ? len. aj ? max

( ? 1 ? j ? i. aj ? max) ? ( i gt len) ? (?
1 ? j ? len. aj ? 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
Computing power doubles every 18
months -Gordon Moore

• An optimizing compiler doubles performance every
  18 years
• -Todd Proebsting

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

• Use program analysis and automated theorem
  proving for model extraction
• User annotations simplify the model extraction
  problem
• Use model checking on the model

Intent
Model
Code
28
Some current projects

• Software productivity tools (MSR)
• SLAM, Vault, ESP, Behave!
• Stanford MC project
• Berkeley Open Source Quality
• KSUs Bandera
• IBMs CANVAS
• SRI Symbolic analysis laboratory (SAL )
• Verimag IF language and Tool Set
• NASA Ames JavaPathfinder
• Compaq SRCs 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 dont 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