Slide 0 FMCAD 2004 A Simple Method for Parameterized Verification of Cache Coherence Protocols Ching-Tsun Chou Phanindra K. Mannava Seungjoon Park Microprocessor Technology Lab Corporate Technology Group Intel Corporation

Slide 1 FMCAD 2004 Outline Motivations Contributions Simulation proof techniques Abstraction for parameterized verification Experimental results Comparison with other works Possible future work Note: Due to time limitations, this talk focuses on the concepts and theory behind our method and glosses over the practical aspects. For the latter, please read the paper

Slide 2 FMCAD 2004 Outline Motivations Contributions Simulation proof techniques Abstraction for parameterized verification Experimental results Comparison with other works Possible future work

Slide 3 FMCAD 2004 Motivations How can industrial cache coherence protocols be proved correct for arbitrary numbers of nodes (i.e., parameterized verification)? Verification of cache coherence protocols has been a major success story of formal methods in industry, but what is actually verified is typically a small configuration containing 3~4 nodes (caching agents) Protocol designers often have intuitions about why 3~4 nodes suffice to exhibit all “interesting” scenarios, but such intuitions are not formalized Our survey of FV literature suggests that the most practical technique for the parameterized verification of cache coherence protocols is McMillan’s composition model checking, but … The technique is implemented only in Cadence SMV, … Whose source code is not public Whose license agreement may limit its use in industry Which can only do symbolic (as opposed to explicit-state) model checking It is not clear what exactly goes on “under the hood” in Cadence SMV Is there an alternative formulation of McMillan’s ideas that is easy to understand and can be used with any model checkers? Experience shows that explicit-state model checkers, such as Murphi, is superior to symbolic model checkers for cache coherence protocols

Slide 4 FMCAD 2004 Outline Motivations Contributions Simulation proof techniques Abstraction for parameterized verification Experimental results Comparison with other works Possible future work

Slide 5 FMCAD 2004 Contributions We developed a method for the parameterized verification of cache coherence protocols that: Can be used with any model checker We use Murphi in this work Has a simple theory based on the classical notion of simulation proofs that justifies apparently circular reasoning Exposes what exactly goes on when a model is abstracted and how noninterference lemmas are applied Retains the chief advantage of McMillan’s technique: Strike the right balance between automation and human intervention Human insights are exploited to reduce model checking complexity Human inputs needed fall far short of full-blown inductive invariants We applied our method to the parameterized verification of: Steven German’s protocol Stanford’s FLASH protocol Which is sufficiently complex to be a good proxy for industrial protocol descriptions

Slide 6 FMCAD 2004 Outline Motivations Contributions Simulation proof techniques Abstraction for parameterized verification Experimental results Comparison with other works Possible future work

Slide 7 FMCAD 2004 State transition systems We focus on safety properties in this work A protocol is modeled as a state transition system M = (S, I, T), where: S is a set of states I  S is a set of initial states T  S  S is a transition relation such that  s  S :  s, s   T Stuttering steps are needed for technical reasons The set of reachable states of M is  (M) = {s  S |  s 0, s 1, …, s n : s 0  I   i :  s i, s i+1   T} State properties: An invariant of M is a set P  S such that  (M)  P An inductive invariant of M is a set P such that:  s  I : s  P  s, s’   T : s  P  s’  P  (M) is the strongest invariant of M and is always inductive All safety properties can be expressed as invariants, provided that sufficient history information is recorded in the state (possibly by adding history variables) Adding such history variables rarely presents a problem in practice

Slide 8 FMCAD 2004 Simulation proof Goal: To deduce properties of a concrete system M = (S, I, T) from those of an abstract system M = (S, I, T) via an abstraction function f : S  S Proof obligations:  s  I : f(s)  I  s, s’   T :  f(s), f(s’)   T Conclusion:  s   (M) : f(s)   (M) Corollary:  Q: Q is an invariant of M  f -1 (Q) is an invariant of M Remark: Unfortunately, this technique does not work when M is nontrivial, because typically the inductive step cannot be proved from an arbitrary current state s

Slide 9 FMCAD 2004 Simulation proof with inductive invariant Idea: Use an inductive invariant P of the concrete system M to constrain the current state in the inductive step Proof obligations:  s  I : f(s)  I  s  P  s, s’   T : s  P   f(s), f(s’)   T  s’  P Conclusion:  s   (M) : f(s)   (M)  s  P Corollary:  Q: Q is an invariant of M  f -1 (Q) is an invariant of M Remarks: Unfortunately, it is very hard to come up with an inductive invariant for a nontrivial cache coherence protocol Fortunately, there is an invariant that always works …

Slide 10 FMCAD 2004 Simulation proof with abstract invariant Idea: Use the set of reachable states of the abstract system,  (M), to produce an inductive invariant Proof obligations:  s  I : f(s)  I  s, s’   T : f(s)   (M)   f(s), f(s’)   T Conclusion:  s   (M) : f(s)   (M) Corollary:  Q: Q is an invariant of M  f -1 (Q) is an invariant of M Remarks: This is the ultimate source of apparent circularity in our method “f(s)   (M)” appears only as an assumption and hence can be weakened to “f(s)  Q” for any invariant Q of M

Slide 11 FMCAD 2004 Simulation proof for parameterized systems The abstract system is the product of all “views” of the concrete system, M =  v  V M v, where M v = (S v, I v, T v ) “Views” are not the components of the parameterized system Proof obligations:  v  V :  s  I : f v (s)  I v  v  V :  s, s’   T : [  u  V : f u (s)   (M u ) ]   f v (s), f v (s’)   T v Conclusion:  s   (M) : [  v  V : f v (s)   (M v ) ] Corollary:  v  V :  Q v : Q v is an invariant of M v  f v -1 (Q v ) is an invariant of M Remarks: “  u  V : f u (s)   (M u )” appears only as an assumption and hence can be weakened to “  u  V : f u (s)  Q u ” for any invariants Q u of M u Invariants of all views can be used as assumptions in the inductive step for each view When all components are symmetric, all views are also symmetric and there is only one representative view to consider in the proof obligations

Slide 12 FMCAD 2004 Outline Motivations Contributions Simulation proof techniques Abstraction for parameterized verification Experimental results Comparison with other works Possible future work

Slide 13 FMCAD 2004 Abstraction for parameterized verification Idea: Focus on the details of only a few components of a parameterized system and abstract away the details of other components We call this a view abstraction of the parameterized system and express it as a state transition system Each view abstraction is finite-state and hence can be analyzed by standard model checking Use a simulation proof to link the parameterized system and the view abstractions and to deduce properties of the former from those of the latter How do we actually construct the view abstractions?

Slide 14 FMCAD 2004 Abstracting states: Basic idea EI II ReqS(2) E(1) Cache 3HomeCache 2Cache 1Cache 4 EI ReqS(2) E(1) HomeCache 2Cache 1 View {1, 2}

Slide 15 FMCAD 2004 Abstracting states: The need for Other II EI ReqS(2) E(3) Cache 3HomeCache 2Cache 1Cache 4 II ReqS(2) E(?) HomeCache 2Cache 1 View {1, 2}

Slide 16 FMCAD 2004 Abstracting states: The need for Other II EI ReqS(2) E(3) Cache 3HomeCache 2Cache 1Cache 4 II ReqS(2) E(Other) HomeCache 2Cache 1 Other View {1, 2} Other is a special node id and has no state

Slide 17 FMCAD 2004 Abstracting transitions: The easy case EI II ReqS(2) E(1) Cache 3HomeCache 2Cache 1Cache 4 InvAck EI ReqS(2) E(1) HomeCache 2Cache 1 View {1, 2} InvAck

Slide 18 FMCAD 2004 Abstracting transitions: The not-so-easy case II EI ReqS(2) E(3) Cache 3HomeCache 2Cache 1Cache 4 InvAck II ReqS(2) E(Other) HomeCache 2Cache 1 Other View {1, 2} InvAck

Slide 19 FMCAD 2004 Abstracting transitions: The hard case EI II ReqS(2) E(1) Cache 3HomeCache 2Cache 1Cache 4 InvAck EI ReqS(2) E(1) HomeCache 2Cache 1 Other View {1, 2} InvAck Why? Because of this noninterference lemma: If Cache 1 is E, then Other does not send InvAck But how do we justify this noninterference lemma? Proving it directly on the concrete system would require an inductive invariant

Slide 20 FMCAD 2004 Justifying noninterference lemmas EI II ReqS(2) E(1) Cache 3HomeCache 2Cache 1Cache 4 Lemma: If Cache 1 is E, then Cache 3 or 4 does not send InvAck E ReqS(Other) E(1) HomeCache 1 View {1, 3} I Cache 3 Lemma: If Cache 1 is E, then Cache 3 does not send InvAck E ReqS(Other) E(1) HomeCache 1 View {1, 4} I Cache 4 Lemma: If Cache 1 is E, then Cache 4 does not send InvAck

Slide 21 FMCAD 2004 Simulation proof for parameterized systems (recapped) The abstract system is the product of all “views” of the concrete system, M =  v  V M v, where M v = (S v, I v, T v ) “Views” are not the components of the parameterized system Proof obligations:  v  V :  s  I : f v (s)  I v  v  V :  s, s’   T : [  u  V : f u (s)   (M u ) ]   f v (s), f v (s’)   T v Conclusion:  s   (M) : [  v  V : f v (s)   (M v ) ] Corollary:  v  V :  Q v : Q v is an invariant of M v  f v -1 (Q v ) is an invariant of M Remarks: “  u  V : f u (s)   (M u )” appears only as an assumption and hence can be weakened to “  u  V : f u (s)  Q u ” for any invariants Q u of M u These are the noninterference lemmas Invariants of all views can be used as assumptions in the inductive step for each view: In the example, v = {1, 2} and u = {1, 3} or {1, 4}

Slide 22 FMCAD 2004 How to construct view abstractions in practice Start with an abstract model that is obviously an over- approximation of the concrete system This step should be automatable Counterexample-guided discovery of noninterference lemmas: 1.Try to prove the desired properties and all noninterference lemmas discovered so far on the abstract model by model checking This step is automatic 2.If all properties pass, we are done and all properties and lemmas are true 3.Otherwise, analyze the counterexample to identify an offending action and formulate a new noninterference lemma to “fix” it This step requires human ingenuity and understanding of the protocol 4.Instantiate the new noninterference lemma to strengthen the precondition of the offending action in the abstract model This step should be largely automatable 5.Go back to step 1

Slide 23 FMCAD 2004 Some technical points How many components are needed in a view? Determined by the depth of quantifier nesting in system description and invariants (both desired properties and noninterference lemmas) To provide a maximally diverse interpretation of quantified formulas (i.e., different quantified variables are not forced to take on the same values due to the smallness of the universe) For typical directory-based cache coherence protocols, the number is 3 (home node, requesting node, snooped node) The number may be 2 if the home node is modeled by data structures that are not indexed by nodes How did we avoid 3-valued logics in view abstraction? Avoid evaluating “Other = Other” A node-valued state variable should never be compared with another node-valued state variable Avoid evaluating “Array[Other]” An array indexed by nodes should never be directly indexed into by a node-valued state variable In practice, the above rules can be enforced syntactically by introducing quantifiers and replacing state variables by (quantified) logic variables

Slide 24 FMCAD 2004 Outline Motivations Contributions Simulation proof techniques Abstraction for parameterized verification Experimental results Comparison with other works Possible future work

Slide 25 FMCAD 2004 Experimental results We verified both German and FLASH cache coherence protocols using our method and the Murphi model checker German protocol: Devised by Steven German as a challenge problem and widely used as an example in research papers on parameterized verification We added data-path logic and properties to the German protocol and found that proving those properties required us to prove more control properties than the mutual exclusion property A detailed description of our proof process is in the paper FLASH protocol: Park’s PVS model  McMillan’s SMV model  Our Murphi model, all by manual translation The complexity of FLASH makes it a good proxy for industrial cache coherence protocol descriptions Our FLASH proof is of comparable complexity as McMillan’s proof using compositional model checking and Cadence SMV Labor required: 3 days in total Translating SMV code into Murphi: 1 day Flushing out translation errors using model checking up to 4 nodes: 0.5 day Constructing initial abstraction by hand: 0.5 day Counterexample-guided discovery of noninterference lemmas: 1 day

Slide 26 FMCAD 2004 Outline Motivations Contributions Simulation proof techniques Abstraction for parameterized verification Experimental results Comparison with other works Possible future work

Slide 27 FMCAD 2004 Comparison with McMillan’s method We owe a great deal of intellectual debt to McMillan’s works Our method can be viewed as an alternative formulation of McMillan’s ideas McMillan’s results showed that something similar could be made to work McMillan’s method: Can prove liveness properties Uses abstract interpretation, which leads to a 3-valued logic Implemented only in Cadence SMV What exactly goes on in Cadence SMV is not entirely clear Our method: Does not (yet) handle liveness properties Uses classical notion of simulation proofs and 2-valued logic, but may require rewriting protocol descriptions Such rewriting is easy in practice and should be automatable Can be used with any model checker All steps have been spelled out in detail Many steps are currently carried out by hand but should be automatable It should be possible to automate our method to the same extent that McMillan’s method is automated in Cadence SMV

Slide 28 FMCAD 2004 Comparison with predicate abstraction A basic problem in applying predicate abstraction to parameterized verification: How to capture the “essential features” of an unbounded set of state variables using a finite set of predicates? Earlier works on predicate abstraction (by Baukus, Lakhnech & Stahl and by Das, Dill & Park) use predicates that contain quantified formulas Discovery of such predicates is hard Reasoning about such predicates is also hard A conceptual breakthrough was made recently by Lahiri & Bryant with their theory and algorithms for indexed predicates They used their method to verify the German protocol (without data-path but with unbounded FIFO queues) Conjecture: There are close connections between our method and Lahiri & Bryant’s method View abstraction  A canonical way of choosing predicates Discovery of noninterference lemmas  Reachability computation Instantiation of noninterference lemmas  Heuristics for universal quantifier instantiation in concretization function

Slide 29 FMCAD 2004 Comparison with invisible invariants Pnueli, Ruah & Zuck proposed a method for generating inductive invariants of a parameterized system by generalizing the reachable state set of a small instance with N 0 nodes For the German protocol, N 0 = 4 suffices The method is very attractive for being automatic, but it is unlikely to work for FLASH because: It is not clear that the method can handle node-valued arrays indexed by nodes, which are present in FLASH Even if it can, the bound N 0 is likely to be too large to be feasible Why is N 0 too large? The bound N 0 is basically determined by the #s of pointers and quantifiers in the protocol and property descriptions Their theory being completely general, protocol-specific knowledge (e.g., about the equality relations between pointers) is not exploited to reduce the bound But there is a strong resemblance between invisible invariants and view abstractions

Slide 30 FMCAD 2004 Outline Motivations Contributions Simulation proof techniques Abstraction for parameterized verification Experimental results Comparison with other works Possible future work

Slide 31 FMCAD 2004 Possible future work Automation: Construction of initial abstract model Maintenance of intermediate abstract models and noninterference lemmas Formalization: Formalize the theory and prove all theorems about simulation in HOL Formalize the protocol description in HOL Discharge the proof obligations in the simulation proof in HOL John Harrison has started doing the formalization in HOL In the above HOL can be replaced by any reasonable theorem prover Handling parameter sets that are not scalarsets Example: Bakery protocol Our indexed simulation proof technique is completely general Symmetry arguments are used only to cut down the number of distinct cases that need to be analyzed Reasoning about liveness properties

Slide 32 FMCAD 2004 Questions?

Slide 33 FMCAD 2004 Backup 