1. Finite-State Verification

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

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

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. Property Specification System Property Translator System Translator State Propagation Trace Flow Graph (TFG) Property Verified Property FSA Counter Example Trace through TFG High-Level Architecture of FLAVERS

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. Elevator Property 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 2 3 close open move close move open open close move

9. Control Flow Graph (CFG) A CFG G is Associate events with nodes o  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 (stopped) then 2:open; end if; … 3:if (stopped) then 4:close; end if; … 5:move; … 1: if 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((N G ) 2  S P )

12. FLAVERS (similar to Cesar) Forward Flow, Any Path Problem IN and OUT are sets of FSA states IN(n) =  OUT(m) OUT(n) =   (s, n)  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. State Propagation 2: open 4: close 5: move Worklist: 2, 3 {1} {2} {1} {1,2} {1,3}, 4, 5 1 2 3 close open move close move open open 3: if 1: if {1} {1} {1,2} {1,2} {1,2}

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

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

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

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

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

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

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 C 1,…,C n Alphabet refine G wrt (  P   C1  …   Cn ) Want ( L (G)  L (C 1 )  …  L (C n ))  L (P) Worst-case cost is O(N G 2  S P  S C1  …  S Cn )

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. Elevator Revisited 1: if 2: S==t 5: if 9: move 4: S==f 3: open 6: S==t 8: S==f 7: close … 1,2,4:if (stopped) then 3: open; end if; … 5,6,8:if (stopped) then 7: close; end if; … 9:move; …

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

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

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

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. Building a model for rendezvous T1 1 2 3 4 5 call a T2 6 7 8 9 10 accept a 1 2 3 5 6 7 8 10 Ra

30. Reachability based model 3 Ra T1T2 1,6 2,6 5,10 3,6 Ra 8 1,7 1 6 2,71,8 3,72,8 b_3,b_8 State explosion 2 7 510 Can build the reachability graph b_3,72,b_8 b_3,61,b_8 b_3,8 3,8 3,b_8

31. Trace Flow Graph Model 3 Ra 2 10 T1T2 5 7 8 1 6 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

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

33. Using Constraints 3 Ra 2 10 T1T2 5 7 8 1 6 Task constraint for T1 1 2 3 Ra 5 v 2,3,Ra,5 1,3,Ra,5 1,2,Ra,5 1,2,3,5 1,2,3,Ra 1,2,3,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 events3,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. 38

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

40. 40

41. 41

42. 42

43. 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 …

44. Some Observations: Data Flow Analysis Overall complexity is O(N 2 S) 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

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