Upload
jake-trujillo
View
226
Download
0
Tags:
Embed Size (px)
Citation preview
Exploitingthe Dual Viewin VerificationKoen Lindström ClaessenChalmers UniversityGothenburg, Sweden
informalformal
Verification w/ Theorem Proving
SystemUnder Verification
Expected/WantedProperty
formula
Sformula
P
SP?
model ~ actual behavior of
system
model ~ allowed behavior of
system
is every actual behavior allowed?
does (S&¬P) have a model?
counterexample
correctnessproof
Full Pure First-Order Logic (FOL)
First-order logicPredicate/function symbolsEqualityUniversal/existential quantification
Not includedArithmeticLeast fixpoints Induction
FOL Decidability
formula(Assumptions &
¬ProofObligation)
contradiction (proof)
satisfiable (model)
infinite domai
n
finite domai
n?
counterexample
correctnessproof
FOL is semi-decidable
a domain (a set);plus interpretations for
function/predicate symbols
This Talk Present an alternative view
Dual ViewThough experiment with initial success
System correctFormula satisfiableModel ~ correctness witness
System incorrectFormula unsatisfiableProof ~ concrete bug trace
Example: Ball Game
Balls
out in
same
different
Can the last ball be red? green?
5050
Modelling the Ball Game
(#red, #green)
(n+2,m) (n+1,m)
(n,m+2) (n+1,m)
(n+1,m+1) (n,m+1)
initial state: (50,50)
Modelling the Ball Game in FOL
% initial stater(s50(0),s50(0)).
% transitionsr(s(s(N)),M) r(s(N),M).r(N,s(s(M))) r(s(N),M).r(s(N),s(M)) r(N,s(M)).
% final state-r(s(0),0).
r(n,m) provableiff.
(n,m) reachable
-r(0,s(0)).
The Model (final state: -r(0,s(0)))
0 = '1
r('1,'1) : TRUEr('1,'2) : FALSEr('2,'1) : TRUEr('2,'2) : FALSE
s('1) = '2s('2) = '1
This is an abstraction of the
original system
Modelling the Ball Game in FOL
% initial statesi(N,0).i(N,M) i(N,s(s(M))).i(N,M) r(N,M).
% transitionsr(s(s(N)),M) r(s(N),M).r(N,s(s(M))) r(s(N),M).r(s(N),s(M)) r(N,s(M)).
% final state-r(0,s(0)).
The Model0 = '1
i('1,'1) : TRUEi('1,'2) : FALSEi('2,'1) : TRUEi('2,'2) : FALSE
r('1,'1) : TRUEr('1,'2) : FALSEr('2,'1) : TRUEr('2,'2) : FALSE
s('1) = '2s('2) = '1
This is an abstraction of the
original system, which has an infinite
amount of states!
Summary
Traditional viewProof ~ system correctCounter model ~ system incorrect
Dual viewProof ~ system incorrectModel ~ system correct
Problem to FOL Mapping
formula
contradiction (proof)
satisfiable (model)
infinite domai
n
finite domai
n?
Hard
Natural Mapping?
TraditionalCorrectness ~ proof
Needs induction/meta-reasoning Hard
Incorrectness ~ bug trace Finding a model Hard conceptually
easy
conceptually hard
Natural Mapping
Dual View Incorrectness ~ proof
Finding bug trace is easy Proof is easy
Correctness ~ model Correctness is hard Finding model is hard
informalformal
Verification w/ Dual View
SystemUnder Verification
Expected/WantedProperty
formula
Sformula
P
M|=S&P?one intended model
~ all behaviors of system
model ~ system satisfying the
property
counterproof
model
s reachable iff.r(s) provable ¬r(sbad)
Summary Dual View
reachability ~ provability
correctness ~ unreachability
correctness ~ unprovability
incorrectness ~ provability
use model finder
use theorem prover
Related Work
“Inductionless induction” Traditional way of expressing puzzles in
FOL Weidenbach’s security protocols with
SPASS
finite-domain model finding
Process Calculus
P ::= nil terminated process | f(e1,...,ek) call a process | P || Q parallell composition | P + Q choice | e ! P send | p ? P receive
synchronous
+ definitions
Example
% serverserver = req ? rel ? server
% clientsclients = client || client || clientclient = req ! doitdoit = rel ! client
% top leveltop = server || clients
Translation into FOL
Each process is a FOL term A set of processes is also a FOL term A reachability predicate r(P) Some general axioms about nil, ||, + Initial state axiom r(top) Property is written directly in FOL
Process Calculus
P ::= nil terminated process | f(e1,...,ek) call a process | P || Q parallell composition | P + Q choice | e ! P send | p ? P receive
Syntactically, FOL terms
alreadySpecial
treatment
General Axioms (FOL)
% parallel composition(P || Q) || R = P || (Q || R).P || Q = Q || P.P || nil = P.
% choicer( (P + Q) || R ) r( P || R ).r( (P + Q) || R ) r( Q || R ).
Definition restriction
Each ’receive’ construct needs to have its own
definition
Example
% serverserver = req ? rel ? server
% clientsclients = client || client || clientclient = req ! doitdoit = rel ! client
% top leveltop = server || clients
Example, fixed
% serverserver = req ? waitingwaiting = rel ? server
% clientsclients = client || client || clientclient = req ! doitdoit = rel ! client
% top leveltop = server || clients
Definition Translation
f(x1,...,xk) = t f(X1,...,Xk) = t.
f(x1,...,xk) = p ? t
r( f(X1,...,Xk) || (p ! P) || Q ) r( t || P || Q ).
Example in FOL
% serverr( server || (req ! P) || Q ) r( waiting || P || Q ).r( waiting || (rel ! P) || Q ) r( server || P || Q ).
% clientsclients = client || client || client.client = req ! doit.doit = rel ! client.
% top leveltop = server || clients.
Property
% bad state-r( doit || doit || P ).
Model with domain size 3
So, bad states are unreachable
Model?
What is a model?A domain (a set) Interpretations for functions/predicates
What does it mean?For each concrete state s, we can calculate
M(r(s))Overapproximation of reachabilityBad state: M(r(sbad)) = FALSE
Model is an abstraction
Example, infinite
% serverserver = req ? waitingwaiting = rel ? server
% clientsclients = client || clientsclient = req ! doitdoit = rel ! client
% top leveltop = server || clients
Process Calculus
P ::= nil terminated process | f(e1,...,ek) call a process | P || Q parallell composition | P + Q choice | e! send | p ? P receive | new x . P new objects
asynchronous
Example
% serverserver = req(A) ? (ack(A)! || waiting(A))waiting(A) = rel(A) ? server
% clientsclients = (new A . client(A)) || clientsclient(A) = req(A)! || doit(A)doit(A) = ack(A) ? (rel(A)! || client(A))
% top leveltop = server || clients
Example in FOL
% serverr( server || req(A)! || Q ) r( ack(A)! || waiting(A) || Q ).r( waiting(A) || rel(A)! || Q ) r( server || Q ).
% clientsr( clients || P ) r( client(new(P)) || clients || P ).client(A) = req(A)! || doit(A).r( doit(A) || rel(A)! || P ) r( rel(A)! || client(A) || P ).
% top leveltop = server || clients.
Property
% bad state-r( doit(A) || doit(B) || P ).
Model with domain size 3
Conclusions Dual View
Benefit Can work in practice (security protocols)Has tighter fit with actual problemWorks for all computation!
DisadvantagesCareful axiomatizationsDanger of infinite models
FOL proving ~ computing
Other constructs
Higher-order calculiProcesses are just terms, like messages
ChannelsUse the idea behind the ‘new’ constructUnbounded queues
Messages with sender and receiverTag ‘send’ construct with extra information
Paradox
Finite-domain model finderFinds finite domainFinds interpretations
Full pure first-order logicConstants, functions, predicatesQuantifiersEquality(Untyped)
Winner of CASC2003,2004,2005,2006
FOL Decidability
formula
contradiction (proof)
satisfiable (model)
infinite domai
n
finite domai
n?
Hard
Paradox Applications Satisfiability
Proof won’t go trhoughBad state is unreachable
ModelMath: group theory, algebraCounter exampleAbstraction
Decision procedureFor FOL with finite domains
Paradox Overview
FOLproblem Clausifier Flattener
InstantiateSAT
Solvern:=n+1
n:=1
no yes
MiniSat(Sörensson,
Eén)
FOL Clause Examples
-p(X,Y) | -p(Y,Z) | p(X,Z)
h(X,h(Y,Z)) = h(h(X,Y),Z)
X = Y | -(f(X) = f(Y))
Connection with SAT-world
Pick domain DOnly size mattersD = {1,2,3,..,n}
Introduce SAT variables”p(i,j)” (for i, j in D)”f(i,j)=k” (for i, j, k in D)
Re-express FOL clauses
Flattening: Definitions
-p(X,Y) | -p(Y,Z) | p(X,Z)Already flattened
h(X,h(Y,Z)) = h(h(X,Y),Z)-(h(Y,Z) = U) | -(h(X,Y) = V) | -(h(X,U) = W) |
h(V,Z) = W
X = Y | -(f(X) = f(Y))X = Y | -(f(X) = V) | -(f(Y) = V)
Extra Axioms for Functions
Result should be unique-(f(X,Y) = V) | -(f(X,Y) = W) | V = W
Function should be total f(X,Y) = 1 | f(X,Y) = 2 | ... | f(X,Y) = n
Only for domain size n
Instantiation (n=3) X = Y | -(f(X) = V) | -(f(Y) = V)
1 = 1 | -(f(1) = 1) | -(f(1) = 1)1 = 1 | -(f(1) = 2) | -(f(1) = 2)1 = 1 | -(f(1) = 3) | -(f(1) = 3)1 = 2 | -(f(1) = 1) | -(f(2) = 1)1 = 2 | -(f(1) = 2) | -(f(2) = 2)1 = 2 | -(f(1) = 3) | -(f(2) = 3)1 = 3 | -(f(1) = 1) | -(f(3) = 1)1 = 3 | -(f(1) = 2) | -(f(3) = 2)1 = 3 | -(f(1) = 3) | -(f(3) = 3) ...
Instantiation (n=3) X = Y | -(f(X) = V) | -(f(Y) = V)
1 = 1 | -(f(1) = 1) | -(f(1) = 1)1 = 1 | -(f(1) = 2) | -(f(1) = 2)1 = 1 | -(f(1) = 3) | -(f(1) = 3)1 = 2 | -(f(1) = 1) | -(f(2) = 1)1 = 2 | -(f(1) = 2) | -(f(2) = 2)1 = 2 | -(f(1) = 3) | -(f(2) = 3)1 = 3 | -(f(1) = 1) | -(f(3) = 1)1 = 3 | -(f(1) = 2) | -(f(3) = 2)1 = 3 | -(f(1) = 3) | -(f(3) = 3) ...
Incremental SAT: Assumptions
FOLproblem Clausifier Flattener
InstantiateSAT
Solvern:=n+1
n:=1
no yes
Under the assumption of
totalness for size n
Complexity
InstantiationDomain size nNumber of variables per clause kO(nk)
Typically, 1 ≤ n ≤ 10 k ~ number of (distinct) subterms in clause
Splitting
-(h(Y,Z) = U) | -(h(X,Y) = V) | -(h(X,U) = W) | h(V,Z) = W
6 variables:O(n6)
-(h(Y,Z) = U) | -(h(X,Y) = V) | s(X,Z,U,V)
-(h(X,U) = W) | h(V,Z) = W | -s(X,Z,U,V)
New predicate s
2 x5 variables:
O(n5)
Splitting Algorithm
X
V
Z
U
W
Y
Splitting Algorithm
X
V
Z
U
W”Graph tree-decomposition
”
Other Techniques
CliquesPre-assign domain values
Symmetry reductionAll permutations are also a modelForce a particular permutation
Type inferenceSome types can have smaller domainsApply symmetry reduction for each type
General Results
Good splitting is vital for feasibilityTerm-based splittingVariable splitting
Symmetry reductionMakes SAT problem easier
Type inference and domain reductionMakes some problems feasible
Typical Behavior
Domain sizes ≤ 6,7,8No problem
Degree 5Domains up to size 20
Using Paradox in the Dual View
Increase possibilityFor finite modelsFor small modelsFor small representations of models
Give freedom …To do as much as possible with as few
domain elements as possible
Example: Unbounded Channels% queuescat(empty,Q) = Q & cat(Q,empty) = Q.cat(Q1,cat(Q2,Q3)) = cat(cat(Q1,Q2),Q3).
% initial stater( stateA, empty, stateP, empty).
% state transitionsr( stateA, Q1, S2, cat(unit(a), Q2) ) r( stateB, cat(Q1, unit(b)), S2, Q2 )....
A B?a!b
P Q!a……
A Possible Model …
Must give one interpretation to cat, empty, unit
So, only one abstraction is used for both queues!
This makes the model more complicatedLarger domainPossibly infinite!
Trick 1: Copy Symbols & Axioms% queuescat1(empty1,Q) = Q & cat1(Q,empty1) = Q.cat1(Q1,cat1(Q2,Q3)) = cat1(cat1(Q1,Q2),Q3).cat2(empty2,Q) = Q & cat2(Q,empty2) = Q.cat2(Q1,cat2(Q2,Q3)) = cat2(cat2(Q1,Q2),Q3).
% initial stater( stateA, empty1, stateP, empty2).
% state transitionsr( stateA, Q1, S2, cat2(unit2(a), Q2) ) r( stateB, cat1(Q1, unit1(b)), S2, Q2 )....
Copying Axioms?
Feels silly Build into the model finder primitively
Example: Types% queuescat1(empty1,Q) = Q & cat1(Q,empty1) = Q.cat1(Q1,cat1(Q2,Q3)) = cat1(cat1(Q1,Q2),Q3).cat2(empty2,Q) = Q & cat2(Q,empty2) = Q.cat2(Q1,cat2(Q2,Q3)) = cat2(cat2(Q1,Q2),Q3).
% initial stater( stateA, empty1, stateP, empty2).
% state transitionsr( stateA, Q1, S2, cat2(unit2(a), Q2) ) r( stateB, cat1(Q1, unit1(b)), S2, Q2 )....
: queue(mess1)
: queue(mess2): state2: state1
: mess2
: mess1
Untyped?
Use same domain for each type Is not the real problemUsing same domain size is
If one concept needs extra room in model Then all concepts pay for that Instantiation is sensitive to domain size
Trick 2: Allow per-type domain size
Who decides the types?Given by the user Inferred by the tool
Who decides the domain sizes?Search? In what order?
Trick 1 improves on trick 2More types, more freedom
Multiple Domains
FOLproblem Clausifier Flattener
InstantiateSAT
Solverni:=ni+1
n1:=1,n2:=1,n3:=1
no yes
why? pick i
Under the assumption of
totalness for sizes n1,n2,n3
MiniSat extension: conflict clause = subset
of assumptions
Example: Arity-reduction
% initial stater( stateA, stateP, stateX, stateV, empty12, empty13, empty14, empty21, empty23, empty24, empty31, empty32, empty34, empty41, empty42, empty43 ).
% state transitions...
Building this predicate table:n=1: 1^16n=2: 2^16n=3: 3^16
Trick 3: Introducing tupling
Instead of writing p(X,Y,Z,A,B,C)p(tup1(X,Y,Z),tup2(A,B,C))p(tup1(X,Y),tup2(Z,A),tup3(A,C))p(tup1(X,A),tup2(Y,B),tup3(Z,C))
Types change: tup1 : (A,B) TWorst-case: |T| = |A| x |B|Better cases: |T| << |A| x |B| Information-coupling
Automation… ?
Tricks
Multiple interpretationsSeveral similar symbolsCopy axiomatization
Multiple domain sizesFeedback from incremental SAT-solver
Arity-reducing transformationsFeasibility of building the model
Results
Abstractions of finite systemsVisualizationAbstraction refinement
Abstractions of infinite systemsWorks surprisingly oftenTechniques for reducing needed sizeTechniques for infinite finite
•security protocols
•communication protocols
•distributed systems
•puzzles
Conclusions Explore Dual View
Interesting and intriguing Finite models
Abstractions Push boundaries
Unbounded queues: not many techniques known
”Trick”s work also for other problemsTPTP
Future Work
Characterize when it works Techniques for making it work
Infinite model finding Saturation techniques SMT
Approximation models Using the models