Finite-State Verification - PowerPoint PPT Presentation

sybill-jordan
finite state verification n.
Skip this Video
Loading SlideShow in 5 Seconds..
Finite-State Verification PowerPoint Presentation
Download Presentation
Finite-State Verification

play fullscreen
1 / 45
Download Presentation
Finite-State Verification
105 Views
Download Presentation

Finite-State Verification

- - - - - - - - - - - - - - - - - - - - - - - - - - - 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