Slide 1 FMCAD 2004

A Simple Method for Parameterized VerificationA Simple Method for Parameterized Verificationof Cache Coherence Protocolsof Cache Coherence Protocols

Ching-Tsun Chou

Phanindra K. Mannava

Seungjoon Park

Microprocessor Technology Lab

Corporate Technology Group

Intel Corporation

Slide 2 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 3 FMCAD 2004

Outline

Motivations Contributions Simulation proof techniques Abstraction for parameterized verification Experimental results Comparison with other works Possible future work

Slide 4 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 5 FMCAD 2004

Outline

Motivations Contributions Simulation proof techniques Abstraction for parameterized verification Experimental results Comparison with other works Possible future work

Slide 6 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 7 FMCAD 2004

Outline

Motivations Contributions Simulation proof techniques Abstraction for parameterized verification Experimental results Comparison with other works Possible future work

Slide 8 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 | s0, s1, …, sn : s0 I i : si, si+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 9 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 10 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 11 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 12 FMCAD 2004

Simulation proof for parameterized systems

The abstract system is the product of all “views” of the concrete system, M = v V Mv , where Mv = (Sv, Iv, Tv)

“Views” are not the components of the parameterized system Proof obligations:

v V : s I : fv(s) Iv v V : s, s’ T : [ u V : fu(s) (Mu) ] fv(s), fv(s’) Tv

Conclusion: s (M) : [ v V : fv(s) (Mv) ]

Corollary: v V : Qv: Qv is an invariant of Mv fv

-1(Qv) is an invariant of M Remarks:

“u V : fu(s) (Mu)” appears only as an assumption and hence can be weakened to “u V : fu (s) Qu” for any invariants Qu of Mu

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 13 FMCAD 2004

Outline

Motivations Contributions Simulation proof techniques Abstraction for parameterized verification Experimental results Comparison with other works Possible future work

Slide 14 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 15 FMCAD 2004

Abstracting states: Basic idea

E I I IReqS(2)E(1)

Cache 3Home Cache 2Cache 1 Cache 4

E IReqS(2)E(1)

Home Cache 2Cache 1View{1, 2}

Slide 16 FMCAD 2004

Abstracting states: The need for Other

I I E IReqS(2)E(3)

Cache 3Home Cache 2Cache 1 Cache 4

I IReqS(2)E(?)

Home Cache 2Cache 1View{1, 2}

Slide 17 FMCAD 2004

Abstracting states: The need for Other

I I E IReqS(2)E(3)

Cache 3Home Cache 2Cache 1 Cache 4

I IReqS(2)E(Other)

Home Cache 2Cache 1 OtherView{1, 2}

Other is a special node idand has no state

Slide 18 FMCAD 2004

Abstracting transitions: The easy case

E I I IReqS(2)E(1)

Cache 3Home Cache 2Cache 1 Cache 4

InvAck

E IReqS(2)E(1)

Home Cache 2Cache 1View{1, 2}

InvAck

Slide 19 FMCAD 2004

Abstracting transitions: The not-so-easy case

I I E IReqS(2)E(3)

Cache 3Home Cache 2Cache 1 Cache 4

InvAck

I IReqS(2)E(Other)

Home Cache 2Cache 1 OtherView{1, 2}

InvAck

Slide 20 FMCAD 2004

Abstracting transitions: The hard case

E I I IReqS(2)E(1)

Cache 3Home Cache 2Cache 1 Cache 4

InvAck

E IReqS(2)E(1)

Home Cache 2Cache 1 OtherView{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 21 FMCAD 2004

Justifying noninterference lemmas

E I I IReqS(2)E(1)

Cache 3Home Cache 2Cache 1 Cache 4

Lemma: If Cache 1 is E, then Cache 3 or 4 does not send InvAck

EReqS(Other)

E(1)

Home Cache 1View{1, 3} I

Cache 3

Lemma: If Cache 1 is E, then Cache 3 does not send InvAck

EReqS(Other)

E(1)

Home Cache 1View{1, 4} I

Cache 4

Lemma: If Cache 1 is E, then Cache 4 does not send InvAck

Slide 22 FMCAD 2004

Simulation proof for parameterized systems (recapped)

The abstract system is the product of all “views” of the concrete system, M = v V Mv , where Mv = (Sv, Iv, Tv)

“Views” are not the components of the parameterized system Proof obligations:

v V : s I : fv(s) Iv v V : s, s’ T : [ u V : fu(s) (Mu) ] fv(s), fv(s’) Tv

Conclusion: s (M) : [ v V : fv(s) (Mv) ]

Corollary: v V : Qv: Qv is an invariant of Mv fv

-1(Qv) is an invariant of M

Remarks: “u V : fu(s) (Mu)” appears only as an assumption and hence can be

weakened to “u V : fu (s) Qu” for any invariants Qu of Mu

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 23 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 24 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 25 FMCAD 2004

Outline

Motivations Contributions Simulation proof techniques Abstraction for parameterized verification Experimental results Comparison with other works Possible future work

Slide 26 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 27 FMCAD 2004

Outline

Motivations Contributions Simulation proof techniques Abstraction for parameterized verification Experimental results Comparison with other works Possible future work

Slide 28 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 29 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 30 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 N0 nodes

For the German protocol, N0 = 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 N0 is likely to be too large to be feasible

Why is N0 too large? The bound N0 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 31 FMCAD 2004

Outline

Motivations Contributions Simulation proof techniques Abstraction for parameterized verification Experimental results Comparison with other works Possible future work

Slide 32 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 33 FMCAD 2004

Questions?

Slide 34 FMCAD 2004

Backup