1. CS 290C: Formal Models for Web Software Lecture 3: Verification of Navigation Models with the Spin Model Checker Instructor: Tevfik Bultan

2. Verifying navigation models
Web application typically have some navigation constraints that they wish to enforce.
For example
Transition to a particular page must be via a specific other page. For example, a page displaying the contents of the shopping cart must be displayed before proceeding to the checkout
From any position in the application the users should be able to go back to the home page
We would like to check these types of constraints on the navigation model

3. Verifying navigation models
Verification of navigation models can be done in two ways
We can first construct the navigation model, verify it, and then while implementing the application we can enforce the navigation model (forward engineering)
If we can enforce the navigation model precisely, then verification results hold for the final application
We can try to extract the navigation model from an existing application by analyzing the application, and then verify the properties of the extracted model (reverse engineering)
If the automatically extracted model is precise, then the verification results hold for the application

4. What can we do after generating navigation models?
As I said last week, after we obtain a formal model of the navigation behavior we can verify it.
This brings up two questions:
How are we going to characterize properties of navigation models?
For this we will briefly discuss temporal logics
How are we going to verify these properties on the navigation model
For this we will discuss the Spin model checker

5. Transition Systems
Transition systems are a very basic model used in automated verification
The idea is to model a system with just states and transitions
It is basically a flat state machine
A transition system T = (S, I, R) consists of
a set of states S
a set of initial states I  S
and a transition relation R  S  S
Semantics of many formal languages (including statecharts) can be defined using transition systems

6. Execution Paths An execution path is an infinite sequence of states
x = s0, s1, s2, ...
such that
s0  I and for all i  0, (si,si+1)  R
Notation: For any path x
xi denotes the i’th state on the path (i.e., si)
xi denotes the i’th suffix of the path (i.e., si, si+1, si+2, ... )

7. Temporal Logics Temporal logics are a type of modal logics
Modal logics were developed to express modalities such as “necessity” or “possibility”
Temporal logics focus on the modality of temporal progression
Temporal logics can be used to express, for example, that:
an assertion is an invariant (i.e., it is true all the time)
an assertion eventually becomes true (i.e., it will become true sometime in the future)

8. Temporal Logics
We will assume that there is a set of basic (atomic) properties called AP
Atomic properties are the basic, non-temporal properties that can be checked by looking at the current state of the system
We will use the usual boolean connectives:  ,  , 
We will also use four temporal operators:
Invariant p : G p (aka p) (Globally)
Eventually p : F p (aka p) (Future)
Next p : X p (aka p) (neXt)
p Until q : p U q

9. Atomic Properties
In order to define the semantics we will need a function L which evaluates the truth of atomic properties on states:
L : S  AP  {True, False}
So given a state of the transition system and an atomic property, the function L determines if the property holds on that state or not.

10. Linear Time Temporal Logic (LTL) Semantics
Given an execution path x and LTL properties p and q
x |= p iff L(x0, p) = True, where p  AP
x |= p iff not x |= p
x |= p  q iff x |= p and x |= q
x |= p  q iff x |= p or x |= q
x |= X p iff x1 |= p
x |= G p iff for all i  0, xi |= p
x |= F p iff there exists an i  0 such that xi |= p
x |= p U q iff there exists an i  0 such that xi |= q and
for all 0  j < i, xj |= p

11. . . . . . . . . . . . . LTL Properties X p G p F p p U q p p p p p p p

12. LTL Equivalences We do not really need all four temporal operators
X and U are enough (i.e., X, U, AP and boolean connectives form a basis for LTL)
F p = true U p
G p =  (Fp) =  (true U p)

13. LTL Model Checking Given a transition system T and an LTL property p
T |= p iff for all execution paths x in T, x |= p
Model checking problem: Given a transition system T and an LTL property p, determine if T is a model for p (i.e., if T |=p)

14. LTL Properties T |= X p T |= F p T |=  G p T |= F  p
Transition System T = (S, I, R)
T |= X p
T |= F p
T |=  G p
T |= F  p p p s1 s2 s3 s4
S = {s1, s2, s3, s4}
I = {s3}
R ={(s1,s2), (s2,s3), (s3,s1),(s3,s4), (s4,s3)}
s1 |= p
s2 |=  p
s3 |=  p
s4 |= p

15. Example navigation properties in temporal logic
F(main-page): main-page is eventually reached
G(F(exit-page)): always eventually exit-page is reached
G(purchase-page => X(X(payment-page))): payment-page is reached two clicks after the purchase-page

16. Model Checkers
There are model checking tools that can check temporal logic properties on transition systems
Spin is a well-known LTL model checker
We will discuss it next
Spin can be used to check properties of finite state systems (such as statecharts specifications)

17. Verifying navigation models
One specific approach to verification of navigation models
Write navigation properties in LTL
Write the navigation model in the Promela language (the input language for the Spin model checker)
Use the Spin model checker to check the properties on the Promela specification
Spin model checker outputs error traces for the properties that are violated

18. SPIN Explicit state model checker Finite state
Temporal logic for specifying properties: LTL
Input language: PROMELA
Asynchronous processes
Shared variables
Message passing through (bounded) communication channels
Variables: boolean, char, integer (bounded), arrays (fixed size)
Structured data types
A good overview paper for the Spin model checker:
``The Model Checker SPIN,’’ Gerard J. Holzmann, IEEE Trans. Soft. Eng., 23(5) , 1997.

19. LTL Model Checking Summary
Each LTL property can be converted to a type of automaton
Generate the property automaton from the negated LTL property
Generate the product of the property automaton and the transition system
Show that there is no accepting (infinite) path in the product automaton (check language emptiness)
i.e., show that the intersection of the paths generated by the transition system and the paths accepted by the (negated) property automaton is empty
If there is an accepting path, it corresponds to a counterexample behavior that demonstrates the bug

20. LTL properties can be converted to automata
true
G p p p
true
F p p p p p p
G (F p) p
These are specific type of automata that accepts infinite strings (they are called Buchi autoamata)

21. LTL Model Checking Summary
We can think of the input transition system as also an automaton if we make all the states of the transition system accepting states
Then, if we generate a property automaton from the negated LTL property and take the product of the property automaton and the transition system
If the transition system satisfies the property, this product automaton should not accept any strings
So, we can check if the language accepted by the property automaton is empty or not
If it is empty, then the transition system satisfies the property
If it is not empty, any accepting sequence corresponds to a behavior that violates the original property

22. SPIN Verification in SPIN Uses the LTL model checking approach
Constructs the product automaton on-the-fly
It is possible to find an accepting path (i.e. a counter-example) without constructing the whole state space
Uses a nested depth-first search algorithm to look for an accepting path (which is must end in a cycle since we are looking for infinite paths)
Uses various heuristics to improve the efficiency of the nested depth first search:
partial order reduction
state compression

23. Promela (PROcess MOdeling LAnguage)
Basic data types and ranges
bit (or bool) 0..1
byte
short
int
bool flag; /* declares a boolean array */
int state; /* declares an integer variable called state */
Array variables
byte myarray[N] /* decleras an array of size N */

24. Processes You can define processes using proctype proctype A() {
byte state; /* local variable */
state = 3 }
; used as a separator not terminator, so no ; after the last statement

25. Processes you can also use -> instead of ; byte state = 2;
proctype A() {
(state==1) -> state=3 }
proctype B()
state = state – 1

26. Process Instantiation
You use an init block to identify initial states of the system
init { skip }
You can use the init block to instantiate processes
init { run A(); run B() }
run is used to start executing a process and can also pass arguments (basic data types) to a process

27. Atomic sequences
A sequence of statements can be executed atomically using the atomic construct
atomic { (state==1) -> state=state+1 }

28. Message passing
Channels can be used to model transfer of data from one process to another
Channels are basically FIFO message queues
Channels can store tuples of values at each location in the message queue
chan qname = [16] of { int }
A channel that stores integer values
chan qname = [16] of {int, int, bool}
A channel that stores tuples that consist of two integers and one boolean value

29. Message passing Send operations:
qname!expr sends the value of the expression expr to the channel named qname
Receive operations:
qname?msg retrieves the message from the head of the channel qname and stores it in the variable msg

30. Rendez-Vous Communication
If the channel size is set to 0 then, the communication corresponds to synchronous communication
Sender and receiver must execute matching send and receive actions at the same time
If the sender (the receiver) reaches the send (the receive) operation before the receiver (the sender) reaches the receive (the send) operation, it has to wait
chan port = [0] of {byte}

31. Control flow: case selection
if ::(a!=b) -> option1 ::(a==b) -> option2 fi If more than one guard is executable, then one option is chosen nondeterministically

32. Control flow: repetition (loops)
do :: count = count+1 :: count= count-1 :: (count==0) -> break od Only one option is selected for execution at a time. After that option is executed, the process is repeated.

33. Enumerated variables You can define enumerated variables using mtype
mtype = {ack, nak, err, next, accept}
chan q = [4] of {mtype, mtype, bit, short}

34. Example Mutual Exclusion Protocol
Two concurrently executing processes are trying to enter a critical section without violating mutual exclusion
Process 1:
while (true) {
out: a := true; turn := true;
wait: await (b = false or turn = false);
cs: a := false; } ||
Process 2:
out: b := true; turn := false;
wait: await (a = false or turn);
cs: b := false;

35. Example Mutual Exclusion Protocol in Promela
#define cs1
#define cs2
#define wait1
#define wait2
#define true
#define false
bool a;
bool b;
bool turn;
proctype process1() {
out: a = true; turn = true;
wait: (b == false || turn == false);
cs: a = false; goto out; }
proctype process2()
out: b = true; turn = false;
wait: (a == false || turn == true);
cs: b = false; goto out;
init {
run process1(); run process2()

36. Property automaton generation
Input formula
“[]” means G
“<>” means F
“spin –f” option
generates a Buchi automaton for the input LTL formula
% spin -f "! [] (! (cs1 && cs2))“
never { /* ! [] (! (cs1 && cs2)) */
T0_init: if
:: ((cs1) && (cs2)) -> goto accept_all
:: (1) -> goto T0_init
fi;
accept_all:
skip }
% spin -f "!([](wait1 -> <>(cs1)))“
never { /* !([](wait1 -> <>(cs1))) */
:: (! ((cs1)) && (wait1)) -> goto accept_S4
accept_S4:
:: (! ((cs1))) -> goto accept_S4
Concatanate the generated never claims to the end of the specification file

37. SPIN
“spin –a mutex.pml” generates a C program “pan.c” from the specification file
You need to use the “-a” flag to verify temporal logic formulas
The generated pan.c is a C program that implements the on-the-fly nested-depth first search algorithm
You compile “pan.c” and run it to do the model checking (you need to use the “-a” flag when you run the executable)
Spin generates a counter-example trace if it finds out that a property is violated
You can view the counter-example trace using
“spin –t –p mutex.pml”

38. %mutex -a
warning: for p.o. reduction to be valid the never claim must be stutter-invariant
(never claims generated from LTL formulae are stutter-invariant)
(Spin Version October 2005)
+ Partial Order Reduction
Full statespace search for:
never claim
assertion violations + (if within scope of claim)
acceptance cycles (fairness disabled)
invalid end states (disabled by never claim)
State-vector 28 byte, depth reached 33, errors: 0
22 states, stored
15 states, matched
37 transitions (= stored+matched)
0 atomic steps
hash conflicts: 0 (resolved)
memory usage (Mbyte)
unreached in proctype process1
line 18, state 6, "-end-"
(1 of 6 states)
unreached in proctype process2
line 27, state 6, "-end-"
unreached in proctype :init:
(0 of 3 states)

39. Modeling state machines with spin
To model a basic (flat) state machine with Spin we can do the following
Declare the states of the state machine as an mtype
Declare a variable called state that will store the current state of the state machine
Use the init block to initialize the state variable to an initial state of the state machine
Model the transitions of the state machine as a switch cases in a loop do
::(state==s1) -> state=s2
:: ... /* one choice for each transition */
... od

40. An example A simple state machine and the corresponding Promela model
#define state1 state==s1
#define state2 state==s2
#define state3 state==s3
#define state4 state==s4
#define p (state==s1 || state==s4)
mtype = {s1, s2, s3, s4};
mtype state;
proctype fsm() { do
:: state==s1 -> state=s2;
:: state==s2 -> state=s3;
:: state==s3 -> state=s1;
:: state==s3 -> state=s4;
:: state==s4 -> state=s3 od }
init {
state = s3;
run fsm()
A simple state machine
and the corresponding
Promela model
(saved it in a file
fsm.pml) p p s1 s2 s3 s4

41. An example
We can check properties such as the following LTL formulas (<> is F and [] is G):
<> p (this property holds on our example)
[] p (this property does not hold on our example)
[] !p (this property does not hold our example either)
[]<> p (this property holds on our examle)

42. An example
To check propety <>p we create a never claim for its negation:
% spin -f “! <> p”
never { /* ! <> p */
accept_init:
T0_init: if
:: (! ((p))) -> goto T0_init
fi; }

43. An example
Concatenate the never claim to fsm.pml and then do the following:
% spin -a fsm.pml
% gcc pan.c -o fsm
% ./fsm –a
We get the output in the next page

44. Verification output Means that the property holds $ ./fsm –a
warning: for p.o. reduction to be valid the never claim must be stutter-invariant
(never claims generated from LTL formulae are stutter-invariant)
(Spin Version October 2005)
+ Partial Order Reduction
Full statespace search for:
never claim
assertion violations + (if within scope of claim)
acceptance cycles + (fairness disabled)
invalid end states (disabled by never claim)
State-vector 24 byte, depth reached 8, errors: 0
7 states, stored (14 visited)
4 states, matched
18 transitions (= visited+matched)
0 atomic steps
hash conflicts: 0 (resolved)
memory usage (Mbyte)
unreached in proctype fsm
line 12, state 2, "state = s2"
line 13, state 4, "state = s3"
line 16, state 10, "state = s3"
line 18, state 14, "-end-"
(4 of 14 states)
unreached in proctype :init:
(0 of 3 states)
Means that the
property holds

45. An example
Now let’s check the following property [] !p we create a never claim for its negation:
% spin -f “! [] ! p”
never { /* ! [] ! p */
T0_init: if
:: ((p)) -> goto accept_all
:: (1) -> goto T0_init
fi;
accept_all:
skip }

46. An example Means that the property is violated % ./fsm –a
warning: for p.o. reduction to be valid the never claim must be stutter-invariant
(never claims generated from LTL formulae are stutter-invariant)
pan: claim violated! (at depth 11)
pan: wrote test.trail
(Spin Version October 2005)
Warning: Search not completed
+ Partial Order Reduction
Full statespace search for:
never claim
assertion violations + (if within scope of claim)
acceptance cycles + (fairness disabled)
invalid end states - (disabled by never claim)
State-vector 24 byte, depth reached 11, errors: 1
6 states, stored
0 states, matched
6 transitions (= stored+matched)
0 atomic steps
hash conflicts: 0 (resolved)
memory usage (Mbyte)
Means that the
property is violated

47. An example
Then we can generate the counter-example trace using “spin –t –p fsm.pml”
This is referring to the
state of the whole
specification
This is the variable
we declared
% spin -t -p fsm.pml
Starting :init: with pid 0
Starting :never: with pid 1
Never claim moves to line [(1)]
2: proc 0 (:init:) line 19 "fsm.pml" (state 1) [state = s3]
Starting fsm with pid 2
4: proc 0 (:init:) line 20 "fsm.pml" (state 2) [(run fsm())]
6: proc 1 (fsm) line 13 "fsm.pml" (state 5) [((state==s3))]
8: proc 1 (fsm) line 13 "fsm.pml" (state 6) [state = s1]
Never claim moves to line [(((state==s1)||(state==s4)))]
10: proc 1 (fsm) line 11 "fsm.pml" (state 1) [((state==s1))]
Never claim moves to line [(1)]
spin: trail ends after 11 steps
#processes: 2
state = s1
11: proc 1 (fsm) line 11 "fsm.pml" (state 2)
11: proc 0 (:init:) line 21 "fsm.pml" (state 3) <valid end state>
11: proc - (:never:) line 36 "fsm.pml" (state 8) <valid end state>
2 processes created