: A Finite State Verification Approach for Software Systems

1
A Finite State Verification Approach
for Software Systems
FLAVERS

• Lori A. Clarke, George S. Avrunin, Jamieson M.
  Cobleigh, Heather M. Conboy,Matthew B.
  Dwyer,Gleb Naumovich, and Leon J. Osterweil
• Laboratory for Advanced Software Engineering
  ResearchUniversity of Massachusetts,
  Amhersthttp//laser.cs.umass.edu/

2
Finite State Verification (FSV)

• Verifies properties about system behavior
• Seeks a middle ground between testing and theorem
  proving
• Testing cannot provide definitive results
• Theorem proving requires mathematical
  sophistication and considerable human insight
• Works on a finite model of the system
• Has been successfully used to prove a variety of
  properties of systems

3
State Explosion Problem

• FSV techniques can quickly become intractable due
  to the state explosion problem
• The cost can be exponential in the size of the
  system being analyzed
• Analysts typically have to figure out how to
  create a small, abstract model of the system

4
Our Approach

• Automatically create an abstract model
• Imprecise, but conservative
• Helps control state explosion
• If needed, add precision incrementally until
  model is precise enough to
• prove the property of interest or
• reveal a fault (in the system or property)

5
Outline

• Introduction
• FLAVERS Model
• Checking Properties
• Improving Precision
• Experimental Results
• Conclusion

6
FLAVERS

• FLow Analysis for VERification of Systems
• Verifies properties about concurrent and
  sequential systems
• Automatically creates an abstract, event-based
  graph model of the system
• Imprecise, but conservative
• Represents properties as Finite-State Automata
• Sequences of syntactically recognizable events
• Uses an efficient data-flow analysis algorithm
• Precision can be improved incrementally
• Can be used for both safety and liveness
  properties

7
Modeling Concurrent Systems

• Common model for a concurrent system is a
  reachability graph
• Represents all the states a concurrent system may
  reach
• ltl1,l2, lngt, where each element of the tuple is
  a location in one of the tasks
• Often includes the full state of execution
• location and values of all variables for each
  task
• Interleaved model of execution

8
Reachability Graph

• task body t1 is begin
• u
• t2.synch
• v
• w
• end t1
• task t2 body is begin
• x
• accept synch
• y
• z
• end t2

9
Reachability Graph

• task body t1 is begin
• u
• t2.synch
• v
• w
• end t1
• task t2 body is begin
• x
• accept synch
• y
• z
• end t2

10
Trace Flow Graph (TFG)

• A TFG represents how events flow through a system
• Built from Control Flow Graphs for the tasks in
  the system
• For a concurrent systems, nodes and edges may be
  added to represent concurrency

11
TFG Construction

• task body t1 is begin
• u
• t2.synch
• v
• w
• end t1
• task t2 body is begin
• x
• accept synch
• y
• z
• end t2

x
u
synch
y
v
w
z
12
Feasible Paths
b,b
u,b
b,x
x
u
u,x
synch
s,s
s,y
v,s
y
v
w,s
v,y
s,z
w
z
w,y
v,z
w,z
e,e
13
Infeasible Paths
b,b
u,b
b,x
x
u
u,x
synch
s,s
s,y
v,s
y
v
w,s
v,y
s,z
w
z
w,y
v,z
w,z
e,e
14
Outline

• Introduction
• FLAVERS Model
• Checking Properties
• Improving Precision
• Experimental Results
• Conclusions

15
Elevator Property

• The elevator does not move
• while its doors are open.
• L(P) is the set of all strings
• accepted by property P

16
Annotated TFG

• A TFG G is ltN, ninitial, nfinal, Egt
• Associate events with nodes
• ?G is the alphabet of G
• Events must be indivisible wrt other events in
  the property
• 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

17
Alphabet Refinement

• ?p is the alphabet of the property P
• E.g., ?p open, close, move
• For alphabet refinement, remove all nodes in the
  TFG that do not have events in ?p OR do not
  control the flow of execution for nodes with such
  events

18
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
19
Proving Properties

• Given a CFG G and a property P
• Alphabet refine G with respect to ?P
• Need to show L(G) ? L(P)
• Use data-flow analysis to propagate states of P
  to the nodes of G
• In(n) Upred(n)Out(n)
• Out(n) Ut?In(n)?(t) where ? is the
  transition function
• Worst-case cost is O((NG)2 ? SP)

20
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
21
State Propagation
Worklist 2, 3
, 4, 5
1
1
1
closemove
1
2 open
open
close
2
1,2
2
open
1,2
1,2
move
4 close
1
closemove open
3
1,2
5 move
1,3
22
State Propagation
1
2
1,2
1
1,3
23
State Propagation
1 if (stopped) then 2 open end
if 3 if (stopped) then 4 close end
if 5 move
24
Boolean Variable Constraint
u
StSt
SfSf
Sf
St St
SfSf
f
t
St
St
Sf
v
St StSf Sf
is a predicate is assignment
25
Boolean Variable Constraint
u
StSt
SfSf
Sf
St St
SfSf
f
t
St
St
Sf
v
St StSf Sf
is a predicate is assignment
26
Improving Precision

• Use constraints to improve precision
• Represented as FSAs
• Given a CFG G, a property P, and constraints
  C1,,Cn
• Alphabet refine G with respect to (?P
  ? ?C1 ? ? ?Cn)
• Want (L(G) ? L(C1) ?? L(Cn)) ? L(P)
• Worst-case cost is O(NG2 ? SP ? SC1 ?? SCn)

27
Elevator Revisited
1,2,4 if (stopped) then 3 open end
if 5,6,8 if (stopped) then 7
close end if 9 move
28
State Propagation
, 6, 8
, 5
, 3
Worklist 2, 4
2 St
4 Sf
3 open
6 St
8 Sf
7 close
9 move
29
State Propagation
, 6, 8
, 5
, 3
Worklist 2, 4
lt1,ugt
1 if
lt1,ugt
lt1,ugt
lt1,ugt
2 St
4 Sf
lt1,tgt
lt1,fgt
lt1,tgt
3 open
lt2,tgt
lt2,tgt,lt1,fgt
5 if
lt2,tgt,lt1,fgt
lt2,tgt,lt1,fgt
6 St
8 Sf
lt2,tgt,lt1,vgt
7 close
9 move
30
State Propagation
, 6, 8
, 5
, 3
Worklist 2, 4
lt1,ugt
1 if
lt1,ugt
lt1,ugt
lt1,ugt
2 St
4 Sf
lt1,tgt
lt1,fgt
3 open
lt1,tgt
lt2,tgt
lt2,tgt,lt1,fgt
5 if
lt2,tgt,lt1,fgt
lt2,tgt,lt1,fgt
6 St
8 Sf
lt2,tgt,lt1,fgt
lt2,tgt,lt1,vgt
7 close
9 move
31
State Propagation
, 6, 8
, 5
, 3
Worklist 2, 4
lt1,ugt
1 if
lt1,ugt
lt1,ugt
lt1,ugt
2 St
4 Sf
lt1,tgt
lt1,fgt
3 open
lt1,tgt
lt2,tgt
lt2,tgt,lt1,fgt
5 if
lt2,tgt,lt1,fgt
lt2,tgt,lt1,fgt
6 St
8 Sf
lt2,tgt,lt1,fgt
lt2,tgt,lt1,vgt
7 close
9 move
32
Outline

• Introduction
• FLAVERS Model
• Checking Properties
• Improving Precision
• Experimental Results
• Conclusion

33
Experimental Goals

• Evaluate how FLAVERS performance scales as
  program size increases
• Time
• Memory
• Number of constraints

34
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

35
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

36
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

37
(No Transcript)
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
(No Transcript)
40
(No Transcript)
41
(No Transcript)
42
Experimental Results

• FLAVERS usually demonstrated subcubic performance
  in the size of the system
• The few examples that were not subcubic could be
  solved by restating the properties
• Only took a few iterations to determine the
  constraints that should be selected
• Once a set of constraints was found for a small
  system configuration, the same set of constraints
  was sufficient for larger configurations
• Often did not have the best performance
  compared to other approaches, but consistently
  performed well

43
(No Transcript)
44
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

45
Recent and Future Work

• Support for Java
• Specifying properties (Propel) (ICSE2002)
• Heuristics for constraint selection (FSE2003)
• Heuristics for counterexample selection (FSE2004)
• Compositional techniques
• Design-time verification applied to architectural
  description languages
• Verification of process descriptions
• Scientific processes
• Medical processes
• To improve safety and efficiency
• ecommerce and egovernment processes
• To assure security and privacy

46
Conclusions

• Finite state verification approaches are
  improving
• Being used in industry for hardware systems
• With the increasing interest in software security
  and quality, may become widely used for software
  systems
• FLAVERS provides a demonstration of its potential
  effectiveness