Protocol Verification using Flows: An Industrial Experience
Transcript of Protocol Verification using Flows: An Industrial Experience
![Page 1: Protocol Verification using Flows: An Industrial Experience](https://reader030.fdocuments.net/reader030/viewer/2022012810/61bfe60e39225c63093f5bd6/html5/thumbnails/1.jpg)
Protocol Verification using Flows:
An Industrial Experience
Murali Talupur
Joint work with
John O’ Leary, Mark R. Tuttle
SCL, Intel Corp
![Page 2: Protocol Verification using Flows: An Industrial Experience](https://reader030.fdocuments.net/reader030/viewer/2022012810/61bfe60e39225c63093f5bd6/html5/thumbnails/2.jpg)
Parametric Verification using Flows
1. CMP is an abstraction & compositional reasoning based method
1. Uses Model Checker as a proof assistant
2. Requires user guidance
2. Demonstrated that “flows” yield powerful invariants
1. Partial orders on “events”
2. Available for free
3. Applied it to German and Flash
P(N)True or Cex
Abstract
Strengthen
Model Check
InventLemma
PA
spurious cexP#(N)
Last year we introduced the CMP + Flows method for parametric protocol verification [FMCAD08]
![Page 3: Protocol Verification using Flows: An Industrial Experience](https://reader030.fdocuments.net/reader030/viewer/2022012810/61bfe60e39225c63093f5bd6/html5/thumbnails/3.jpg)
Verification of Larrabee Cache
Protocol
Fix
ed F
un
ctio
n L
og
ic
Mem
ory
& I
/O I
nte
rfac
es
Ring Network
CPU core
Coherent
L2 cache
CPU core
CPU core
CPU core
CPU core
CPU core
CPU core
CPU core
Coherent
L2 cache
Coherent
L2 cache
Coherent
L2 cache
Coherent
L2 cache
Coherent
L2 cache
Coherent
L2 cache
Coherent
L2 cache
…
…
…
…
Ring Network
This year we applied the method to a real, state-of-the-art cache protocol
To be used in Intel’s
Larrabee processors
LRB is several orders of magnitude larger than Flash (which is considered hard to verify)
50 message types vs 16 messages
70 Boolean state variables vs 10
![Page 4: Protocol Verification using Flows: An Industrial Experience](https://reader030.fdocuments.net/reader030/viewer/2022012810/61bfe60e39225c63093f5bd6/html5/thumbnails/4.jpg)
Lessons from our Effort
• A significant milestone– To our knowledge no protocol of this size has been verified at this level
of automation
– Proof required just 5 manual lemmas by hand• Dramatic reduction compared to 25 lemmas required for McOP protocol
using just CMP method[DCC08]
– CMP+Flows scales very well in terms of protocol size and manual effort required
• Demonstrates that powerful invariants, namely those from flows, are available essentially for free
• Ideas from our work will be useful in other contexts– Other message passing systems
– Shared memory systems, concurrent software verification as well
![Page 5: Protocol Verification using Flows: An Industrial Experience](https://reader030.fdocuments.net/reader030/viewer/2022012810/61bfe60e39225c63093f5bd6/html5/thumbnails/5.jpg)
Extensions Required
Notion of Flows had to be
generalized• From simple linear flows to
directed acyclic graphs
Additional invariants from
flows• Conflict between flows
Criteria to choose which
flows to use• Using all flows leads to state
explosion
iMem Dir
ReqS
RecvReqS
RecvAck
SndData
Wait
Data
SendAck
DataSentG
ntS
Dir i
SendReqS
SendGntS
RecvReqS
RecvGntS
Linear Flows DAG Flows
![Page 6: Protocol Verification using Flows: An Industrial Experience](https://reader030.fdocuments.net/reader030/viewer/2022012810/61bfe60e39225c63093f5bd6/html5/thumbnails/6.jpg)
Outline
BackgroundCMP methodFlows
Extensions Linear flows to dagsNew languageNew constraints
LRB verificationDetailsLessons
Conclusion
![Page 7: Protocol Verification using Flows: An Industrial Experience](https://reader030.fdocuments.net/reader030/viewer/2022012810/61bfe60e39225c63093f5bd6/html5/thumbnails/7.jpg)
Logical Model of a Cache Protocol
Directo
ry
Mem
6
5
4
3
1
2
![Page 8: Protocol Verification using Flows: An Industrial Experience](https://reader030.fdocuments.net/reader030/viewer/2022012810/61bfe60e39225c63093f5bd6/html5/thumbnails/8.jpg)
CMP+Flows Approach
Consists of two key elements
CMP Method:
•A general framework for verifying systems with
replication based on abstraction & compositional
reasoning
•We simplified and generalized the method
Flow based Invariants:
•A new method for discovering system invariants
•Implicit partial orders on system events yield valuable
invariants
![Page 9: Protocol Verification using Flows: An Industrial Experience](https://reader030.fdocuments.net/reader030/viewer/2022012810/61bfe60e39225c63093f5bd6/html5/thumbnails/9.jpg)
CMP Method
P(N) True or CexAbstract
Strengthen
Model Check
Invent
Lemma
PA
spurious cexP#(N)
Strengthening with L:
Each rule is of the form: rname: guard ���� action
Strengthened rule:rname: guard & L ���� action
![Page 10: Protocol Verification using Flows: An Industrial Experience](https://reader030.fdocuments.net/reader030/viewer/2022012810/61bfe60e39225c63093f5bd6/html5/thumbnails/10.jpg)
Abstraction in CMP
Data Type Reduction
Throws away the state spaces of agents 3..N
Any condition involving them is conservatively over-approximated
Syntactic & fast but leads to very abstract models
Other
21 N
21
N-13
P(N)
PA
![Page 11: Protocol Verification using Flows: An Industrial Experience](https://reader030.fdocuments.net/reader030/viewer/2022012810/61bfe60e39225c63093f5bd6/html5/thumbnails/11.jpg)
Inventing Lemmas
P(N)
Abstract
Strengthen
Model Check
InventLemma
PA
spurious cexP#(N)
Manual process (by examining spurious cexs)
Time consuming and requires insight
Drawback of all theorem proving style
methods
Flows can drastically reduce the “lemma burden”
![Page 12: Protocol Verification using Flows: An Industrial Experience](https://reader030.fdocuments.net/reader030/viewer/2022012810/61bfe60e39225c63093f5bd6/html5/thumbnails/12.jpg)
Dir i j
SendReqS
SendGntS
RecvReqS
RecvGntS
Process i intiates a Request Sharedtransaction: Case 1
Flows
Partial orders on system events
For cache protocols, sending and receiving of messages by various agents are
“events”
Each event corresponds to a well defined syntactic block of protocol code
For cache protocols written in Murphi, events are essentially rule names
For the rest of the talk:
Rule names ���� Events
![Page 13: Protocol Verification using Flows: An Industrial Experience](https://reader030.fdocuments.net/reader030/viewer/2022012810/61bfe60e39225c63093f5bd6/html5/thumbnails/13.jpg)
Constraints from Flows
Dir i j
SendReqS
SendGntS
RecvReqS
RecvGntS
Precedence between events:
For instance, for process i, action RecvReqS(i)must happen before SendGntS(i)
Flows are used and also validated
Wrong/incomplete flows are caught by the method
Sample invariant:
If guard for SendGntS is true then
history variables must record firing of RecvReqS
![Page 14: Protocol Verification using Flows: An Industrial Experience](https://reader030.fdocuments.net/reader030/viewer/2022012810/61bfe60e39225c63093f5bd6/html5/thumbnails/14.jpg)
Tracking Flows
A set Aux(i) of auxiliary variables to
track
1) all the flows that a process i is involved in
2) for each such flow the last rule that was fired
Each aux ∈ Aux(i) is initially
( no_flow, no_rule )
If process i fires rule rnamen in fname
update aux = (f,rnamen-1) to (f,rnamen)
If rnamen is the last rule reset the aux variable
rname1
rname2
rnamen-1
rnamen
rnamem
fname
![Page 15: Protocol Verification using Flows: An Industrial Experience](https://reader030.fdocuments.net/reader030/viewer/2022012810/61bfe60e39225c63093f5bd6/html5/thumbnails/15.jpg)
Outline
BackgroundCMP methodFlows
Extensions Linear flows to dagsNew languageNew constraints
LRB verificationDetailsLessons
Conclusion
![Page 16: Protocol Verification using Flows: An Industrial Experience](https://reader030.fdocuments.net/reader030/viewer/2022012810/61bfe60e39225c63093f5bd6/html5/thumbnails/16.jpg)
Typical LRB flowiMem Dir
ReqS
SndData
Data
SendAck
DataSent
Wait
RecvReqS
GntS
Flows are DAGs in real protocols unlike
“academic” protocols
SendAck depends on two other events:
Data and GntS
RecvReqS enbles two other events:
SndData and Wait
RecvAckFlattening out partial orders leads to
an explosion in the number of flows
A transaction for requesting shared access
Order between all events not specified:
For eg., GntS and Data
![Page 17: Protocol Verification using Flows: An Industrial Experience](https://reader030.fdocuments.net/reader030/viewer/2022012810/61bfe60e39225c63093f5bd6/html5/thumbnails/17.jpg)
Language for new Flows
Each flow is given by:
fname: {prec1, prec2,..,precn}
where each preci is an entry of the form
rname: rname1, .., rnamem
Name of the rule
firing
Name of the
flow
Names of the
preceding rules
![Page 18: Protocol Verification using Flows: An Industrial Experience](https://reader030.fdocuments.net/reader030/viewer/2022012810/61bfe60e39225c63093f5bd6/html5/thumbnails/18.jpg)
ExampleiMem Dir
ReqS
RecvReqS
RecvAck
SndData
Wait
Data
SendAck
DataSent
GntS
ReqShar: {prec1,.., prec9}
One of the ‘prec’s:
SendAck: GntS, Data
![Page 19: Protocol Verification using Flows: An Industrial Experience](https://reader030.fdocuments.net/reader030/viewer/2022012810/61bfe60e39225c63093f5bd6/html5/thumbnails/19.jpg)
Conflict sets
• Many flows are mutually exclusive
– For example, ReqShar cannot happen when ReqExcl is happening and vice-versa
• Because the directory can participate in only one of these at a time
• Further, many flows are such that only a single instance can be alive at any time
– ReqShar, ReqExcl for example
• With each flow we also associate a conflict set
![Page 20: Protocol Verification using Flows: An Industrial Experience](https://reader030.fdocuments.net/reader030/viewer/2022012810/61bfe60e39225c63093f5bd6/html5/thumbnails/20.jpg)
Language for flows
Each flow is given by:
fname, conflict_set: {prec1, prec2,..,precn}
where each preci is an entry of the form
(rname, id): (rname1,id1), .., (rnamem,idm)
Name of the rule
firing & id
Name of the flow
and conflict set
Names of the
preceding rules &
ids
We need event ids to distinguish occurrences of same
event in multiple flows.
![Page 21: Protocol Verification using Flows: An Industrial Experience](https://reader030.fdocuments.net/reader030/viewer/2022012810/61bfe60e39225c63093f5bd6/html5/thumbnails/21.jpg)
Invariants from Flows
• Invariants from precedence constraints:
– Constraints on events within a flow
– Extension to new language straight-forward
• Invariants from conflict constraints:
– Constraints on events across multiple flows
This is new!
![Page 22: Protocol Verification using Flows: An Industrial Experience](https://reader030.fdocuments.net/reader030/viewer/2022012810/61bfe60e39225c63093f5bd6/html5/thumbnails/22.jpg)
Conflict constraints
Suppose f1 and f2 conflict
Conflict constraint:
If f1 is active then f2 cannot become
active
Equivalently:
If there exists an aux variable
recording firing of an event from f1then e6 should not be enabled
Flow f1
iDir
e 1
e2
e5
iDir
e 6
e7
e10
Flow f2
e4 e9
Rest of events in f2 are disabled
by the precedence constraints
e3
e8
![Page 23: Protocol Verification using Flows: An Industrial Experience](https://reader030.fdocuments.net/reader030/viewer/2022012810/61bfe60e39225c63093f5bd6/html5/thumbnails/23.jpg)
Outline
BackgroundCMP methodFlows
Extensions Linear flows to dagsNew languageNew constraints
LRB verificationDetailsLessons
Conclusion
![Page 24: Protocol Verification using Flows: An Industrial Experience](https://reader030.fdocuments.net/reader030/viewer/2022012810/61bfe60e39225c63093f5bd6/html5/thumbnails/24.jpg)
LRB Cache Model
Directo
ry
Mem
6
5
4
3
1
2
High level model written
Murphi
Constructed semi-
automatically from tabular
description
Retained all the relevant
details
The various in- and out-
buffers and L1 cache
states
Retaining all the internal structure made characterizing when an agent has
access difficult
![Page 25: Protocol Verification using Flows: An Industrial Experience](https://reader030.fdocuments.net/reader030/viewer/2022012810/61bfe60e39225c63093f5bd6/html5/thumbnails/25.jpg)
LRB Proof (1)
• Property: If cache i has exclusive access to an item then no other cache j has access to the same item.
• The rules in Murphi model were very large covering multiple “events”– Single rule for “Receive” would cover different types of incoming messages
• Even though they belonged to completely different transactions
– We needed to break up the rules into smaller rules to get closer rule-event correspondence
• Done using simple rewriting procedures
• Model had some quirks– Many directory variables referred to using terms that had process ids
• Though they were essentially constants
– Leads to an unnecessarily abstract model
![Page 26: Protocol Verification using Flows: An Industrial Experience](https://reader030.fdocuments.net/reader030/viewer/2022012810/61bfe60e39225c63093f5bd6/html5/thumbnails/26.jpg)
LRB Proof (2)
• Abstraction was carried out using Abster– We need to specify how many agents to keep concrete in the
abstract model• 2 agents for LRB since we were verifying two indexed safety
properties
• Flows are also given as an input– We used about 15 flows from the design documents
• Covering transactions for shared and exclusive access– Left out flows for write backs and invalidates
– Flow invariants generated automatically– These led to 36 lemmas
• 25 from precedence constraints and 11 from conflict constraints
![Page 27: Protocol Verification using Flows: An Industrial Experience](https://reader030.fdocuments.net/reader030/viewer/2022012810/61bfe60e39225c63093f5bd6/html5/thumbnails/27.jpg)
LRB Proof (3)
• 5 manual lemmas on top to complete the proof
– Huge reduction compared to the 25 lemmas used for
McOP [DCC08]
• Architects were more impressed with flow
validation than with the global properties
verified!
• Murphi running time: 5.5 hrs
– Time taken for whole proof not clear
• Methodology development and proof went hand in hand
![Page 28: Protocol Verification using Flows: An Industrial Experience](https://reader030.fdocuments.net/reader030/viewer/2022012810/61bfe60e39225c63093f5bd6/html5/thumbnails/28.jpg)
State explosion from flows
• It does not help to track all the flows that we can get from the design documents!
• Only flows that appear in their own conflict sets should be used
– The rest lead to blow up in state space of the abstract model
• Multiple instantiations of a flow can be active at the same time
• Thus, the “other” agent can saturate the auxiliary variables
– Unexpected because the concrete model with auxiliary variables does not suffer from the same problem
![Page 29: Protocol Verification using Flows: An Industrial Experience](https://reader030.fdocuments.net/reader030/viewer/2022012810/61bfe60e39225c63093f5bd6/html5/thumbnails/29.jpg)
Outline
BackgroundCMP methodFlows
Extensions Linear flows to dagsNew languageNew constraints
LRB verificationDetailsLessons
Conclusion
![Page 30: Protocol Verification using Flows: An Industrial Experience](https://reader030.fdocuments.net/reader030/viewer/2022012810/61bfe60e39225c63093f5bd6/html5/thumbnails/30.jpg)
Existing Methods
Inde
x pr
edicat
es
WS1S
Counter A
bstracti
on
Regular Model C
hecking
Invis
ible Inva
riants
Agg
rega
ted
Trans
CM
P
Increasing Manual Effort
Theor
em P
roving
Automatic methods don’t scale
Theorem Proving style methods require human guidance
but scale
CM
P + F
lows
![Page 31: Protocol Verification using Flows: An Industrial Experience](https://reader030.fdocuments.net/reader030/viewer/2022012810/61bfe60e39225c63093f5bd6/html5/thumbnails/31.jpg)
Conclusion
• CMP + Flows method is highly scalable and easy to use– Perhaps the only method available for large
protocols
• Ideas generally applicable– Not limited to cache protocols
– Flows open up a new avenue to taming verification complexity
• By providing a way to harness informal high level reasoning in a precise manner
![Page 32: Protocol Verification using Flows: An Industrial Experience](https://reader030.fdocuments.net/reader030/viewer/2022012810/61bfe60e39225c63093f5bd6/html5/thumbnails/32.jpg)
Future Work
• Extend flows to other kinds of systems– Shared memory systems
– Concurrent software
• Investigate other uses of flows– Run time monitoring
– Refinement checking between high level model and RTL implementation
– Speeding up model checking