Software Verification With Blast

1
Software VerificationWith Blast

• Thomas A. Henzinger Ranjit Jhala Rupak
  Majumdar
• Grégoire Sutre
• UC Berkeley

2
Motivation

• Verification of systems code
• Locking disciplines
• Interface specifications
• Essential for correct operation
• High rate of bugs
• Temporal properties
• Require path-sensitive analysis
• Swamped by false positives
• Really hard to check

3
Specifying and Checking Properties of Programs

• Many (mature) techniques
• automated deduction
• program analysis
• type checking
• model checking
• Many projects
• Bandera, Blast, ESC-Java, FeaVer, JPF, LClint,
  OSQ, PolyScope, PREfix, SLAM, TVLA, Verisoft,
  xgcc,

• Goals
• defect detection
• partial validation
• Properties
• memory safety
• temporal safety
• security

4
Reliability Trust

• Reliability (verification)
• Check that the system is bug free
• Low level systems code
• Locking disciplines, interface specs,
• Temporal, path-sensitive properties
• Model checking

• Trust (certification)
• Questionable code written by third parties
• device drivers, mobile code
• Model checkers are buggy (!)
• Simply, efficiently checkable
• avoid redoing verification

5
Programming
Testing
BLAST
Code
6
Windows Device Drivers

• Kernel presents a very complex interface to
  driver
• stack of drivers
• NT kernel multi-threaded
• IRP completion, IRQL, plug-n-play, power
  management,
• Correct API usage described by finite state
  protocols
• Automatically check that clients respect these
  protocols

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

• Soundly and precisely check a program without
  annotations against API rules by
• creating a program abstraction
• exploring the abstractions state space
• refining the abstraction
• Scale such an approach to many 100kloc via
• Demand-driven analysis
• model checking

9
BLAST

• Input
• API usage rules
• client C source code as is
• Analysis
• create, explore and refine program abstractions
• Output
• Error traces
• Proofs of Correctness

10
Verification
11
Model Checking 101

• Keep searching successors until
• Hit error states report bug !
• Add no new successors report safe
• Could take a long time

Init
ERROR STATES
SYSTEMS STATE SPACE
12
Model Checking

• Doesnt scale to low level implementations
• Can only model check abstractions
• Requires human intervention
• Abstract Check Refine Loop
• Microsoft SLAM Project
• Clarke et. al. 00, Saidi 00

13
Model Checking Abstraction

• Partition the state space

• Existentially lift transition relation
  

14
Model Checking Abstraction

• Problem Abstraction too coarse
• Solution Refine abstraction

Init

ERROR STATES
15
Model Checking Abstraction

• Problem Abstraction too coarse
• Solution Refine abstraction

Init

ERROR STATES
16
Abstract-Check-Refine Loop
Abstract
Is model unsafe ?
Check
Refine
Why infeasible ?
Infeasible
17
Abstract Only Where Required

• Abstraction is very expensive
• Why abstract regions that are never visited ?

• On-the-fly abstraction driven by the search

Init
ERROR STATES
18
Refine Only Where Required

• Why be precise everywhere ?
• Dont refine error-free regions

Init
ERROR STATES
ERROR FREE

19
Refine Only Where Required

• Why be precise everywhere ?
• Dont refine error-free regions

• Different precision for different regions
• Local Refinement driven by the search

Init
ERROR STATES
ERROR FREE

20
Benefits of Lazy Abstraction

• Abstract only where required
• Reachable state space maybe very sparse
• Construct the abstraction on-the-fly
• Use greater precision only where required
• Different precisions/abstractions for different
  regions
• Refine locally
• Reuse work from earlier phases
• Batch-oriented ) lose work from previous runs
• Integrate the three phases

21
Example
Example ( ) 1 do lock()
old new 2 if () 3
unlock() new
4 while ( new ! old) 5
unlock () return
Q Is Error Reachable ?
22
ExampleCFA
lock() old new
Example ( ) 1 do lock()
old new 2 if () 3
unlock() new
4 while ( new ! old) 5
unlock () return

23
ExampleCFA
Example ( ) 1 do lock()
old new 2 if () 3
unlock() new
4 while ( new ! old) 5
unlock () return
Q Is Error Reachable ?
24
Step 1 Search
1
LOCK0
lock() old new
gt
unlock()
Set of predicates LOCK0, LOCK1
25
Step 2 Analyze Counterexample
Q When can
States at node n Rn
Err
LOCK0
26
Step 2 Analyze Counterexample
lock() old new
LOCK0 Æ new old
newold
LOCK0
unlock()
27
Step 2 Analyze Counterexample
LOCK0 Æ new1 new
LOCK1 Æ new1 old
LOCK1 Æ new 1 old
LOCK0 Æ new old
LOCK0
Track the predicate new old
LOCK0
28
Step 3 Resume Search
lock() old new
newold
new!old
Set of predicates LOCK0, LOCK1, new old
29
Step 3 Resume Search
Set of predicates LOCK0, LOCK1, new old
LOCK0 Æ new old
30
Local Refinement
Example ( ) 0 if () 6 do
got_lock 0 7 if
() 8 lock()
got_lock 9
if (got_lock) 10
unlock() 11 while
() 1 do lock()
old new 2 if () 3
unlock() new
4 while ( new ! old) 5
unlock () return
6 do got_lock 0 7
if () 8
lock() got_lock
9 if (got_lock) 10
unlock() 11
while ()
1 do lock()
old new 2 if () 3
unlock() new
4 while ( new ! old) 5 unlock ()
return
31
Local Refinement
Search on left subtree not repeated
Different abstractions for subtrees
Refine right subtree only
32
Leaves Covered (Reuse work)
0
Leaves covered Avoid repeating search
when paths merge
LOCK0 Æ
COVERED !
33
Technical Details
34
Predicate Abstraction
Region Representation formulas over predicates
Set of states
Abstract Set P1P2P4 Ç P1 P2 P3 P4
35
Predicate Abstraction

• Box abstract variable valuation
• BoxCover(S) Set of boxes covering S
• Theorem prover used to compute BoxCover

36
Post, Pre
post
post(S)
post(S)

• pre(S,op) s 9s2S. s !op s (Weakest
  Precondition)
• post(S,op) s 9s2S. s !op s (Strongest
  Postcondition)
• Abstract Operators post
• post(S,op) µ post(S,op)
• Concrete Operators pre
• Classical Weakest Precondition

37
Computing Post
post
post(S)
post(S)

• For each predicate p, check if
• S) Pre(p, op) then have a conjunct p
• S) Pre( p, op) then have a conjunct p
• Else have no conjunct corresponding to p
• Use a theorem prover for these queries

38
Predicate Discovery

• Information lost in substitution
• Keep substitutions explicit
• Ask a proof of unsatisfiability
• Pick predicates appearing in proof

39
Predicate Discovery
Weakest Precondition wp(Y, xe) Y e/x
Explicit WP wp(Y, xe) 9 x. x e Æ Y
x/x
LOCK 0 Æ 9 old new LOCK. old
new Æ LOCK0 Æ new old Æ new
new 1
New Predicates from proof of unsatisfiability
old new, new old, new new 1
40
Certification
41
What is a Certificate ?

• Proof Carrying Code (PCC)

• Annotations
• Loop invariants, func. Precondition/Postcondition

• Validity of VC guarantees correctness

• Certificate Annotations Proof of VC
• Consumer reconstructs VC, checks proof

42
Annotations VCs

• Annotations
• For each cntrl location q, invariant I(q)
• Verification condition
• Init µ I(q0)

Start set includes initial states
Error location is not reached

• I(qe) false

• For each edge q !op q
• POST(I(q),op) µ I(q)

States closed under post
43
Invariants grow on Trees
1
LOCK0
Ç LOCK0 Æ new old
LOCK0 Æ new old
4
Ç LOCK1 Æ newold
5
LOCK1 Æ newold
Invariants
44
Proving the VC

• Each condition dischargeable automatically
  (Vampyre, CVC )
• Tree yields a small decomposition
• Entire proof can be extracted from model
  checkers data structures

45
Implementation
46
BLAST

• Berkeley Lazy Abstraction Software verification
  Tool
• 10K Lines of Ocaml
• Analyze Linux/Windows Device Drivers

LAZY ABSTRACTION
47
BLAST

• All of C modeled except
• Function pointers
• Recursive functions
• Logical Model of memory
• Pointer arithmetic imprecise
• Fragile on heap dependant properties
• Safety checking
• Checks if a given label is reachable in the C
  program
• Monitor automata specified in C

48
Experiments
Prf Size (bytes)
Total Time(sec)
Active Preds
Total Preds
Lines
Program
Pred. Disc. Time(sec)
253
0.01
4.5
5
5
18131
ide.c
Linux Lock 3 state
179
0.01
0.5
2
2
23539
qpmouse.c

0.03
20.93
2
2
17736
aha152x.c

403.33
428.63
4
5
16506
tlan.c
156787
540
1398
45
85
17798
cdaudio.c

1565
2086
37
62
17386
floppy.c
60129
17
395
44
93

fixed

5
64
40
54
12131
kbflter.c
Windows DDK IRP 22 state

165
256
35
48
7619
0.38
10
34
37
fixed

3.34
54
46
57
17372
mouclass.c
102967
519
1980
50
193
61781
parport.c
49
start NP
CallDriver
SKIP2
SKIP1
return child status
Skip
IPC
CallDriver
synch
MPR3
NP
CallDriver
prop completion
PPC
not pending returned
MPR completion
Complete request
CallDriver
MPR1
MPR2
DC
return not Pend
no prop completion
synch
CallDriver
N/A
N/A
IRP accessible
CallDriver
start P
SKIP2
Mark Pending
SKIP1
Skip
IPC
CallDriver
synch
MPR3
NP
CallDriver
return Pending
prop completion
PPC
not pending returned
MPR completion
Complete request
CallDriver
MPR1
MPR2
DC
no prop completion
CallDriver
N/A
50
Why Does this Work ?

• Reach set is very sparse
• Abstract on-the-fly
• Only the reachable region
• Requires very fast post
• Exploit Control-Flow Structure
• Free partitioning of state space
• Partition preds different abstractions
• Refine locally dont repeat old work

51
Techniques

• Model checking
• predicate abstraction
• counterexample-driven refinement
• symbolic model checking
• Program analysis
• abstract interpretation
• points-to analysis
• data flow analysis
• slicing optimizations

• Automated deduction
• weakest preconditions
• theorem proving
• Proof generation
• PCC
• Software
• CIL Infrastructure
• Pointer Analysis
• CU BDD
• Simplify, Vampyre
• OCAML

52
Conclusions

• Lazy Abstraction
• Reachability Tree yields certificate
• Implemented BLAST
• Finds (only) real bugs in large device drivers
• and gives proofs for correct ones !

• Future work
• Smarter abstractions
• Program analysis for model reduction
• Modeling heap properties (induction?)

53
BLAST Reading List

• Henzinger, Jhala, Majumdar, Sutre. Lazy
  Abstraction, POPL 2002.
• Henzinger, Jhala, Majumdar, Necula, Sutre,
  Weimer, CAV 2002.
• SLAM Ball, Rajamani, POPL 2002.
• Predicate Abstraction Graf Saidi, CAV 1997 Ball
  Majumdar Millstein Rajamani, PLDI 2001, Qadeer
  Flanagan, POPL 2002.
• PCC Necula, POPL 1997.

54
BLAST
Berkeley Lazy Abstraction Software Tool
www.eecs.berkeley.edu/tah/blast/