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

Presentation on theme: "Exploiting the Dual View in Verification Koen Lindström Claessen Chalmers University Gothenburg, Sweden."— Presentation transcript:

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

informal formal Verification w/ Theorem Proving System Under Verification Expected/Wanted Property formula S formula P S P? model ~ actual behavior of system model ~ allowed behavior of system is every actual behavior allowed? does (S&¬P) have a model? counter example correctness proof

Full Pure First-Order Logic (FOL) First-order logic Predicate/function symbols Equality Universal/existential quantification Not included Arithmetic Least fixpoints Induction

FOL Decidability formula (Assumptions & ¬ProofObligation) contradiction (proof) satisfiable (model) infinite domain finite domain ? counter example correctness proof FOL is semi- decidable a domain (a set); plus interpretations for function/predicate symbols

This Talk Present an alternative view Dual View Though experiment with initial success System correct Formula satisfiable Model ~ correctness witness System incorrect Formula unsatisfiable Proof ~ concrete bug trace

Example: Ball Game Balls outin same different Can the last ball be red? green? 50

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 state r(s 50 (0),s 50 (0)). % transitions r(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) provable iff. (n,m) reachable -r(0,s(0)).

The Model (final state: -r(0,s(0))) 0 = '1 r('1,'1) : TRUE r('1,'2) : FALSE r('2,'1) : TRUE r('2,'2) : FALSE s('1) = '2 s('2) = '1 This is an abstraction of the original system

Modelling the Ball Game in FOL % initial states i(N,0). i(N,M) i(N,s(s(M))). i(N,M) r(N,M). % transitions r(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 Model 0 = '1 i('1,'1) : TRUE i('1,'2) : FALSE i('2,'1) : TRUE i('2,'2) : FALSE r('1,'1) : TRUE r('1,'2) : FALSE r('2,'1) : TRUE r('2,'2) : FALSE s('1) = '2 s('2) = '1 This is an abstraction of the original system, which has an infinite amount of states!

Summary Traditional view Proof ~ system correct Counter model ~ system incorrect Dual view Proof ~ system incorrect Model ~ system correct

Problem to FOL Mapping formula contradiction (proof) satisfiable (model) infinite domain finite domain ? Hard

Natural Mapping? Traditional Correctness ~ 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

informal formal Verification w/ Dual View System Under Verification Expected/Wanted Property formula S formula P M|=S&P? one intended model ~ all behaviors of system model ~ system satisfying the property counter proof model s reachable iff. r(s) provable ¬r(s bad )

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 Weidenbachs security protocols with SPASS finite-domain model finding

Process Calculus P ::= nilterminated process | f(e1,...,ek)call a process | P || Qparallell composition | P + Qchoice | e ! Psend | p ? Preceive synchronous + definitions

Example % server server = req ? rel ? server % clients clients = client || client || client client = req ! doit doit = rel ! client % top level top = 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 ::= nilterminated process | f(e1,...,ek)call a process | P || Qparallell composition | P + Qchoice | e ! Psend | p ? Preceive Syntactically, FOL terms already Special treatment

General Axioms (FOL) % parallel composition (P || Q) || R = P || (Q || R). P || Q = Q || P. P || nil = P. % choice r( (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 % server server = req ? rel ? server % clients clients = client || client || client client = req ! doit doit = rel ! client % top level top = server || clients

Example, fixed % server server = req ? waiting waiting = rel ? server % clients clients = client || client || client client = req ! doit doit = rel ! client % top level top = 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 % server r( server || (req ! P) || Q ) r( waiting || P || Q ). r( waiting || (rel ! P) || Q ) r( server || P || Q ). % clients clients = client || client || client. client = req ! doit. doit = rel ! client. % top level top = 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 reachability Bad state: M(r(s bad )) = FALSE Model is an abstraction

Example, infinite % server server = req ? waiting waiting = rel ? server % clients clients = client || clients client = req ! doit doit = rel ! client % top level top = server || clients

Process Calculus P ::= nilterminated process | f(e1,...,ek)call a process | P || Qparallell composition | P + Qchoice | e! send | p ? Preceive | new x. Pnew objects asynchronous

Example % server server = req(A) ? (ack(A)! || waiting(A)) waiting(A) = rel(A) ? server % clients clients = (new A. client(A)) || clients client(A) = req(A)! || doit(A) doit(A) = ack(A) ? (rel(A)! || client(A)) % top level top = server || clients

Example in FOL % server r( server || req(A)! || Q ) r( ack(A)! || waiting(A) || Q ). r( waiting(A) || rel(A)! || Q ) r( server || Q ). % clients r( 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 level top = 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 problem Works for all computation! Disadvantages Careful axiomatizations Danger of infinite models FOL proving ~ computing

Other constructs Higher-order calculi Processes are just terms, like messages Channels Use the idea behind the new construct Unbounded queues Messages with sender and receiver Tag send construct with extra information

Paradox Finite-domain model finder Finds finite domain Finds interpretations Full pure first-order logic Constants, functions, predicates Quantifiers Equality (Untyped) Winner of CASC 2003,2004,2005,2006

FOL Decidability formula contradiction (proof) satisfiable (model) infinite domain finite domain ? Hard

Paradox Applications Satisfiability Proof wont go trhough Bad state is unreachable Model Math: group theory, algebra Counter example Abstraction Decision procedure For FOL with finite domains

Paradox Overview FOL problem ClausifierFlattener Instantiate SAT Solver n:=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 D Only size matters D = {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 FOL problem ClausifierFlattener Instantiate SAT Solver n:=n+1 n:=1 no yes Under the assumption of totalness for size n

Complexity Instantiation Domain size n Number of variables per clause k O(n k ) 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(n 6 ) -(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 x 5 variables: O(n 5 )

Splitting Algorithm X V Z U W Y

X V Z U W Graph tree- decomposition

Other Techniques Cliques Pre-assign domain values Symmetry reduction All permutations are also a model Force a particular permutation Type inference Some types can have smaller domains Apply symmetry reduction for each type

General Results Good splitting is vital for feasibility Term-based splitting Variable splitting Symmetry reduction Makes SAT problem easier Type inference and domain reduction Makes some problems feasible

Typical Behavior Domain sizes 6,7,8 No problem Degree 5 Domains up to size 20

Using Paradox in the Dual View Increase possibility For finite models For small models For small representations of models Give freedom … To do as much as possible with as few domain elements as possible

Example: Unbounded Channels % queues cat(empty,Q) = Q & cat(Q,empty) = Q. cat(Q1,cat(Q2,Q3)) = cat(cat(Q1,Q2),Q3). % initial state r( stateA, empty, stateP, empty). % state transitions r( stateA, Q1, S2, cat(unit(a), Q2) ) r( stateB, cat(Q1, unit(b)), S2, Q2 ).... AB ?a !b PQ !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 complicated Larger domain Possibly infinite!

Trick 1: Copy Symbols & Axioms % queues cat1(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 state r( stateA, empty1, stateP, empty2). % state transitions r( 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 % queues cat1(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 state r( stateA, empty1, stateP, empty2). % state transitions r( 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 problem Using 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 2 More types, more freedom

Multiple Domains FOL problem ClausifierFlattener Instantiate SAT Solver n i :=n i +1 n 1 :=1,n 2 :=1,n 3 :=1 no yes why? pick i Under the assumption of totalness for sizes n 1,n 2,n 3 MiniSat extension: conflict clause = subset of assumptions

Example: Arity-reduction % initial state r( 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^16 n=2: 2^16 n=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) T Worst-case: |T| = |A| x |B| Better cases: |T| << |A| x |B| Information-coupling Automation… ?

Tricks Multiple interpretations Several similar symbols Copy axiomatization Multiple domain sizes Feedback from incremental SAT-solver Arity-reducing transformations Feasibility of building the model

Results Abstractions of finite systems Visualization Abstraction refinement Abstractions of infinite systems Works surprisingly often Techniques for reducing needed size Techniques 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 Tricks work also for other problems TPTP

Future Work Characterize when it works Techniques for making it work Infinite model finding Saturation techniques SMT Approximation models Using the models

Download ppt "Exploiting the Dual View in Verification Koen Lindström Claessen Chalmers University Gothenburg, Sweden."

Similar presentations