Logic as the lingua franca of
software verification
Ken McMillan
Microsoft Research
Joint work with Andrey Rybalchenko and Nikolaj Bjorner
Copyright 2013 Kenneth L. McMillan. All rights reserved.
Integration of program analyzers
Given: source program
and properties.
C
Transform
A
Transform
B
IL
Analyzer
A
source-to-source
IL-to-IL
heap modeling
To share facts, we undo A
transforms and apply B
transforms.
IL
Invariant
Analyzer
B
???
Goal: share information
between analyzers
Invariant can fail because
of divergent interpretations
of the source language.
Copyright 2013, Kenneth L. McMillan
The logical alternative
Given: source program
and properties.
C
VC
gen
Solver
A
translate to logical
constraint solving
SMT
To share facts, we pass
logical constraints.
Invariant
Goal: share information
between analyzers
Solver
B
OK!
Invariant can't fail because
it is a logical fact.
Copyright 2013, Kenneth L. McMillan
Duality of proofs and models
• Finding a proof about one system can often be cast as finding a solution
of another.
• Example: Duality in linear programming
solution
refutation
Primal constraints
Dual constraints
refutation
solution
The solution of the dual system is a proof that
the primal system is infeasible.
Copyright 2013, Kenneth L. McMillan
Program proving as SMT
• In program proving, we decorate a program with auxiliary assertions,
such as
– Loop invariants
– Procedure summaries
– Environment conditions
• Analysis of the program yields logical verification conditions (VC's) that
we can discharge with a theorem prover.
• Leaving the auxiliary assertions as unknown symbolic constants, the
problem of program proof becomes an SMT problem:
– Find values of the unknown relations that make the VC's valid.
We will examine the consequences of viewing the program
analysis as a satisfiability problem.
Copyright 2013, Kenneth L. McMillan
Example
var 𝑖 ∶ 𝑖𝑛𝑡 := 0;
while 𝑖 < 𝑁 invariant 𝑅(𝑖) do
𝑖 := 𝑖 + 2;
done
assert 𝑖 ≠ 41;
symbolic assertion
• The verification conditions are:
𝑖=0⇒𝑅 𝑖
invariant holds on entry
𝑅 𝑖 ∧ 𝑖 < 𝑁 ⇒ 𝑅(𝑖 + 2)
loop preserves invariant
𝑅 𝑖 ∧ ¬ 𝑖 < 𝑁 ⇒ 𝑖 ≠ 41
assertion holds on loop exit
• To prove the program, we must solve for 𝑅:
𝑅 𝑖 ⇔
𝑖 ≡ 0, mod 2
• Duality: a proof corresponds to a model of the VC's.
Copyright 2013, Kenneth L. McMillan
Is it really this simple?
• We need symbolic solutions, since 𝑅 is an infinite set.
• Traditional SMT solvers can't solve for 𝑅 because of the quantifiers in
the VC's.
– In general, SMT solvers don't produce models for quantified formulas.
• We need specialized tools to solve these programs
• We will consider three approaches
– Predicate abstraction
– Property-driven reachability
– Lazy abstraction with interpolants
Copyright 2013, Kenneth L. McMillan
Advantages of this view
1) Separation of concerns
C
2) Simplified tools
3) Allows interoperation
4) Amortizes effort
5) Established standards
interpreting program semantics
VC
gen
SMT
Solver
A
SMTLIB
Solver
B
proof
common
usessearch
can
be
logic.
highly
language
notoptimized
IL and model
Copyright 2013, Kenneth L. McMillan
VC generators and solvers
• We will consider first the VC generation problem, then the VC solving
problem.
• Andrey Rybalchenko's observation:
– Many common proof strategies produce VC's in the form of constrained
Horn clauses.
– Many familiar verification and analysis algorithms can be cast in terms of
solving constrained Horn clauses.
This allows us to generalize these algorithms over a range of verification problems.
Copyright 2013, Kenneth L. McMillan
Constrained Horn Clause
• A constrained Horn clause:
𝜙 ∧ 𝑃1 𝑡1 ∧ ⋯ ∧ 𝑃𝑘 𝑡𝑘
⇒
𝑃(𝑡)
constraint in theory 𝑇
example:
𝑅 𝑖 ∧ 𝑖 < 𝑁 ⇒ 𝑅(𝑖 + 2)
• We will call 𝑘 the degree of the clause
• If 𝑘 > 1, we say the clause is non-linear
• We will next consider some examples of systems that produce VC's in
this form, linear and non-linear...
Copyright 2013, Kenneth L. McMillan
Procedural programs
• Consider a simple procedure (without parameters):
procedure 𝜋:
requires 𝑃(𝑥);
ensures 𝑄(𝑥 𝑜𝑙𝑑 , 𝑥);
begin
𝑥 := 𝑥 + 1;
end
precondition
postcondition
• Procedural abstraction, Boogie style:
VC's are constrained
Horn clauses:
assert 𝑥 ≥ 0;
call 𝜋;
assert 𝑥 ≥ 0
𝑥 ≥ 0 ⇒ 𝑃(𝑥)
𝑥𝑜𝑙𝑑 ≥ 0 ∧ 𝑄 𝑥𝑜𝑙𝑑 , 𝑥 ⇒ 𝑥 ≥ 0
assert 𝑥 ≥ 0
assert 𝑃(𝑥);
𝑥𝑜𝑙𝑑 ≔ 𝑥;
havoc x;
assume 𝑄 𝑥𝑜𝑙𝑑 , 𝑥 ;
assert 𝑥 ≥ 0
𝑃 𝑥 ⇒ 𝑄 𝑥, 𝑥 + 1
Copyright 2013, Kenneth L. McMillan
Solving for procedure summaries
assert 𝑥 ≥ 0;
call 𝜋;
assert 𝑥 ≥ 0
assert 𝑥 ≥ 0
assert 𝑃(𝑥);
𝑥𝑜𝑙𝑑 ≔ 𝑥;
havoc x;
assume 𝑄 𝑥𝑜𝑙𝑑 , 𝑥 ;
assert 𝑥 ≥ 0
𝑥 ≥ 0 ⇒ 𝑃(𝑥)
𝑥𝑜𝑙𝑑 ≥ 0 ∧ 𝑄 𝑥𝑜𝑙𝑑 , 𝑥 ⇒ 𝑥 ≥ 0
𝑃 𝑥 ⇒ 𝑄 𝑥, 𝑥 + 1
solve...
𝑃 𝑥 ⇔ 𝑇𝑟𝑢𝑒
𝑄 𝑥𝑜𝑙𝑑 , 𝑥 ⇔ 𝑥 ≥ 𝑥𝑜𝑙𝑑
This is an over-approximate procedure summary
Copyright 2013, Kenneth L. McMillan
The non-linear case
• Suppose we have a symbolic invariant before a procedure:
assert R(𝑥);
call 𝜋;
assert 𝑥 ≥ 0
𝑅(𝑥) ⇒ 𝑃(𝑥)
𝑅(𝑥𝑜𝑙𝑑 ) ∧ 𝑄 𝑥𝑜𝑙𝑑 , 𝑥 ⇒ 𝑥 ≥ 0
The VC's have degree 2
• Nonlinear VC's make solving more involved
– counterexamples are trees, not paths
Copyright 2013, Kenneth L. McMillan
Modular concurrent proofs
• Consider two parallel processes:
process 𝑝1 :
while * do
𝜌1
done
process 𝑝2 :
while * do
𝜌2
done
• Suppose 𝑝𝑖 has locals 𝑥𝑖 and we have globals 𝑦
• We have to kinds of symbolic invariants:
– local invariants 𝑅1 (𝑥1 , 𝑦) and 𝑅2 (𝑥2 , 𝑦)
– environment assumptions 𝐸1 (𝑦, 𝑦 ′ ) and 𝐸2 (𝑦, 𝑦 ′ )
Copyright 2013, Kenneth L. McMillan
Modular VC's
• The VC's for process 𝜋1 are:
𝐼 ⇒ 𝑅(𝑥1 , 𝑦)
𝑅1 𝑥1 , 𝑦 ∧
𝜌1
initiation
𝑥1 , 𝑦, 𝑥1′ , 𝑦 ′ ⇒ 𝑅1 (𝑥1′ , 𝑦 ′ )
𝑅1 𝑥1 , 𝑦 ∧ 𝐸1 𝑦, 𝑦 ′ ⇒ 𝑅1 (𝑥1 , 𝑦 ′ )
𝑅1 𝑥1 , 𝑦 ∧
𝜌1
𝑥1 , 𝑦, 𝑥1′ , 𝑦 ′ ⇒ 𝐸2 (𝑦, 𝑦 ′ )
consecution
non-interference
environment abstraction
• These VC's are:
– in CHC form (the constraints are the transition relations)
– non-linear (the non-interference rule)
Copyright 2013, Kenneth L. McMillan
Inference of dependent types
• A common approach to verification of higher-order functional programs
is to decorate the program with "refinement types".
• For example, the type of functions taking an integer 𝑥 and returning an
integer greater than 𝑥 would written as:
𝑥: int → 𝑦: int {𝑦 > 𝑥}
• Using an abstraction called Liquid Types, inference of refinement types
can be reduced to solving constrained horn clauses.
Copyright 2013, Kenneth L. McMillan
CHC solvers
• Many familiar analysis and model checking approaches can be adapted
to CHC solving, and thus can potentially solve all these inference
problems.
–
–
–
–
–
Predicate abstraction
Lazy abstraction with interpolants
Incremental inductive invariant generation
Other lazy techniques, such as Yogi, Lazy annotation, etc.
Bounded model checking
• We will now consider some approaches to solving CHC's based on
different proof search strategies.
Copyright 2013, Kenneth L. McMillan
Predicate abstraction
• Given a set of predicates 𝒫, we synthesize the strongest satisfying
interpretation of the unknown relations, as:
– A Boolean combination over 𝒫, or
– A conjunction of literals over 𝒫 (Cartesian approximation)
• Simple example:
procedure P:
ensures 𝑃(𝑥𝑜𝑙𝑑 , 𝑥);
begin
if * then
call P;
𝑥 ≔ 𝑥 + 1;
end
procedure Q:
ensures 𝑄 𝑥𝑜𝑙𝑑 , 𝑥 ;
begin
call P;
call P;
end
procedure main:
begin
y=x;
call Q;
assert 𝑦 ≤ 𝑥
end
Copyright 2013, Kenneth L. McMillan
PA example, cont.
• Our VC's are:
𝑥 = 𝑦 ⇒ 𝑃(𝑥, 𝑦)
base case of P
𝑃 𝑥, 𝑦 ∧ 𝑧 = 𝑦 + 1 ⇒ 𝑃(𝑥, 𝑧)
𝑃 𝑥, 𝑦 ∧ 𝑃 𝑦, 𝑧 ⇒ 𝑄(𝑥, 𝑧)
recursive case of P
Q is P twice
𝑄 𝑥, 𝑧 ⇒ 𝑥 ≤ 𝑧
property to prove (query)
We want to synthesize a solution for these VC's using
these predicates:
𝑃 𝑥, 𝑦 ∶ {𝑥 = 𝑦, 𝑥 ≤ 𝑦}
𝑄 𝑥, 𝑧 ∶ {𝑥 = 𝑧, 𝑥 ≤ 𝑧}
Strategy: start with false and use counterexamples to the
VC's to weaken the relational interpretation.
Copyright 2013, Kenneth L. McMillan
PA execution
relational interpretation
𝑃(𝑥, 𝑦)
𝑄(𝑥, 𝑧)
𝐹𝑎𝑙𝑠𝑒
𝑥=𝑦
𝑥≤𝑦
𝐹𝑎𝑙𝑠𝑒
failed VC
𝑥 = 𝑦 ⇒ 𝑃(𝑥, 𝑦)
𝑃 𝑥, 𝑦 ∧ 𝑧 = 𝑦 + 1 ⇒ 𝑃(𝑥, 𝑧)
𝑃 𝑥, 𝑦 ∧ 𝑃 𝑦, 𝑧 ⇒ 𝑄(𝑥, 𝑧)
𝑥≤𝑧
• All the VC's are now solved, so our property is proved.
• This is the strongest solution expressible using our predicates.
• But consider the query:
𝑄 𝑥, 𝑧 ⇒ 𝑥 ≤ 𝑧
• We can't repair this by weakening a relation.
• If it's false, we need more predicates!
Copyright 2013, Kenneth L. McMillan
Refinement using interpolants
• A fact is a CHC of the form 𝜙 ⇒ 𝑃(𝑡).
• A fact also expresses a set of ground facts:
– For example 𝑥 > 0 ⇒ 𝑃 𝑥 stands for 𝑃 1 , 𝑃 2 , 𝑃 3 , …
• A counterexample is a proof of a ground fact that contradicts a query.
• We build a counterexample as a derivation tree.
Copyright 2013, Kenneth L. McMillan
Derivation tree
• Start with negation of query (we want to refute it)
• Unify each P-fact with a P-rule
𝑥 = 𝑦 ⇒ 𝑃(𝑥, 𝑦)
𝑄 𝑥, 𝑧 ∧ ¬𝑥 ≤ 𝑧
𝑃 𝑥, 𝑦 ∧ 𝑧 = 𝑦 + 1 ⇒ 𝑃(𝑥, 𝑧)
𝑃 𝑥, 𝑦 ∧ 𝑃 𝑦, 𝑧 ⇒ 𝑄(𝑥, 𝑧)
𝑃 𝑥, 𝑦 ∧ 𝑃 𝑦, 𝑧 ⇒ 𝑄(𝑥, 𝑧)
𝑄 𝑥, 𝑧 ⇒ 𝑥 ≤ 𝑧
𝑥 = 𝑦 ⇒ 𝑃(𝑥, 𝑦)
𝑃 𝑦, 𝑦 ′ ∧ 𝑧 = 𝑦 ′ + 1 ⇒ 𝑃(𝑦, 𝑧)
𝑦 = 𝑦′ ⇒ 𝑃(𝑦, 𝑦′)
• The derivation tree characterizes a set of ground derivations
Copyright 2013, Kenneth L. McMillan
Solving the derivation tree
• By solving the constraints in the derivation tree, we derive a ground fact
that contradicts the query.
𝑄 𝑥,
1,2𝑧 ∧∧ ¬1
¬𝑥 ≤
≤ 2𝑧
¬(𝑥 ≤ 𝑧)
𝑃 1,1
𝑥, 𝑦 ∧∧𝑃𝑃 1,2
𝑦, 𝑧 ⇒
⇒𝑄(1,2)
𝑄(𝑥, 𝑧)
𝑥=1
1
𝑦 ⇒ 𝑃(1,1)
𝑃(𝑥, 𝑦)
𝑡𝑟𝑢𝑒
𝑥=𝑦
𝑧 = 𝑦′ + 1
𝑃 𝑦,
1,1𝑦 ′ ∧∧2𝑧==1𝑦+′ +
11
⇒⇒
𝑃(1,2)
𝑃(𝑦, 𝑧)
not true!
𝑦=1
1
𝑦′⇒
⇒𝑃(1,1)
𝑃(𝑦, 𝑦′)
y = 𝑦′
Satisfiable without query: 𝑥 = 𝑦 = 𝑦 ′ = 1, 𝑧 = 2
Note the constraint tree is just a BMC formula.
BMC = solving for a proof of a ground fact!
Copyright 2013, Kenneth L. McMillan
Interpolating the derivation tree
• If the constraints are UNSAT, we can compute an interpolant.
¬(𝑥 ≤ 𝑧)
𝑄 𝑥, 𝑧 ∧ ¬𝑥
≤𝑧
𝑓𝑎𝑙𝑠𝑒
𝑡𝑟𝑢𝑒
𝑃 𝑥, 𝑦 ∧ 𝑃 𝑦, 𝑧 ⇒ 𝑄(𝑥,𝑥𝑧)≤ 𝑧 − 1
𝑥 𝑥= =
𝑦 𝑦 ⇒ 𝑃(𝑥, 𝑦)
𝑃
𝑦, 𝑦 ′
𝑥≤𝑦
𝑧 = ′𝑦 ′ + 1
∧ 𝑧 = 𝑦 + 1 ⇒ 𝑃(𝑦, 𝑧)
𝑦 = 𝑦′ ⇒ 𝑃(𝑦, 𝑦′)
y = 𝑦′
• Interpolant formulas are:
– bottom up refutation
– only over head variables
– upper bound on derivable facts
𝑄 𝑥, 𝑧 ∶ 𝑥 ≤ 𝑧 − 1
𝑃 𝑥, 𝑦 ∶ 𝑥 ≤ 𝑦
𝑦 ≤𝑧−1
𝑦 ≤ 𝑦′
𝑃 𝑥, 𝑦 ∶ 𝑥 ≤ 𝑦 − 1
𝑃 𝑥, 𝑦 ∶ 𝑥 ≤ 𝑦
predicates
from
interpolants
Copyright 2013, Kenneth L. McMillan
Predicate abstraction as unwinding
• We can think of predicate abstraction as unwinding
• Each time inductiveness fails, we add an new instance of a clause
𝑥 = 𝑦 ⇒ 𝑃(𝑥, 𝑦)
𝑄1 𝑥, 𝑧 ⇒ 𝑥 ≤ 𝑧
𝑃 𝑥, 𝑦 ∧ 𝑧 = 𝑦 + 1 ⇒ 𝑃(𝑥, 𝑧)
𝑃 𝑥, 𝑦 ∧ 𝑃 𝑦, 𝑧 ⇒ 𝑄(𝑥, 𝑧)
Q1 𝑥, 𝑧 : 𝑇𝑟𝑢𝑒
𝑄 𝑥, 𝑧 ⇒ 𝑥 ≤ 𝑧
𝑃2 𝑥, 𝑦 : 𝑇𝑟𝑢𝑒
𝑃1 𝑥, 𝑦 ∧ 𝑃2 𝑦, 𝑧 ⇒ 𝑄1 (𝑥, 𝑧)
𝑃1 𝑥, 𝑦 ∧ 𝑧 = 𝑦 + 1 ⇒ 𝑃2 (𝑥, 𝑧)
𝑃1 𝑥, 𝑦 : 𝑥 = 𝑦
𝑥 = 𝑦 ⇒ 𝑃1 (𝑥, 𝑦)
𝑃 𝑥, 𝑦 : {𝑥 = 𝑦}
𝑃0 𝑥, 𝑦 : 𝐹𝑎𝑙𝑠𝑒
Q0 𝑥, 𝑧 : 𝐹𝑎𝑙𝑠𝑒
Copyright 2013, Kenneth L. McMillan
Lazy predicate refinement
• When query fails, build a derivation tree for the unwinding, and compute
interpolants.
predicates from
interpolants:
𝑄1 𝑥, 𝑧 ⇒ 𝑥 ≤ 𝑧
𝑄 𝑥, 𝑧 : {𝑥 ≤ 𝑧}
𝑃 𝑥, 𝑦 : {𝑥 ≤ 𝑦 − 1}
QQ11 𝑥,
𝑥,𝑧𝑧 ::𝑥𝑇𝑟𝑢𝑒
≤𝑧
eager propagation
unwinding solved!
𝑃2𝑦 𝑥,: 𝑥𝑦 ≤: 𝑇𝑟𝑢𝑒
P2 𝑥,
𝑦−1
solution inductive!
𝑃1 𝑥, 𝑦 ∧ 𝑧 = 𝑦 + 1 ⇒ 𝑃2 (𝑥, 𝑧)
P1𝑃1𝑥,𝑥,
𝑦 𝑦: 𝑥: 𝑥==𝑦 𝑦
𝑃 𝑥, 𝑦 : 𝑥 = 𝑦 ∨ 𝑥 ≤ 𝑦 − 1
𝑄 𝑥, 𝑧 : 𝑥 ≤ 𝑧
𝑥 = 𝑦 ⇒ 𝑃1 (𝑥, 𝑦)
𝑃0 𝑥, 𝑦 : 𝐹𝑎𝑙𝑠𝑒
Q0 𝑥, 𝑧 : 𝐹𝑎𝑙𝑠𝑒
Copyright 2013, Kenneth L. McMillan
What have we done?
• Given a purely logical account of predicate abstraction with CEGAR
• Generalize the technique to:
–
–
–
–
Interprocedural analysis
Modular proofs of concurrent programs
Inference of refinement types
...
• A single implementation solves all these problems. All we need is a VC
generator, and these already exist.
• This approach (more or less) implemented in QARMC
Copyright 2013, Kenneth L. McMillan
Lazy abstraction with interpolants
• In the IMPACT algorithm, we don't compute consequences eagerly
using predicate abstraction. Instead, we simply decorate the unwinding
with the interpolants from the failed derivation of a counterexample.
• We can generalize IMPACT from the linear case to the non-linear
– In IMPACT, counterexample derivations are paths
– in Duality, they are trees.
Copyright 2013, Kenneth L. McMillan
Duality algorithm
• We unwind the CHC's without any eager deduction
• Each time inductiveness fails, we add an new instance of a clause
𝑥 = 𝑦 ⇒ 𝑃(𝑥, 𝑦)
𝑄1 𝑥, 𝑧 ⇒ 𝑥 ≤ 𝑧
𝑃 𝑥, 𝑦 ∧ 𝑧 = 𝑦 + 1 ⇒ 𝑃(𝑥, 𝑧)
𝑃 𝑥, 𝑦 ∧ 𝑃 𝑦, 𝑧 ⇒ 𝑄(𝑥, 𝑧)
Q1 𝑥, 𝑧 : 𝑇𝑟𝑢𝑒
𝑄 𝑥, 𝑧 ⇒ 𝑥 ≤ 𝑧
𝑃2 𝑥, 𝑦 : 𝑇𝑟𝑢𝑒
𝑃1 𝑥, 𝑦 ∧ 𝑃2 𝑦, 𝑧 ⇒ 𝑄1 (𝑥, 𝑧)
𝑃1 𝑥, 𝑦 ∧ 𝑧 = 𝑦 + 1 ⇒ 𝑃2 (𝑥, 𝑧)
𝑃1 𝑥, 𝑦 : 𝑇𝑟𝑢𝑒
𝑥 = 𝑦 ⇒ 𝑃1 (𝑥, 𝑦)
𝑃0 𝑥, 𝑦 : 𝐹𝑎𝑙𝑠𝑒
Q0 𝑥, 𝑧 : 𝐹𝑎𝑙𝑠𝑒
Copyright 2013, Kenneth L. McMillan
Fixing the proof
• When query fails, build a derivation tree for the unwinding, and compute
interpolants,then update the solution with the interpolants.
𝑄1 𝑥, 𝑧 ⇒ 𝑥 ≤ 𝑧
QQ11 𝑥,
𝑥,𝑧𝑧 ::𝑥𝑇𝑟𝑢𝑒
≤𝑧
unwinding solved!
P2 𝑥,𝑃1𝑦 𝑥,: 𝑥𝑦 ≤: 𝑇𝑟𝑢𝑒
𝑦−1
solution inductive!
𝑃1 𝑥, 𝑦 ∧ 𝑧 = 𝑦 + 1 ⇒ 𝑃2 (𝑥, 𝑧)
P1 𝑥,𝑃1𝑦 𝑥,
: 𝑥𝑦=: 𝑇𝑟𝑢𝑒
𝑦
𝑃 𝑥, 𝑦 : 𝑥 = 𝑦 ∨ 𝑥 ≤ 𝑦 − 1
𝑄 𝑥, 𝑧 : 𝑥 ≤ 𝑧
𝑥 = 𝑦 ⇒ 𝑃1 (𝑥, 𝑦)
𝑃0 𝑥, 𝑦 : 𝐹𝑎𝑙𝑠𝑒
Q0 𝑥, 𝑧 : 𝐹𝑎𝑙𝑠𝑒
Copyright 2013, Kenneth L. McMillan
Property-driven reachability
• We can generalize PDR to the non-linear case [BjornerHoder2012]
• In PDR, when we fail to prove a conjecture locally, we form proof subgoals and propagate them downward.
𝑄1 𝑥, 𝑧 ⇒ 𝑥 ≤ 𝑧
𝑄1 𝑥, 𝑧 ⇒ ¬ 𝑥 = 1, 𝑧 = 0 ?
QQ11 𝑥,
𝑥,𝑧𝑧 ::𝑥𝑇𝑟𝑢𝑒
≤𝑧
𝑃2 𝑥, 𝑦 ∧ 𝑃1 𝑦, 𝑧 ⇒ 𝑄1 (𝑥, 𝑧)
P2 𝑥,𝑃2𝑦 𝑥,
: 𝑥𝑦≤: 𝑇𝑟𝑢𝑒
𝑦−1
𝑃1 𝑥, 𝑦 ∧ 𝑧 = 𝑦 + 1 ⇒ 𝑃2 (𝑥, 𝑧)
P1 𝑥,𝑃1𝑦 𝑥,
: 𝑥𝑦=: 𝑇𝑟𝑢𝑒
𝑦
unwinding solved!
𝑃2 𝑥, 𝑦 ⇒ ¬ 𝑥 = 1, 𝑦 = 0 ?
solution inductive!
𝑃 𝑥, 𝑦 : 𝑥 = 𝑦 ∨ 𝑥 ≤ 𝑦 − 1
𝑃𝑃11 𝑥,
𝑥,𝑦𝑦 ⇒
⇒¬
¬ 𝑥𝑥 =
= 1,
0,𝑦𝑦 =
= −1
0 ??
𝑄 𝑥, 𝑧 : 𝑥 ≤ 𝑧
𝑥 = 𝑦 ⇒ 𝑃1 (𝑥, 𝑦)
𝑃0 𝑥, 𝑦 : 𝐹𝑎𝑙𝑠𝑒
Q0 𝑥, 𝑧 : 𝐹𝑎𝑙𝑠𝑒
Copyright 2013, Kenneth L. McMillan
The story so far
• We've seen that program analysis can be viewed ass solving the VC's
• Existing algorithms can be transferred to this context:
– (Lazy) Predicate abstraction
– Lazy abstraction with interpolants
– Property-driven reachability analysis
• In the process we...
– Generalize these algorithms to the nonlinear case, so they can compute
procedure summaries, modular proofs, refinement types, etc...
– Abstract away from program languages and representations.
– Allows re-use of VC generation tools
• We also have lots of flexibility in generating VC's
– Different granularity -- blocks, loops, procedures, etc.
– Different proof rules give different proof decompositions
– By expressing the auxiliary relations in the right form, we can guide the proof
Copyright 2013, Kenneth L. McMillan
Performance
• The key remaining question is how much performance we may sacrifice
to gain this flexibility.
– Are there important optimizations we will miss?
– In particular, what is lost if we don't explicitly mode control flow?
• We'll look a two cases of comparison between generic logical tools and
highly refined program-specific tools to try to answer this question.
Copyright 2013, Kenneth L. McMillan
Verifying Boolean programs
• We compare two tools for inter-procedural analysis of Boolean programs
[Bjorner and Hoder, 2012]:
– Bebop (a BDD-based tool used in SLAM)
– CHC solver using PDR
Copyright 2013, Kenneth L. McMillan
Full device driver verification
• We compare Duality with Yogi, a software model checker extensively
tuned for this application domain.
• Benchmarks: randomly selected SDV examples
• Procedure-level VC's generated by Boogie
• Solved using duality algorithm with interpolating Z3.
Copyright 2013, Kenneth L. McMillan
Adding localization reduction
• Hypothesis: large overhead due to encoding of heap using many global
maps (one per structure field).
• Test: Localize using bounded model checking (a standard technique).
This shows what potentially could be achieved by integrating
localization incrementally, or perhaps different heap encoding
Copyright 2013, Kenneth L. McMillan
Open questions
• Are there techniques or optimizations that can be performed on CFG
representations that are not possible in the logical representation?
• Various common operations have logical analogs
–
–
–
–
–
Symbolic execution → substitution
Slicing → dropping constraints
Abstract post → consequence finding
Abstract join → resolution
Points-to analysis → quantifier elimination? (Dillig and Dillig)
• It's an open question whether a purely logic representation suffices, or
we still need CFG representations for pragmatics.
Copyright 2013, Kenneth L. McMillan
Conclusion
• We've seen that program verification can be viewed as solving the VC's
to infer the necessary auxiliary constructs such as loop invariants,
procedure summaries, non-interference conditions and so on.
• Many existing verification techniques can be applied to this problem
– Generalizing to the non-linear case
– Allowing application to many proofs systems and languages
• This allows a separation of concerns between programming language
interpretation and verification algorithms
– Re-use existing VC generators (Boogie, VCC, etc...)
– Reduce barrier to entry in the field
• It allow allows inter-operation of tools, since they speak a common
language.
Database of program verification problems in SMTLIB format at:
https://svn.sosy-lab.org/software/sv-benchmarks/trunk/clauses/
Copyright 2013, Kenneth L. McMillan