1 / 45

Finite-State Verification

Finite-State Verification. A quick look at three approaches to FSV. Model Checking Flow Equations Data Flow Analysis FLAVERS. High-Level Architecture of FSV Systems. Property. Property Translator. Property Representation. System. System Model. System Translator. Property Verified.

sybill-jordan
Télécharger la présentation

Finite-State Verification

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Finite-State Verification

  2. A quick look at three approaches to FSV • Model Checking • Flow Equations • Data Flow Analysis • FLAVERS

  3. High-Level Architecture of FSV Systems Property Property Translator Property Representation System System Model System Translator Property Verified ReasoningEngine Counter Examples for Model

  4. Data Flow Based Verification: some history • Mid-70’s: Originally proposed for def-ref anomalies in FORTRAN (Osterweil and Fosdick) • Early 80’s: Extended to general properties (Olender and Osterweil) & concurrency (Taylor and Osterweil) • 90’s: Deadlock detection (Masticola and Ryder); Efficient representation of concurrency & incremental precision improvement (Dwyer and Clarke) • Recent: Optimizations, Java (Avrunin, Clarke, Cobleigh, Naumovich, and Osterweil)

  5. Data Flow Analysis: FLAVERS • FLow Analysis for VERification of Systems • Represents property as a finite state automaton • System model is collection of annotated control flow graphs • intertask communication and interleavings are represented with additional nodes & edges • does not enumerate all reachable states • over-approximates relevant executable behaviors • Reasoning engine based on data flow analysis

  6. High-Level Architecture of FLAVERS Property Specification Property Translator Property FSA Trace Flow Graph(TFG) System System Translator Property Verified StatePropagation Counter Example Trace through TFG

  7. Representing Properties • Properties are represented as Finite State Automata (FSAs) • Properties are either all or none • An all property is a behavior that must always happen • A none property is a behavior that must never happen

  8. The elevator does not move while its doors are open P is the alphabet of the property L(P) is the set of all strings accepted by Property P 1 closemove open close 2 open move closemoveopen 3 Elevator Property

  9. Control Flow Graph (CFG) • A CFG G is <N, E , ninitial, nfinal > • Associate events with nodes • G is the alphabet of G • L(G) is the language of G • The set of all strings in (G) that occur on paths from the initial node to the final node • CFG is alphabet refined • Remove nodes that do not affect the property being verified

  10. Simple Sequential Example 1: if … 1: if (stopped) then 2: open; end if; … 3: if (stopped) then 4: close; end if; … 5: move; … 2: open 3: if 4: close 5: move

  11. Proving Properties • Given a CFG G and a property P • Alphabet refine G with respect to P • Want to show L(G)  L(P) • Use data-flow analysis to propagate states of P to the nodes of G • Worst-case cost is O((NG)2  SP)

  12. FLAVERS (similar to Cesar) • Forward Flow, Any Path Problem • IN and OUT are sets of FSA states • IN(n) =  OUT(m) • OUT(n) = d(s, n) • d is the FSA transition function • Result: Let f be the final node of the TFG • All property: Want OUT(f)  Accept(P) • None property: Want OUT(f)  Accept(P) =  • Accept(P) is the set of accepting states of a property, P m in pred(n) s in IN(n)

  13. 1: if 1 closemove open close 2 open 3: if move closemove open 3 State Propagation Worklist: 2, 3 , 4, 5 {1} {1} {1} 2: open {2} {1,2} {1,2} {1,2} 4: close {1} {1,2} 5: move {1,3}

  14. 1: if 2: open 3: if 4: close 5: move State Propagation Worklist: 2, 3 , 4, 5 {1} {1} 1 closemove {1} open {2} close {1,2} 2 open {1,2} {1,2} move {1} closemove open 3 {1,2} {1,3}

  15. 1: if 1 closemove 2: open open close 2 3: if open move 4: close closemove open 3 5: move State Propagation {1} {2} {1,2} {1} {1,3}

  16. 1: if 2: open 3: if 4: close 5: move State Propagation … 1: if (stopped) then 2: open; end if; … 3: if (stopped) then 4: close; end if; … 5: move; …

  17. Constraints ... Incrementally Improving Precision Property Specification Property Translator Property FSA Trace Flow Graph System System Translator Property Verified StatePropagation Counter Example Trace through TFG

  18. Boolean Variable Constraint u S==tS=t S==fS=f S=f S==t S=t S==fS=f t f S=t S==f S==t v S==t S=tS==f S=f == is a predicate= is assignment

  19. Boolean Variable Constraint u S==tS=t S==fS=f S=f S==t S=t S==fS=f t f S=t S==f S==t v S==t S=tS==f S=f == is a predicate= is assignment

  20. Constraints • Constraints are represented as FSAs • Constraints describe conditions necessary for feasible execution • Constraints have a special violation state that is entered when an infeasible path is detected • Violation is a trap state; once it is entered, never leave that state

  21. Improving Precision • Use constraints to improve precision • Given a CFG G, a property P, and constraints C1,…,Cn • Alphabet refine G wrt (P C1 … Cn) • Want (L(G) L(C1) …L(Cn))  L(P) • Worst-case cost is O(NG2  SP  SC1 … SCn)

  22. How do constraints affect the data flow equations • IN and OUT are now sets of tuples of FSA states • Merge is still union • Transfer function now has to look at each FSA state in the in-tuple when computing the out-tuple • Result looks at paths that are feasible with respect to the constraints • The property state is the same as before • Every constraint must be in an accepting state

  23. 1: if 2: S==t 4: S==f 3: open 5: if 6: S==t 8: S==f 7: close 9: move Elevator Revisited … 1,2,4: if (stopped) then 3: open; end if; … 5,6,8: if (stopped) then 7: close; end if; … 9: move; …

  24. closemove 1 open close 1: if 2 open move closemove open 3 u 5: if S==t S==f S==t S==f t f S==f S==t v S==f S==t State Propagation Worklist: 2, 4 , 3 , 5 , 6, 8 <1,u> <1,u> <1,u> <1,u> 2: S==t 4: S==f <1,t> <1,f> 3: open <1,t> <2,t> <2,t>,<1,f> <2,t>,<1,f> <2,t>,<1,f> 6: S==t 8: S==f <2,t>,<1,v> 7: close 9: move

  25. closemove 1 open close 2 open move closemove open 3 u S==t S==f S==t S==f t f S==f S==t v S==f S==t State Propagation Worklist: 2, 4 , 3 , 5 , 6, 8 <1,u> 1: if <1,u> <1,u> <1,u> 2: S==t 4: S==f <1,t> <1,f> <1,t> 3: open <2,t> <2,t>,<1,f> 5: if <2,t>,<1,f> <2,t>,<1,f> 6: S==t 8: S==f <2,t>,<1,v> 7: close 9: move

  26. closemove 1 open close , 7, 9 2 open move closemove open 3 u S==t S==f S==t S==f t f <2,v>,<1,f> <2,t> S==f S==t <1,t> v <1,t>,<1,f> S==f S==t <1,t>,<1,f> State Propagation Worklist: 2, 4 , 3 , 5 , 6, 8 <1,u> 1: if <1,u> <1,u> <1,u> 2: S==t 4: S==f <1,t> <1,f> <1,t> 3: open <2,t> <2,t>,<1,f> 5: if <2,t>,<1,f> <2,t>,<1,f> <2,t>,<1,f> 6: S==t 8: S==f <2,t>,<1,v> 7: close 9: move

  27. Versatility of Constraints • Can be used to model: • Values of variables • Control flow within a specific thread of control • Behavior of hardware components • Possible behaviors of the environment • Intended behaviors of unimplemented modules

  28. Support for Concurrency: • Different concurrency constructs • Rendezvous-based in Ada • Shared variable-based, monitor style in Java • FLAVERS/Ada and FLAVERS/Java • Hence, different program models • Still use the same state propagation algorithm

  29. T1 T2 1 6 2 7 3 8 call a accept a 4 9 5 10 Building a model for rendezvous 1 6 2 7 3 8 Ra 5 10

  30. Reachability based model 1,6 T1 T2 6 1 2,6 1,7 7 2 3,6 2,7 1,8 8 3 b_3,6 3,7 2,8 1,b_8 Ra 5 10 b_3,7 3,8 2,b_8 b_3,8 b_3,b_8 3,b_8 Can build the reachability graph Ra • State explosion 5,10

  31. 2 7 5 Trace Flow Graph Model • FLAVERS model is a Trace Flow Graph (TFG) • Automatically created from the source code • Instead of the state space, explicitly represents interleaved execution May Immediately Precede (MIP) edges • Smaller model • Less precise T1 T2 6 1 8 3 Ra 10

  32. 2 7 5 Trace Flow Graph • This model has many infeasible paths because of the MIP edges • Can use constraints to keep track of the flow through a task T1 T2 6 1 8 3 Ra 10

  33. 2 7 2,3,Ra,5 1,3,Ra,5 1,2,Ra,5 5 v 1,2,3,5 1,2,3,Ra 1,2,3,Ra,5 Using Constraints Task constraint for T1 T1 T2 6 1 1 2 8 3 Ra 3 10 Ra 5

  34. Experimental Goals • Evaluate how FLAVERS performance scales as program size increases • Time • Memory • Number of constraints

  35. Chiron • User interface system • Developed at UC Irvine • Uses event-based notification • Similar to Listeners in Java • Proved several properties about Chiron • Avrunin, Corbett, Dwyer, Pasareanu, Siegel

  36. Example Properties • p07 - If listener1 registers for event1 before listener2, then listener1 will be notified of event1 before listener2 • p09 - The program never terminates while a listener is listening for an event

  37. Chiron • The Chiron system was scaled by increasing the number of events that can be listened for • Lines of code • 2 events 259 • 53 events 3,557 • Constraints Needed • For every property, the constraints needed to verify a property in the 2 event system are sufficient to verify the property for any system with more events • Never needed more than 4 constraints

  38. Comparison to Other Approaches • SMV [McMillan, 1993] • Symbolic model checking • SPIN [Holzmann, 1991] • Optimized reachability analysis • INCA [Corbett and Avrunin, 1995] • Integer linear programming

  39. Related Work • Data-flow analysis • DAVE [Osterweil and Fosdick, 1976] • CESAR/CECIL [Olender and Osterweil, 1990 & 1992] • FLAVERS [Dwyer and Clarke, 1994] • Other FSV Tools • SMV, NuSMV • SPIN • Java PathFinder • SLAM • INCA • Blast • …

  40. Some Observations: Data Flow Analysis • Overall complexity is O(N2S) • N is the # nodes in the model • S is the number of states: property x constraints • In our experience, many important properties can be proven with a small number of constraints • Experimentally: performance sub-cubic • Usually requires several iterations to determine needed constraints • Constraints • Many automatically generated on request

  41. Future Work • Support for Java • Specifying properties (Propel) • Heuristics for constraint selection • Heuristics for counterexample selection • Heterogeneous communication models • Compositional techniques

More Related