exploiting the dual view in verification

70
Exploiting the Dual View in Verification Koen Lindström Claessen Chalmers University Gothenburg, Sweden

Upload: scarlett-berg

Post on 30-Dec-2015

16 views

Category:

Documents


3 download

DESCRIPTION

Exploiting the Dual View in Verification. Koen Lindström Claessen Chalmers University Gothenburg, Sweden. Verification w/ Theorem Proving. System Under Verification. Expected/Wanted Property. model ~ actual behavior of system. model ~ allowed behavior of system. informal formal. - PowerPoint PPT Presentation

TRANSCRIPT

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

p('1,'1) : TRUEp('1,'2) : FALSEp('2,'1) : TRUEp('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

p('1,'1) : TRUEp('1,'2) : FALSEp('2,'1) : TRUEp('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