1. CSE 555 Protocol Engineering Dr. Mohammed H. Sqalli Computer Engineering Department King Fahd University of Petroleum & Minerals Credits: Dr. Abdul Waheed (KFUPM) Spring 2004 (Term 032)

2. Correctness Requirements

3. CSE555-SqalliTerm 0324-1-3 Topics (Ch. 6)  Correctness criteria  Reasoning about behavior  Assertions and system invariants  Deadlocks and bad cycles  Temporal claims

4. CSE555-SqalliTerm 0324-1-4 Correctness Criteria  What does it mean for a design to be correct (i.e., to validate a design)?  A design can be proven correct wrt to specific correctness criteria  Logical correctness is concerned primarily with possibilities, not with probabilities  Some fairly general correctness criteria:  Absence of deadlocks  Absence of livelocks  No improper terminations  Problem: high complexity even with finite state models  A design should be provably correct  Proving even simple protocol properties, such as absence of deadlocks, is PSPACE hard

5. CSE555-SqalliTerm 0324-1-5 Dealing With Complexity  Validation methods need to solve complexity problems:  Methods should allow correctness analysis of large models  Methods should provide techniques for reducing complexity of models (Ch. 8 and 11)  Ability to express large models despite complexity depends on a careful choice of correctness criteria  PROMELA’s choice of correctness criteria: support several independent levels of complexity  Simple and straight-forward requirements are checked independently of the others  Example: Absence of deadlocks  Slightly more complicated requirements have higher computation cost  Example: Absence of livelocks  More sophisticated requirements are the most expensive to check  Techniques of reducing complexity are applicable here (Ch. 11)

6. CSE555-SqalliTerm 0324-1-6 Basic Types of Claims  Two types of correctness requirements:  Safety: set of properties the system may not violate, i.e., bad things that should be avoided (e.g., invalid end states)  Liveness: set of properties the system must satisfy, i.e., good things that capture the required functionality of a system (e.g., non-progress cycles)  Function of a verification system  Need not, and cannot, determine what is good or bad  It can only help the designer to determine what is possible and what is not  For a verifier, there are two types of correctness claims  Claims about reachable and unreachable states  state properties (e.g., system invariant, process assertion)  Claims about feasible and infeasible executions (i.e., sequence of states)  path properties (finite or infinite (e.g., cyclic))

7. CSE555-SqalliTerm 0324-1-7 Reasoning About Behavior  Correctness criteria can be formalized as claims about the behavior of a PROMELA validation model  Two general types of claims about a given behavior:  Inevitable; or  Impossible  Suffice to support only one type of claim  Claim of one type implicitly defines a complementary and equivalent claim of the other type  PROMELA’s expression of correctness criteria:  Define behaviors that are claimed to be impossible

8. CSE555-SqalliTerm 0324-1-8 Reasoning About Behavior (Cont’d)  How to state that a given behavior is inevitable:  All deviant behaviors are impossible  How to express an assertion stating that a condition is invariantly true:  Correctness claim: assertion is impossible to be violated

9. CSE555-SqalliTerm 0324-1-9 Definition of Terms  A state of a validation model is completely defined by:  Specification of all values for local and global variables  All control flow points of running processes  Contents of all message channels  An execution sequence:  A finite, ordered set of states  The behavior of a validation model:  Defined completely by the set of all possible execution sequences  Model can reach a given state by executing PROMELA statements  Model can be placed in a given state by:  Assignment of the appropriate values to variables, control flow points, and channels

10. CSE555-SqalliTerm 0324-1-10 Valid Execution Sequence  Any arbitrary set of states do not necessarily form a valid execution sequence  A finite, ordered set of states is valid for a given PROMELA model M if it satisfies two criteria:  The first state (state 1) of the sequence is the initial system state of M:  All variables initialized to zero  All message channels empty  Only init process active and set in its initial state  If M is placed in state i, there is at least one executable statement that can bring it to the state i+1

11. CSE555-SqalliTerm 0324-1-11 Terminating and Cyclic Sequences  Terminating:  No state occurs more than once in the sequence  Model M contains no executable statements when placed in the last state of the sequence  Cyclic:  All states except for the last one are distinct  Last state of the sequence is equal to one of the earlier states  Cyclic sequences define potentially infinite executions  System behavior of a PROMELA model:  Defined by all terminating and cyclic sequences generated by executing this model  Set of reachable states of a PROMELA model:  The union of all states included in the system behavior

12. CSE555-SqalliTerm 0324-1-12 State Properties  Propositions  Correctness claims for PROMELA models can be built up from simple propositions  A proposition is a boolean condition on the state of the system  A proposition can refer to all the elements of a system state:  Local and global variables  Control-flow points of arbitrary executing processes  Contents of message channels  Propositions implicitly define labeling of states  In any given state, a proposition is either true or false  Correctness criteria can be expressed in terms of states in which a given proposition should hold  Specified by assertion statements in PROMELA

13. CSE555-SqalliTerm 0324-1-13 Temporal Ordering of Propositions  Correctness criteria can be expressed as a temporal ordering of propositions (if more than one proposition is used)  Need to specify order in which propositions are required to hold  Truth of one proposition follows (immediately or eventually) the truth of another  Complementary way to express temporal ordering  Define the order in which propositions should never hold  Only this alternative is supported in PROMELA  Through a language feature called temporal claim

14. CSE555-SqalliTerm 0324-1-14 Temporal Claims  We need to specify ordering of propositions  Semantics of proposition orderings is different from statement orderings in PROMELA  A sequential ordering implies that second statement in a process is to be executed after the first one terminates  However, in reality we cannot assume relative speed of entities  All we can say is that second statement executes eventually after the first one  Correctness claims have to be more specific  In a temporal claim, a sequential ordering of two propositions defines an immediate consequence

15. CSE555-SqalliTerm 0324-1-15 Temporal Claims and Process Types  Types of correctness requirements are different for terminating and cyclic sequences  Terminating processes  An important requirement for terminating sequences is absence of deadlocks  Not all terminating sequences correspond to deadlocks  Need to express which final state properties make a terminating sequence acceptable as non-deadlocking.  Cyclic processes  Temporal claims for cyclic sequences need to express general conditions, such as absence of livelocks and non-progress cycles

16. CSE555-SqalliTerm 0324-1-16 Assertions  Correctness criteria can be expressed as boolean conditions  This criteria must be satisfied whenever a process reaches a given state  PROMELA uses assert statement for this purpose  Syntax of assert statement assert (condition)  The condition can be an arbitrary boolean expression  This statement is always executable  It can be placed anywhere in a PROMELA specification  Effect of the assert statement:  If the condition is true, the statement has no effect  If condition is false in at least one execution sequence, the validity of the statement is violated  The PAN run-time flag –A can be used to disable the reporting of assertion violations  “ spin –a file_name.pml ” will generate a pan.c file. This file is compiled “ cc –o pan pan.c ” to get the executable used for verification

17. CSE555-SqalliTerm 0324-1-17 Assertions: Example  In this example, we cannot predict what will be the final value of state  0, 1, or 2  We can try the following correctness criteria:  When process of type A completes, value of state must be 2  When process of type B completes, value of state must be 0  Expressed using assert  Claims are of course false! Example without assertions Example with assertions C:\Tools\spin>spin state.pml state in A is: 1 spin: line 2 "state.pml", Error: assertion violated spin: text of failed assertion: assert((state==2)) #processes: 3 state = 1 8: proc 2 (B) line 3 "state.pml" (state 3) 8: proc 1 (A) line 2 "state.pml" (state 4) 8: proc 0 (:init:) line 4 "state.pml" (state 3) 3 processes created

18. CSE555-SqalliTerm 0324-1-18 System Invariants  System invariants are boolean conditions, such that:  If they are true in the initial system state, they remain true in all reachable system states  This is independent of the execution sequence that leads to each specific state  A more general application of assert is to formalize system invariants  System invariants can be expressed in a monitor process  Example: proctype monitor() { assert (invariant) }  This process, after it has been started with a run statement, continues to execute independently of the rest of the system  The assert statement is executable once for every system state

19. CSE555-SqalliTerm 0324-1-19 System Invariants: Dijkstra’s Semaphore #define p0 #define v1 chan sema[0] of { bit }; proctype dijkstra() {do :: sema!p -> sema?v od } proctype user() {sema?p; /* critical section */ sema!v /* non-critical section */ } init {atomic { run dijkstra(); run user(); run user(); run user(); }  Semaphore guarantees mutually exclusive access to critical sections  We can modify the above to count the number of user processes in the critical section #define p0 #define v1 chan sema[0] of { bit }; byte count; proctype dijkstra() {do :: sema!p -> sema?v od } proctype user() {sema?p; count = count + 1; skip; /* critical section */ count = count – 1; sema!v skip; /* non-critical section */ } proctype monitor() { assert(count==0 || count==1) } init {atomic { run dijkstra(); run monitor(); run user(); run user(); run user(); }

20. CSE555-SqalliTerm 0324-1-20 Deadlocks  Two types of possible execution sequences in a finite state system:  Either terminate after a finite number of state transitions; or  Cycle back to a previously visited state  There are two types of end states that should be distinguished:  Expected or proper end states  Unexpected end states  Error states due to incomplete or inconsistent protocol specifications  Deadlock state is only one type of possible error states  Example: unspecified receptions  Two criteria for the final state of a terminating execution sequence to be considered a proper end-state:  Every instantiated process has terminated  All message channels are empty

21. CSE555-SqalliTerm 0324-1-21 Deadlocks: End-State Labels  All processes do not necessarily terminate  Some processes may stay alive even after all others terminate  Example: server processes  In PROMELA, process states can be identified in proctype definitions as proper end-states using end-state labels  Exmaple: dijkstra’s algorithm: proctype dijkstra() { end: do :: sema!p -> sema?v od }  Process will be considered in a proper end-state when it is in a state labeled end

22. CSE555-SqalliTerm 0324-1-22 End-State Labels (Cont’d)  More than one proper end-sate within a single proctype are possible  All label names must be unique  An end-state label is any label with prefix end  Examples: enddne, end0, endme, end_of_part_1, end_war etc.  Revised first criterion of proper end-state:  Every instantiated process has either terminated or reached a state marked as a proper end-state  Any final state in a terminating execution sequence that does not satisfy above criteria is classified as an improper end-state  An implicit correctness claim for a validation model is that the behaviors they define, do not include any improper end states  The PAN run-time flag –E can be used to suppress the reporting of invalid end states (i.e., “ pan –E ”)  The PAN run-time option –q means that all message channels must be empty for a system state to be considered valid (in addition to reaching a valid end state).

23. CSE555-SqalliTerm 0324-1-23 Bad Cycles  Correctness requirements (i.e., properties) of cyclic sequences can be expressed in PROMELA:  Non-progress cycles  Livelocks  Two properties are:  No infinite behaviors of only unmarked states  System cannot infinitely cycle through unmarked states  Marked states are called progress-states  Execution sequences violating this correctness claim are called non- progress cycles  No infinite behaviors that include marked states  Execution sequences violating this claim are called livelocks

24. CSE555-SqalliTerm 0324-1-24 Non-Progress Cycles  How to claim absence of non-progress cycles?  Define the system states within PROMELA model that represent progress  Defined through progress-state labels  A progress-state label marks a state that must be executed for the protocol to make progress  Examples:  Delivering data to a receiver  Incrementing a sequence number  Passing of a semaphore test will show “progress” proctype dijkstra() { end:do :: sema!p -> progress:sema?v od }  The passing of the semaphore guard cannot be postponed infinitely long  In all infinite executions, the semaphore process reach the progress label infinitely often  An automated validator can confirm that this claim cannot be violated  More than one progress-state labels are possible: progress0, progressing, progression etc.  Use “ cc –DNP –o pan pan.c ” to enable non-progress checking, and “ pan -l ” to search for non-progress cycles

25. CSE555-SqalliTerm 0324-1-25 Livelocks  Formally expressed as something that cannot happen infinitely often  Using acceptance-state labels  An acceptance-state marks a state that may not be part of a sequence of states that can be repeated infinitely often.  An acceptance-state label start with prefix “accept”  Examples: acceptance, accepting, etc.  Example: modified proctype dijkstra (): proctype dijkstra() { end: do :: sema!p -> accept:sema?v od }  Claim: it is impossible to cycle through a series of p and v operations  This claim is false

26. CSE555-SqalliTerm 0324-1-26 Temporal Claims  So far, we have defined specifications of correctness criteria with:  Assertions  Three special labels to mark end, progress, and acceptance states  Temporal claims define temporal orderings of properties of states  We can express claims, such as: Every state in which property P is true is followed by a state in which property Q is true This is expressed as: P -> Q  In the above statement, “followed by” has two interpretations:  Immediately followed by; or  Eventually followed by  PROMELA support the second interpretation with the first as a special case

27. CSE555-SqalliTerm 0324-1-27 Temporal Claims (Cont’d)  Two problems in specifying temporal claims P -> Q :  Temporal claims should express orderings of properties that are impossible, just like other correctness criteria  Temporal claims are defined on complete execution sequences  Even if a prefix of the sequence is irrelevant, it must be represented as a trivially true sequence of propositions  Example: never { do :: skip :: break od -> P -> !Q }  Independent of initial sequence of events, it is impossible for a state in which property P is true to be followed by a state in which property Q is false  Claim is matched if and when claim body terminates and corresponding correctness property is violated  Thus, PROMELA notation for temporal claims is: never { … }  A never claim is normally used to specify either finite or infinite system behavior that should never occur

28. CSE555-SqalliTerm 0324-1-28 Example: Temporal Claims  We want to express the temporal property that condition1 can never remain true infinitely long  We need a representation of all behaviors, such that  condition1 may be false initially  It becomes true eventually  It remains true  Expressed in PROMELA as follows: never { do :: skip :: condition1 -> break od; accept: do :: condition1 od }  If and when the acceptance cycle is detected, claim is matched and corresponding correctness property is violated (livelock)

29. CSE555-SqalliTerm 0324-1-29 Example: Temporal Claims (Cont’d)  Another claim (perhaps an erroneous version of previous) can be expressed as follows: never { do :: skip :: condition1 -> break od; accept: condition1 }  Claim has just two state transitions after condition1 becomes true:  This claim is completely matched if there is at least one execution sequence in which condition1 holds in two subsequent states  For the first version, it would be an error (a livelock) if the machine can stay in the accept state infinitely long.  For the second version, it would be an error if the terminal state is reachable

30. CSE555-SqalliTerm 0324-1-30 Specifying Temporal Claims  Body of a temporal claim is similar to a proctype body, except for one difference:  Every statement inside a temporal claim is interpreted as a condition  These should be free of side-effects  PROMELA statements with side-effects are: assignments, assertions, sends, receives, and printf statements.  A temporal claim is matched if:  An undesirable/illegal behavior can be realized  Thus, correctness claim is violated  Application of temporal claims:  Most useful ones combine temporal claims with acceptance labels  Two ways to match a temporal claim depending on undesirable behavior  Undesirable behavior can define:  A terminating sequence; or  A cyclic execution sequence (livelock)

31. CSE555-SqalliTerm 0324-1-31 Specifying Temporal Claims (Cont’d)  For a terminating execution sequence, a temporal claim is matched only when it can terminate (reaches the closing curly brace)  The claim can be violated if the closing curly brace of the PROMELA body of the claim is reachable.  For a cyclic execution sequence, the claim is matched only when an explicit acceptance cycle exists.  To check a cyclic temporal claim, acceptance labels should only occur within the claim and not elsewhere in the PROMELA code.  A combination of never claim with accept labels can express the absence of non-progress cycles  Thus, temporal claims are more general than progress-state labels  However, cost (complexity) of validation with progress-state labels is smaller  There are easier ways to express never claims  Spin’s built-in translator from formulae in linear temporal logic (LTL) to never claims (less expressive than never claims)  The timeline editor, a graphical tool, converts timeline descriptions into never claims (less expressive than LTL formula)

32. CSE555-SqalliTerm 0324-1-32 trace Assertion  Expresses a correctness requirement on existing behavior in the remainder of the system  Expresses properties of message channels  Formalizes statements about valid and invalid sequence of operations that processes can perform on message channels  All channel names referenced in a trace assertion must be global  All message fields must be global or mtype constants.  Example: trace { do :: q1!a; q2?b od }  Send operations on channel q1 alternate with receive operations on channel q2  All send operations on q1 are exclusively messages of type a  All receive operations on q2 are exclusively messages of type b  Must always be deterministic  Cannot contain random receive, sorted send, or channel poll operations  No data objects can be declared or referred to inside a trace assertion  Don’t care values for specific message fields can be specified with the predefined write-only variable _ (i.e., the underscore symbol)  notrace assertion is also supported, but rarely used  Specifies a sequence of events that should not occur in an execution

33. CSE555-SqalliTerm 0324-1-33 Tracing Verification Errors  When the verifier finds an error it writes a complete trace for the error execution into a file called file_name.pml.trail  Using this file, we can reproduce the error trail with spin’s guided simulation option: “ spin –t –p file_name.pml ”