An Approach to Preserve Protocol Consistency and Executability Across Updates

1. An Approach to Preserve Protocol Consistency and Executability Across Updates M. Subramaniam University of Nebraska at Omaha Joint Work with P. Chundi

2. Outline • Motivation and goal • Specifying protocols and updates • Consistent single rule updates • Add-updates • Replace-updates • Consistent multi-rule updates • Conclusions

3. Motivation • Verified protocols are updated several times in practice. • Ad hoc updates are error prone and may require extensive debugging. • Subtle interactions in protocols and lack of systematic specification of updates impose considerable burden on users to identify what changes led to what errors. • Updates are often non-monotonic with respect to properties.

4. Goal • Systematic approach to update protocols to aid re-verification by early error detection.

5. Proposed Approach • Explicitly specify updates and generate updated protocols without manual intervention. • An update is a finite set of rules that add, replace, and/or delete protocol transitions. • Identify pre-conditions under which an update can be applied • Every update must preserve protocol consistency and executability (application-independent protocol properties in general) • Conditions are based on the structure of the rules and reachability of protocol transitions. • The new protocol generated from a given consistent and executable protocol is guaranteed to be consistent and executable whenever the conditions are met. • An update fails whenever the conditions are not met.

6. Request Controller I Read/Read Busy1 Ackdirty/ S Example- A Cache Coherence Protocol Scenario Reply Controller M Read /Ackdirty S Memory Read/ free Busy Ackdirty/ Initial States: Request/Reply Controller: I, S, M Memory: free

7. Request Controller I Read/Read Busy1 Ackdirty/ S Example – Updating Cache Coherence Protocol Reply Controller M Read /Ackdirty Read /Ackdirty I S Memory Read/ free Busy Ackdirty/ Update rule Match: Read, M  S, Ackdirty Change: Read, M  I, Ackdirty

8. Example – Updating Coherence Protocol- II • Consistency and Executability • Is the change reachable ? • Is every reachable path part of a run ? • inputs of match and change are same. • output msg. of change and match are same. • output state of change is an initial state. • Are transitions “dependent” on match still reachable and part of a run ? • transitions reaching match, reach change. • no transitions follow match. • Can we still reach from any legal initial state to another one ? • match does not dominate any initial state. Request Controller Reply Controller I M Read /Ackdirty Read/Read Read /Ackdirty Busy1 I S Ackdirty/ S Memory Read/ free Busy Ackdirty/ Update rule Match: Read, M  S, Ack dirty Change: Read, M  I, Ack dirty

9. Modeling Protocols • Protocol P is a network of communicating finite state machines (CFSMs) with bounded message queues [Brand]. • P = (E, P1, …, Pn) where E is the environment and each Pi is a finite state machine • Si is the states of Pi ; Iiis the initial states of Pi • M (j, i) is the set of messages from Pj to Pi; M (i, i) = {} • Ti : M (j, i) x Si Si, {M (i, k)},k = 1 to n, j, k≠i is a deterministic transition relation. • (i, j) stands for the queue containing messages from Pi to Pj; (i, i) = {}.

10. Modeling Protocols (contd.) • Global state of P is a pair [u, v] where • u is an n-tuple of controller states and • v represents the n2 + 2n queues • Initial global state: [u,v] where all elements of u are initial controller states and the queues have environment messages or are empty. • Execution step • [u1, v1]ti[u2, v2] if • u1[i] = input state of ti, v1(k, i) = input message of tifor some k • u2 is the same as u1 with its ith element being the output state of ti. • v2 is the same as v1 except de-queuing the input message of tiand en-queuing output messages of ti. • Executable path: [u0, v0]t0[u1, v1] ,..., tk[uk+1, vk+1] where each [ui, vi] ti[ui+1, vi+1] is a step. • Valid path (run): An executable path starting and ending in initial states.

11. Protocol Consistency and Executability • Consistency • Each transition appears in a valid path. • Every execution path is a prefix of a valid path. • Every controller has a deterministic transition relation. • Executability • There is a valid path between every pair of initial states of the protocol.

12. Specifying Updates • An update is a finite set of update rules. • Each update rule is an ordered-pair of transitions • Urk: Matchk Changek • A transition tmatches transition s if inputs (t) = inputs (s) • Apply(Urk, T) = T [ t Changek] if a transition t in Tmatches Matchk = T U Changek otherwise. • The new protocol is got by applying the update rules in an arbitrary order.

13. Single Rule Update • Ur: Match  Change • Add-update: An add-update adds a new combination of input message and input state to a controller. • No transitions in the protocol match Match. • Replace-update: Changes the outputs produced for an existing input combination by another. • there exists a protocol transition that matches Match.

14. Conditions on an add update rule • no new states can appear in Match or Change • no new messages can appear except to/from environment, • Change must match Match, and • the input state must be an initial state

15. Problem with non-matching Change • A transition matching Change but with different outputs may already exist. • Example: P: m1, s0  m1, s0 Ur: m2, s2  m1, s1  m1, s0  m2, s0 UP: m1, s0  m1, s0; m1, s0  m2, s0 • Violates consistency due to determinism.

16. Problem with a non-initial state • Change transition cannot appear in a valid path since the same executable path must enable two transitions with different input combinations. P1 P2 m4/m5 S0 m0/m0 m0/m1 m1/m2 S0’ t0 m1/m2 m5/m6 S1 S2 m2/m3 m3/m4

17. P1 P2 m4/m5 S0 m0/m0 m1/m2 S0’ t0 m7/m2 m5/m6 m0/m1 S1 S2 m2/m3 m3/m4 Ensuring that Changeis part of a run • Structural conditions suffice for add-updates involving only initial states. • However, in general, additional conditions based on • reachability are needed. [<s0, t0>, {m7}] m7, s0  s2, m2 [<s2, t0>, {m2}] m2, t0  t0, m3

18. Initial states Initial states ….. ….. ….. ….. p1 p2 pm qn qn-1 q1 Reachability Condition for Add-Update Change: m1(j, i), s1  s2, m2(i, k) Change [um, vm] where um [i] = s1 and vm (j, i) = m1 [un’, vn’] where un’ [i] = s2, v’m(j, i) = vm(j, i) – m1 vn’ (i, k) = vm(i, k) + m2 • Change is reachable and • for each pm there exists a qn such that • components of um and u’n are equal except for the ith one and • queues of vm and v’n are equal except for (j, i) and (i, k).

19. Consistency and Executability: Add-update • Theorem: An add-update preserves consistency and executability if and only if • structural conditions on the update rule and • reachability conditions on the update rule hold.

20. Replace-Update • Change the outputs of an existing transition. • Ur: MatchChangesuch that there is a transition matchingMatch. • Structural conditions of add-updates can be relaxed • the input state can be any existing state. • Reachability conditions of add-update need to be strengthened • transitions that follow Match in any valid path must appear with transitions other than Match • every transition dominatedby Match is reachable from Change.

21. Consistency and Executability: Replace-Update Theorem:Replace-update preserves consistency and executability if and only if • the relaxed structural conditions hold and • the strengthened reachability conditions hold.

22. More Complex Updates • Single rule updates are restrictive • transitions cannot be deleted • new states and/or new messages cannot be introduced • Multi-rule updates • allow new states, new messages to be introduced • transitions can be added, replaced, and/or deleted across one or more controllers.

23. Handling Multi-rule updates • Obtain the same updated protocol independent of the order in which the rules are applied. • Pre-condition on the update is expressed as a conjunction of the pre-conditions on individual rules. • Pre-conditions of a rule are evaluated over the protocol using the other rules as the context.

24. Rules in Multi-rule updates • Given, Ur = {Ur1, …, Urm} • Urk:Matchk Changek • Add-rule : No protocol transition matches Matchk • Replace-rule: There exists a change transition Changel and a protocol transition, both matching Matchk. • Delete-rule: Some protocol transition matches Matchk but there is no change transitionmatchingMatchk

25. Conditions on Rules • Given, Ur = {Ur1, …, Urm}, • for each update rule, Urk:Matchk Changek,Changek matches some Matchl. • Order-independence: For any two update rules, Urk:Matchk Changek , Url:Matchl Changel, either Changekdoes not match Matchl or Changeldoes not match Matchk or Changek = Changel.

26. Checking Individual Rules • For each rule Urk: Matchk Changek, • Add-rule: Add-update reachability conditions hold over the protocol using the other rules as the context. • Replace-rule: Replace-update reachability conditions hold over the protocol using the other rules as the context. • Delete-rule: Each transition that can only appear in valid paths containing Matchk appears as the match transition of some other delete rule.

27. Application and Experiments • Cache Coherence Protocols [Culler] • Snoop and directory based protocols • Most design choices has been specified as updates to produce consistent and executable protocol variants. • introduce new Upgrade/Downgrade transactions, • change memory-cache transfer to cache-cache transfers, • MSI  MESI  MOESI • Network Protocols TCP/IP [Comer] • 3-way handshake for reliable communication. • A protocol update prototype has been built and uses an in-house explicit state enumeration procedure along with static analyses to perform the above experiments. • Ongoing plans to replace the in-house implementation with customized Murphi [Dill] model checker.

28. Conclusions • A simple approach to systematically update finite-state protocols to aid re-verification in real designs is proposed. • Protocol updates are explicitly specified as a finite set of rules with ordered-pairs of transitions. Rules may add, replace, and/or delete transitions. • Pre-conditions are identified based on structure of update rules and reachability to preserve consistency and executability of protocols across updates. • The effectiveness of the approach is illustrated by applying it to a large class of cache coherence protocols and aspects of network protocols.

29. In progress… • Expand the class of application independent properties to include other properties such as the absence of deadlocks. • Identify update classes for which preservation of application independent properties can be more efficiently checked. • Develop methods to capture effects of protocol changes on application-specific verification infrastructure like runtime monitors.