700 likes | 835 Views
This talk presents a novel approach to system verification using the Dual View paradigm, which contrasts the traditional verification method. It covers the relationship between actual behavior (S) and expected properties (P) of systems using first-order logic (FOL). We explore how the dual perspective allows for proving both correctness and incorrectness efficiently, highlighting examples like the Ball Game to illustrate formal modeling. Discussions include finite and infinite domains, satisfiability, and the challenges of mapping real-world systems into logical frameworks.
E N D
Exploitingthe Dual Viewin 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 formula S formula P counter example correctness proof is every actual behavior allowed? SP? does (S&¬P) have a model?
Full Pure First-Order Logic (FOL) • First-order logic • Predicate/function symbols • Equality • Universal/existential quantification • Not included • Arithmetic • Least fixpoints • Induction
contradiction (proof) satisfiable (model) infinite domain finite domain FOL Decidability a domain (a set); plus interpretations for function/predicate symbols formula (Assumptions & ¬ProofObligation) counter example correctness proof FOL is semi-decidable ?
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
out in same different Example: Ball Game Balls 50 50 Can the last ball be red? green?
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(s50(0),s50(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)). r(n,m) provable iff. (n,m) reachable % final state -r(s(0),0). -r(0,s(0)).
The Model (final state: -r(0,s(0))) 0 = '1 p('1,'1) : TRUE p('1,'2) : FALSE p('2,'1) : TRUE p('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 p('1,'1) : TRUE p('1,'2) : FALSE p('2,'1) : TRUE p('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
contradiction (proof) satisfiable (model) infinite domain finite domain Problem to FOL Mapping Hard formula ?
Natural Mapping? conceptually hard • Traditional • Correctness ~ proof • Needs induction/meta-reasoning • Hard • Incorrectness ~ bug trace • Finding a model • Hard conceptually easy
Natural Mapping • Dual View • Incorrectness ~ proof • Finding bug trace is easy • Proof is easy • Correctness ~ model • Correctness is hard • Finding model is hard
Verification w/ Dual View System Under Verification Expected/Wanted Property s reachable iff. r(s)provable informal formal ¬r(sbad) formula S formula P counter proof model one intended model ~ all behaviors of system model ~ system satisfying the property M|=S&P?
Summary Dual View reachability ~ provability correctness ~ unreachability use model finder correctness ~ unprovability use theorem prover incorrectness ~ provability
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 % 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 ::= 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 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(sbad)) = 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 ::= 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 % 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 Winner of CASC 2003,2004,2005,2006 • Finite-domain model finder • Finds finite domain • Finds interpretations • Full pure first-order logic • Constants, functions, predicates • Quantifiers • Equality • (Untyped)
contradiction (proof) satisfiable (model) infinite domain finite domain FOL Decidability Hard formula ?
Paradox Applications • Satisfiability • Proof won’t 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 MiniSat (Sörensson, Eén) Clausifier Flattener n:=1 Instantiate SAT Solver n:=n+1 no yes
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 Under the assumption of totalness for size n FOL problem Clausifier Flattener n:=1 Instantiate SAT Solver n:=n+1 no yes
Complexity • Instantiation • Domain size n • Number of variables per clause k • O(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 New predicate s 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) 2 x 5 variables: O(n5)