Counterexample Guided Invariant Discovery for Parameterized Cache Coherence Verification Sudhindra Pandav Konrad Slind Ganesh Gopalakrishnan

Motivation Parameterized verification methods are of growing importance for large scale verification Despite the current state of art, parameterized verification –still highly manual and ingenious process –almost inapplicable for large system verification Using the current technology standards, can we make the verification process at usage level –more easy, more structured and more practical? Symbiosis --- can we benefit from system designer’s insights?

Contributions Invariant discovery for parameterized verification of safety properties Based on syntactic analysis of counterexamples to discover only relevant invariants Heuristics for directory-based cache coherence protocols (important class of parameterized systems) to minimize the number of predicates in the generated invariants Case studies: German, FLASH, German-Ring.

Inductive Invariant Checking: Basics Let θ be the initial state formula. Let δ be the transition formula. Let P be the property to be proved. Generate an inductive invariant Q s.t – θ => P –Q /\ δ => Q’ –Q => P How to generate Q ?

Inductive Invariant Checking: Practice s t  General State Verification: For all states s & t, such that s ∈ R, t ∈ R, verify that the property P(s) => P(t) all states diagrams not up to scale Reachable states (R) initial states (I) Auxiliary invariant Q Inductive invariant checking: I ⊂ Q Q(s) => Q(t) Q(s) /\ P(s) => P(t)

System Model We model the system as a tuple where V = set of system variables  = initial state formula  = set of rules of form: g => a, where g = boolean condition(guard) a = next state assignment of state variables(action) We also have a set of input variables I, which are assigned arbitrary values in each step of operation. –The guard g consists of variables on ( V U I ) Expressions are logical formulae over the theory of equality and uninterpreted functions –Values can be integers, booleans, functions (integer arrays) or predicates (boolean arrays).

Property Safety properties we verify are of form:  X. A(X) => C(X) where –X is the set of variables (index variables) –A is the antecedent – C is the consequent Example: –  i,j. ((i != j) & (cache(i) = exclusive)) => (cache(j) = invalid) ;

Invariant Discovery Process: Counterexample Analysis Overview Since we start from a general state, we are bound to get failure cases Failure cases classified into three possible classes Syntactic analysis of failure case: –Pick relevant predicates from Predicates in the property Predicates in the transition rule Interpretation to input variables ( I ) and index variables ( X ) –Construct auxiliary invariant by substituting in the formula suggested for the corresponding failure class

Counterexample Counterexample is a trace consisting of two states and a transition rule that leads one state to another, which violates the property. Formally, a counterexample C can be expressed as a tuple, where –  s is the initial state interpretation –  t is the next state interpretation –  is the transition rule of form: g => a

Failure Classes Counterexample C = Property P:  X.A(X) => C(X) Since, the initial state satisfies the property and the next state violates it, we can classify counterexamples into three different classes. – (  s |= A,  s |= C) (  t |= A,  t !|= C) –(  s ! |= A,  s ! |= C) (  t |= A,  t !|= C) –(  s ! |= A,  s |= C) (  t |= A,  t !|= C) We analyze each case and suggest a formula to construct auxiliary invariant

Case I: (  s |= A,  s |= C) (  t |= A,  t !|= C) st ACAC A ~C A => ~g SC(A,  s ) SC(g,  s ) Candidate invariant generated: SC(A,  s ) => ~SC(g,  s ) where SC is the satisfying core under interpretation  s. SC can be easily computed from the structure of formula g

Case II: (  s ! |= A,  s !|= C) (  t |= A,  t !|= C) st ~A ~C A ~C a retains VC(C,  s ) SC(g,  s ) Candidate invariant generated: ~VC(C,  s ) => ~SC(g,  s ) where VC is the violating core under interpretation  s. VC can be easily computed from the structure of formula ~C => ~g g

Case III: (  s ! |= A,  s |= C) (  t |= A,  t !|= C) st g ~A C A ~C a a Probably a concrete counterexample, as the action assigns next state values to variables in both A and C s.t they contradict. helps identify errors in models

Example: German protocol  i,j. cache(i) = exclusive => ch2(j) != grant_sh Counterexample: Start state j = curr_client cache(i) = exclusive ch2(j) = empty excl_granted = F Next state ch2(j) = grant_sh cache(i) = exclusive rule 9 (current_cmd = req_sh) /\ ~excl_granted /\ ch2(curr_client) = empty => cache(curr_client) = grant_sh; … type I counterexample: SC(A,  s ) => ~SC(g,  s )  i,j. cache(i) = exclusive => ~((current_cmd = req_sh) /\ ~excl_granted /\ ch2(j) = empty)

Filtering Heuristics Guards of transition rules are very much complex, containing many predicates. –More the number of predicates in an auxiliary invariant, more the number of counterexamples Usage-specific heuristics to filter relevant predicates in a structured way We suggest heuristics for directory based cache coherence protocols based on empirical observations

Heuristics for dir based cache coherence protocols Order predicates in guard depending on type of the rule (R), msg type (m), client type (c) and state variables. Type of rules: –P-rule: initiated by requesting node –N-rule: initiated by msg from network Type of msgs: –Request: req msg from caching node to home node –Grant: msg from home to caching node, acks, … State variables: –local: variables describing state of cache –directory: variables describing directory –environment: variables describing global state –channel: variables describing msg on network channels Such categorization is natural for designers.

Filtering Heuristics for dir based cache coherence protocols

Example: German protocol  i,j. cache(i) = exclusive => ch2(j) != grant_sh Counterexample: Start state j = curr_client cache(i) = exclusive ch2(j) = empty excl_granted = F Next state ch2(j) = grant_sh cache(i) = exclusive rule 9 (current_cmd = req_sh) /\ ~excl_granted /\ ch2(curr_client) = empty => cache(curr_client) = grant_sh; … type I counterexample: SC(A,  s ) => ~SC(g,  s )  i,j. cache(i) = exclusive => ~((current_cmd = req_sh) /\ ~excl_granted /\ ch2(j) = empty) R = N-rule, m = request, c = home  select predicates on dir variables  i,j. cache(i) = exclusive => ~excl_granted

Results / Comparison

Conclusions Counterexample guided invariant discovery for safety property verification of parameterized systems. Simple heuristics to pick relevant predicates from guards of directory based cache protocols. Structured way of using verification technology for practical verification. Applied our methods to cache protocols from small to large scale examples. Future Work: –Automation Counterexample analysis steps can be automated –Application to other large examples

References Counter-example based predicate discovery in predicate abstraction [Das et.al., FMCAD’02] Parameterized verification of a cache coherence protocol [Baukus et.al., VMCAI’02] A simple method for parameterized verification of cache coherence protocols [Ching-Tsun Chou et.al., FMCAD’04] Indexed predicate discovery for unbounded system verification [Lahiri et.al., CAV’04] Automatic deductive verification with invisible invariants [Pnueli et.al., TACAS’01] Empirically efficient verification for a class of infinite state systems [Bingham et.al., TACAS’02] A synthesizer of inductive assertions [German et.al., IEEE trans.’75]

Backup

System Operation At each step of operation, Input variables are assigned arbitrary values A rule  ∈  is nondeterministically selected for execution If the guard g is enabled (true), then next state values are assigned to state variables in the action a. –State variables which are not assigned in action retain their values.

Depending on the structure of the counterexample, we construct an auxiliary invariant from –those predicates in the property P, which have been violated –predicates from the guard and ITE (“if-then- else”) conditions in the action

Framework of verification process P unproved P proved P unproved ={} “done” Y N Pick a property P from P unproved Automated Decision Procedure D System model M counterexample Counterexample Analysis Procedure Auxiliary Invariant Add P