slide 0 fmcad 2004 a simple method for parameterized verification of cache coherence protocols...
Post on 22-Dec-2015
217 views
TRANSCRIPT
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