Automating Verification of Software - PowerPoint PPT Presentation

About This Presentation
Title:

Automating Verification of Software

Description:

Lemma 1: If a safe invariant can be expressed in terms of predicates in P then ... Lemma 2: For any guarded command c, prec( ') = prec( ) prec( ') prec ... – PowerPoint PPT presentation

Number of Views:39
Avg rating:3.0/5.0
Slides: 83
Provided by: Thoma352
Category:

less

Transcript and Presenter's Notes

Title: Automating Verification of Software


1
(No Transcript)
2
Automating Verification of Software
  • Remains a grand challenge of computer science
  • Behavioral abstraction is central to this effort
  • abstractions simplify our view of program
    behavior
  • proofs over the abstractions carry over to proofs
    over the program

3
Reachability
unsafe
unsafe
init
4
Safe Invariants
  • Q is a safe invariant if
  • init ? Q
  • T(Q) ? Q
  • Q ? safe

5
Abstraction Overapproximation of Behavior
Q
unsafe
Q
T(Q)
init
6
More Concretely
do KeAcquireSpinLock() nPacketsOld
nPackets if(request) request
request-gtNext KeReleaseSpinLock() nPackets
while (nPackets ! nPacketsOld) KeRelease
SpinLock()
Rel
Acq
Unlocked
Locked
Rel
Acq
Error
7
Abstraction (via Boolean program)
sU do assert(sU) sL if()
assert(sL) sU while
() assert(sL) sU
do KeAcquireSpinLock() nPacketsOld
nPackets if(request) request
request-gtNext KeReleaseSpinLock() nPackets
while(nPackets!nPacketsOld) KeReleaseSpi
nLock()
8
Abstraction (via Boolean program)
sU do assert(sU) sL if()
assert(sL) sU while
() assert(sL) sU
U
L
L
L
U
L
U
L
U
U
E
9
Overapproximation Too Large!
Q
unsafe
Q
init
10
Refined Boolean Abstraction
b (nPacketsOld nPackets)
sU do assert(sU) sL b true
if() assert(sL) sU b b ?
false while ( !b ) assert(sL)
sU
do KeAcquireSpinLock() nPacketsOld
nPackets if(request) request
request-gtNext KeReleaseSpinLock() nPackets
while(nPackets!nPacketsOld) KeReleaseSpi
nLock()
11
Refined Boolean Abstraction
b (nPacketsOld nPackets)
sU do assert(sU) sL b true
if() assert(sL) sU b b ?
false while ( !b ) assert(sL)
sU
U
L
b
L
b
L
b
U
b
!b
L
U
b
L
b
U
12
Invariant
13
Software VerificationA Search for Abstractions
  • A complex search space with a fitness function
    (false errors)
  • search for right abstraction
  • search within state space of abstraction
  • Can a machine beat a human at search for the
    right abstractions?
  • Deep Blue beat Kasparov

14
Overview
  • Part I Abstract Interpretation
  • Cousot Cousot, POPL77
  • Manual abstraction and refinement
  • ASTRÉE Analyzer
  • Part II Predicate Abstraction
  • Graf Saïdi, CAV 97
  • Automated abstraction and refinement
  • SLAM and Static Driver Verifier
  • Part III Comparing Approaches

15
(No Transcript)
16
(No Transcript)
17
(No Transcript)
18
(No Transcript)
19
(No Transcript)
20
(No Transcript)
21
(No Transcript)
22
(No Transcript)
23
(No Transcript)
24
(No Transcript)
25
(No Transcript)
26
Abstract Transitions
a
a
27
(No Transcript)
28
(No Transcript)
29
Slide courtesy of Patrick Cousot
30
Slide courtesy of Patrick Cousot
31
Slide courtesy of Patrick Cousot
32
Slide courtesy of Patrick Cousot
33
Diagram from Cousot, Cousot, POPL 1977
34
(No Transcript)
35
(No Transcript)
36
(No Transcript)
37
Patrick Cousot, Radhia Cousot, Jérôme Feret,
Laurent Mauborgne, Antoine Miné, David Monniaux,
Xavier Rival, Bruno Blanchet
ASTRÉE analyzes structured C programs, without
dynamic memory allocation and recursion.
In Nov. 2003, ASTRÉE automatically proved the
absence of any run-time error in the primary
flight control software of the Airbus A340
fly-by-wire system a program of 132,000 lines of
C analyzed in 1h20 on a 2.8 GHz 32-bit PC using
300 Mb of memory
38
Abstraction RefinementPLDI03 Case Study of
Blanchet et al.
  • the initial design phase is an iterative
    manual refinement of the analyzer.
  • Each refinement step starts with a static
    analysis of the program, which yields false
    alarms. Then a manual backward inspection of the
    program starting from sample false alarms leads
    to the understanding of the origin of the
    imprecision of the analysis.
  • There can be two different reasons for the lack
    of precision
  • some local invariants are expressible in the
    current version of the abstract domain but were
    missed
  • some local invariants are necessary in the
    correctness proof but are not expressible in the
    current version of the abstract domain.

39
Part I Summary
  • Create abstract domains and supporting algorithms
  • Relate domains via ? and ? functions
  • Prove Galois connection
  • Create abstract transformer T
  • Show that T approximates ? T ?
  • Widening to achieve termination
  • Refinement to reduce false errors

40
Part II Predicate Abstraction
  • Graf Saïdi, CAV 97
  • Idea
  • Given set of predicates P P1, , Pk
  • Formulas describing properties of system state
  • Abstract State Space
  • Set of Boolean variables B b1, , bk
  • bi true ? Set of states where Pi holds

41
Approximating concrete states
  • Fundamental Operation
  • Approximating a set of concrete states by a set
    of predicates
  • Requires exponential number of theorem prover
    calls in worst case
  • Compute Symbolically
  • Main Operation
  • ?X. ? ? (?i bi ? Pi )

Partitioning defined by the predicates
Similar to existential abstraction of finite
state machines Clarke, Grumberg, Long
42
Abstraction ? and Concretization ? Functions
43
Abstraction ? and Concretization ? Functions
44
Abstraction ? and Concretization ? Functions
45
(No Transcript)
46
(No Transcript)
47
(No Transcript)
48
(No Transcript)
49
(No Transcript)
50
(No Transcript)
51
(No Transcript)
52
(No Transcript)
53
(No Transcript)
54
(No Transcript)
55
Symbolic Best Transformers
  • Can be computed for infinite abstract domains
    with finite height
  • Reps,Sagiv,Yorsh, VMCAI04
  • Also for shape logics
  • Yorsh, Reps, Sagiv, TACAS04
  • Efficient predicate abstraction via symbolic
    decision procedures
  • Lahiri, Ball, Cook, CAV05

56
Refinement
a
b
c
57
Refinement
a
b
c
58
Rules
Static Driver Verifier
Development
Testing
Source Code
59
(No Transcript)
60
Part III Comparison
  • Informal
  • Formal

61
(No Transcript)
62
(No Transcript)
63
(No Transcript)
64
Formaling Comparing the Two Approaches
  • WAIL
  • widening abstract intepretation over infinite
    lattice
  • FAIR
  • finite abstraction iterative refinement

65
Abstraction/Refinement
  • Cousot-Cousot, PLILP92
  • widening abstract interpretation with infinite
    lattices (WAIL) is more powerful than a (single)
    finite abstraction
  • Namjoshi/Kurshan, CAV00
  • if there is a finite (bi-)simulation quotient
    then WAIL with no widening will terminate and
    therefore so will FAIR
  • Ball-Podelski-Rajamani, TACAS02
  • finite abstractions plus iterative refinement
    (FAIR) is more powerful than WAIL

66
Guarded Command Language
  • Variables X x1, , xn
  • Guarded command c
  • g ? x1e1 ? ? xnen
  • Program is a set of guarded commands
  • each command is deterministic
  • set of commands may be non-deterministic

67
Symbolic Representation of States
  • ? ? ?i?I ? j?J(i) ?ij
  • ?ij atomic formula such as (xlt5)
  • ? ? ? ? ? ? ?

68
pre ofc ? g ? x1e1 ? ? xnen
  • prec(?) ? g ? ?e1,en/ x1,xn
  • pre(?) ? ?c?C prec(?)

69
Safe Backward Invariants
  • ? is a safe backward invariant if
  • unsafe ? ?
  • pre(?) ? ?
  • ? ? noninit

70
Predicate Abstraction
  • A set P of predicates over a programs state
    space defines an abstraction of the program
  • P (a1), (b1), (agt0)
  • Uninterpreted atoms a1b1agt0
  • If P has n predicates, the abstract domain
    contains exactly 22n elements
  • an abstract state conjunction (?) of atoms
  • a set of abstract states disjunction (?) of
    abstract states

71
Free Lattice of DNF over a,b
a ? b ? (a?b)
a ? b
a ? (a?b)
b ? (a?b)
Logical Implication
a
b
(a?b)
?
72
preP ? ?P pre ?
  • ? ? the identity function
  • ?P(?) ? the least ? such that ? ? ? ?
  • Example
  • P (xlt2), (xlt3), (x0)
  • ?P( x1 ) (xlt2) ? (xlt3)

73
FAIR
n 0 ? unsafe loop Pn atoms(?)
construct pren, as defined by Pn ?
lfp(pren, unsafe) if (? ? noninit) then
return success ? ? ? pre(?) n n
1 forever
74
Widening
  • widen(?) ? such that ? ? ?
  • We consider widening that simply drops terms from
    some conjuncts
  • widen(?i?I ? j?J(i) ?ij )
  • ?i?I ? j?J(i) ?ij where J(i) ? J(i)
  • Results can be extended to other classes of
    widenings

75
Interval Widening, Revisited
76
WAIL
n 0 ? unsafe old false loop if
(? ? old) then if (? ? noninit) then
return success else return
Dont know else old ? i
guess provided by oracle ?
widen(i, ? ? pre(?) ) n n1 forever
77
WAIL
FAIR
n 0 ? unsafe loop Pn atoms(?)
construct pren, as defined by Pn ?
lfp(pren, unsafe) if (? ? noninit) then
return success ? ? ? pre(?) n n
1 forever
n 0 ? unsafe old false loop if
(? ? old) then if (? ? noninit) then
return success else return
Dont know else old ? i
guess provided by oracle ?
widen(i, ? ? pre(?) ) n n1 forever
78
Theorem. For any program P, if WAIL terminates
with success for some sequence of widening
choices, then FAIR will terminate with success
as well.
  • Lemma 1 If a safe invariant ? can be expressed
    in terms of predicates in P then lfp(preP,
    unsafe) is a safe invariant
  • Lemma 2 For any guarded command c,
  • prec(? ? ?) prec(?) ? prec(?)
  • prec(? ? ?) prec(?) ? prec(?)
  • Corollary For any guarded command c,
  • atoms(prec(? ? ?)) atoms(prec(?)) ?
    atoms(prec(?))
  • atoms(prec(? ? ?)) atoms(prec(?)) ?
    atoms(prec(?))

79
Proof of Theorem
  • ?0 unsafe
  • ?n1 ?n ? pre(?n)

?0 unsafe ?n1 widen(?n ? pre(?n))
for all i, atoms(?i) ? atoms(?i) by induction on
i and Lemma 2
if ?i is a safe inv. then by Lemma 1 and above
result lfp(Fatoms(?i), start) is a safe inv.
80
Summary
  • Predicate abstraction refinement and widening
    can be formally related to each other
  • Predicate abstraction refinement widening
    with optimal guidance

81
What We Did
  • Part I Abstract Interpretation
  • Cousot Cousot, POPL77
  • Manual abstraction and refinement
  • ASTRÉE Analyzer
  • Part II Predicate Abstraction
  • Graf Saïdi, CAV 97
  • Automated abstraction and refinement
  • SLAM and Static Driver Verifier
  • Part III Comparing Approaches

82
Searching for Solutions
  • Once upon a time, only a human could play a great
    game of chess
  • but then smart brute force won the day
  • Once upon a time, only a human could design a
    great abstraction
Write a Comment
User Comments (0)
About PowerShow.com