Finite-State Verification

105 Views

Download Presentation
## Finite-State Verification

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -

**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 ReasoningEngine Counter Examples for Model**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)**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**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**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**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**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**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**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)**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)**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}**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}**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}**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; …**Constraints**... Incrementally Improving Precision Property Specification Property Translator Property FSA Trace Flow Graph System System Translator Property Verified StatePropagation Counter Example Trace through TFG**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**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**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**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)**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**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; …**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**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**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**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**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**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**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**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**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**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**Experimental Goals**• Evaluate how FLAVERS performance scales as program size increases • Time • Memory • Number of constraints**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**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**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**Comparison to Other Approaches**• SMV [McMillan, 1993] • Symbolic model checking • SPIN [Holzmann, 1991] • Optimized reachability analysis • INCA [Corbett and Avrunin, 1995] • Integer linear programming**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 • …**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**Future Work**• Support for Java • Specifying properties (Propel) • Heuristics for constraint selection • Heuristics for counterexample selection • Heterogeneous communication models • Compositional techniques