The Model Checker SPIN

The Model Checker SPIN The model checker SPIN

SPIN & Promela • SPIN(=Simple Promela Interpreter) • tool for analyzing the logical consistency of concurrent systems • concurrent systems are described in the modeling language called Promela • Promela(=Protocol/Process Meta Language) • dynamic creation of concurrent processes • communication via message channels • specification language to model finite-state model • C like The model checker SPIN

What is SPIN? (1) • “Press on the button” model-checker, based on automata theory • A popular open-source software tool that can be used for the formal verification of asynchronous and distributed asynchronous and distributed software systems. • Developed in Bell Laboratories. The model checker SPIN

What is SPIN? (2) • Spin can be used in 2 basic modes : • as a simulator to get a quick impression of the types of the behaviour captured by the system model: • guided simulation • random and interactive simulation • as a verifier generator: when a counterexample is generated, it uses simulation to step through the trace The model checker SPIN

Promela • Non-deterministic , guarded command language for specifying the possible system behaviours in a distributed system design • Systems of interacting, asynchronous threads of execution • It brings ideas from: • CSP process algebra by Hoare for input/output • C language in some of the syntax and notational conventions • a non-deterministic guarded command language (without msg passing primitives) by Dijkstra The model checker SPIN

Promela Model mytype = {MSG, ACK}; chan toS=… chan toR=… bool flag; proctype Sender(){ … process body… } proctype Receiver(){ … process body… } init{ … } • Promela model consists of • type declaration • channel declarations • variable declarations • process declarations • [init process] • A Promela model corresponds with a FSM, so: • no unbounded data • no unbounded channels • no unbounded processes • no unbounded process creation The model checker SPIN

Processes • A process type consists of • a name • a list of formal parameters • local variable declarations • body • A process executes concurrently with all other processes, independent of speed of behaviour • There may be several processes of the same type • Each process has its own local state (process counter, local variables) The model checker SPIN

Process instantiation proctype Foo(byte x){ … } init{ int pid2=run Foo(2); run Foo(22); } active [...] proctype Pippo(){ … } • Processes are created using the run statement (it returns the process id) and start executing after it • Processes can be created at any point in the execution • Processes can also be activate by adding in front of the proctype declaration The model checker SPIN

Example proctype Sender(chan in; chan out){ bit sndB, rcvB; do :: out ! MSG, sndB -> in ? ACK, rcvB; if :: sndB == rcvB -> sndB= 1-sndB :: else -> skip fi od } The model checker SPIN

Variables and Types (1) • Basic integer types: bit, bool, byte, short, int, unsigned • Arrays: fixed size byte a[27]; bit flags[4]; • Records typedef Record{ short f1; byte f2; } The model checker SPIN

Variables and Types (2) • Variables should be declared int ii, bb; • Variables can be given a value by • assignment bb=1; Rercord f; f.bb=1; • argument passing • message passing The model checker SPIN

Variables and Types (3) • mtype: a way to introduce symbolic constant values • mtype declaration (up to 255 names): mtype = { msg0, ack0, msg1, ack1 } • pid 0..255 • Communication channel • chan 0…255 The model checker SPIN

Predefined Variables • else • value=true iff no statement in the current process is executable • timeout • value=true iff no statement in the model is executable • _ • write-only scratch variable, does not store a value • _pid • the current process’s instantiation number • _nr_pr • the number of active processes • _last • the pid of process that executed last The model checker SPIN

Communication (1) The model checker SPIN

Communication (2) • Communication between processes is via channels: • message passing • rendez-vous synchronisation (handshake) • Both are defined as channels: chan <name> = [<dim>] of {<t1>,<t2>, … <tn>}; • t1…tn = type of the elements that will be transmitted over the channel • dim = number of elements in the channel [dim==0 is special case: rendez-vous] • Examples: • chan c = [1] of {bit}; • chan toR = [2] of {mtype, bit}; • chan line[2] = [1] of {mtype, Record}; array of channels The model checker SPIN

Communication (3) • channel = FIFO-buffer (for dim>0) • ! Sending - putting a message into a channel ch ! <expr1>, <expr2>, … <exprn>; • The values of <expri> should correspond with the types of the channel declaration. • A send-statement is executable if the channel is not full. • ? Receiving - getting a message out of a channel ch ? <var1>, <var2>, … <varn>; message passing • If the channel is not empty, the message is fetched from the channel and the individual parts of the message are stored into the <vari>s. ch ? <const1>, <const2>, … <constn>; message testing • If the channel is not empty and the message at the front of the channel evaluates to the individual <consti>, the statement is executable and the message is removed from the channel. The model checker SPIN

Communication (4) • Rendez-vous communication <dim> == 0 The number of elements in the channel is now zero. • If send ch! is enabled and if there is a corresponding receive ch? that can be executed simultaneously and the constants match, then both statements are enabled. • Both statements will “handshake” and together take the transition. • Example: chan ch = [0] of {bit, byte}; • P wants to do ch ! 1, 3+7 • Q wants to do ch ? 1, x • Then after the communication, x will have the value 10. The model checker SPIN

Communication (5) • len(q) : returns the number of messages in q • empty(q) : true when q is currently empty • full(q) : true when q is filled to capacity • nempty(q) : added to support optimization • nfull(q) : added to support optimization The model checker SPIN

Statements (1) • The body of a process consists of a sequence of statements. A statement is either • executable: the statement can be executed immediately. • blocked: the statement cannot be executed. • An assignment is always executable. • An expression is also a statement; it is executable if it • evaluates to non-zero. • 2 < 3 always executable • x < 27 only executable if value of x is smaller 27 • 3 + x executable if x is not equal to –3 The model checker SPIN

Statements (2) • The skip statement is always executable. • “does nothing”, only changes process’ process counter • A run statement is only executable if a new process can be created (remember: the number of processes is bounded). • A printf (printm) statement is always executable (but is not evaluated during verification, of course). • assert(<expr>); • The assert-statement is always executable. • If <expr> evaluates to zero, SPIN will exit with an error, as the <expr> “has been violated”. • The assert-statement is often used within Promela models, to check whether certain properties are valid in a state. The model checker SPIN

Interleaving Semantics • Promela processes execute concurrently. • Non-deterministic scheduling of the processes. • Processes are interleaved (statements of different processes do not occur at the same time). • exception: rendez-vous communication. • All statements are atomic; each statement is executed without interleaving with other processes. • Each process may have several different possible actions enabled at each point of execution. • only one choice is made, non-deterministically. The model checker SPIN

if-statement If :: choice1 -> option1 :: choice2 -> option2 :: else -> option3 /* optional */ fi • Cases need not be exhaustive or mutually exclusive • Non-deterministic selection The model checker SPIN

do-statement do :: choice1 -> option1; :: choice1 -> option1; ………. :: choice1 -> option1; od; • With respect to the choices, a do-statement behaves in the same way as an if-statement. • However, instead of ending the statement at the end of the choosen list of statements, a do-statement repeats the choice selection. • The (always executable) break statement exits a do-loop statement and transfers control to the end of the loop. The model checker SPIN

Example proctype counter() { do :: (count != 0) -> if :: count = count + 1 :: count = count – 1 fi :: (count == 0) -> break od } The model checker SPIN

Delimitors • Semi-colon is used a statement separator not a statement terminator • Last statement does not need semi-colon • Often replaced by -> to indicate causality between two successive statements • (a == b); c = c + 1 • (a == b) -> c = c + 1 The model checker SPIN

Variable scoping • Similar to C • globals, locals, parameters byte foo, bar, baz; proctype A(byte foo) { byte bar; baz = foo + bar; } The model checker SPIN

Send and Receive Executability • Send is executable only when the channel is not full • Receive is executable only when the channel is not empty • Optionally some arguments of receive can be constants • qname?RECV,var,10 • Value of constant fields must match value of corresponding fields of message at the head of channel queue The model checker SPIN

Composite conditions • Invalid in Promela • (qname?var == 0) • (a > b && qname!123) • Either send/receive or pure expression • Can evaluate receives • qname?[ack,var] The model checker SPIN

Promela statements • skip always executable • assert(<expr>) always executable • expressionexecutable if not zero • assignmentalways executable • if executable if at least one guard is executable • do executable if at least one guard is executable • break always executable (exits do-statement) • send (ch!) executable if channel ch is not full • receive (ch?) executable if channel ch is not empty The model checker SPIN

assert • assert(any_boolean_condition) • pure expression • If condition holds -> no effect • If condition does not hold -> error report during verification with Spin The model checker SPIN

atomic atomic { stat1; stat2; ... statn } • can be used to group statements into an atomic sequence; all statements are executed in a single step (no interleaving with statements of other processes) • is executable if stat1 is executable • if a stati (with i>1) is blocked, the “atomicity token” is (temporarily) lost and other processes may do a step no pure atomicity The model checker SPIN

d_step { stat1; stat2; ... statn } more efficient version of atomic: no intermediate states are generated and stored may only contain deterministic steps it is a run-time error if stati (i>1) blocks. d_step is especially useful to perform intermediate computations in a single transition d_step The model checker SPIN

proctype P1(){t1a; t1b;t1c} proctype P2(){t2a; t2b;t2c} init{run P1(); run P2()} No Atomicity 0 0 t2a t1a 1 1 t2b t1b 2 2 t2c t1c 3 3 The model checker SPIN

proctype P1(){atomic{t1a; t1b;t1c}} proctype P2(){t2a; t2b;t2c} init{run P1(); run P2()} Atomicity It is as P1 has only one transition, but if one P1’s transitions blocks, these transition may be executed The model checker SPIN

proctype P1(){d_step{t1a; t1b;t1c}} proctype P2(){t2a; t2b;t2c} init{run P1(); run P2()} d_step The model checker SPIN

timeout • Promela does not have real-time features. • In Promela we can only specify functional behaviour. • Most protocols, however, use timers or a timeout mechanism to resend messages or acknowledgements. • timeout • SPIN’s timeout becomes executable if there is no other process in the system which is executable • so, timeout models a global timeout • timeout provides an escape from deadlock states • beware of statements that are always executable… • timeout can be replaced by skip The model checker SPIN

goto goto label • transfers execution to label • each Promela statement might be labelled • quite useful in modelling communication protocols wait_ack: if :: B?ACK -> ab=1-ab ; goto success :: ChunkTimeout?SHAKE -> if :: (rc < MAX) -> rc++; F!(i==1),(i==n),ab,d[i]; goto wait_ack :: (rc >= MAX) -> goto error fi fi; The model checker SPIN

unless { <stats> } unless { guard; <stats> } • Statements in <stats>are executed until the first statement ( guard) in the escape sequence becomes executable. • resembles exception handling in languages like Java • Example: proctype MicroProcessor() { { ... /* execute normal instructions */ } unless { port ? INTERRUPT; ... } } The model checker SPIN

never never { stmnt1; stmnt2; … stmntn } • used to specify behavior that should never happen • the claim is defined as a series of propositions, or boolean expressions, on the system state that must become true in the sequence specified for the behavior of interest to be matched • a never claim can be used to match either finite or infinite behaviors (i.e., safety and liveness properties, and LTL formulae) • it can either be written by hand or they can be generated mechanically from LTL formula The model checker SPIN

LTL patterns • Invariance [] (p) • Spin supports 7 ways to check for invariance • Response [] ((p) -> (<> (q))) • Precedence [] ((p) -> ((q) U (r))) • Objective [] ((p) -> <>((q) || (r))) The model checker SPIN

Invariance • Add the following monitor process to the Promela model: active proctype monitor() { assert(P); } Two variations: • monitor process is created first • monitor process is created last (the –end- transition will be executable after executing assert(P)) • SPIN translates the LTL formula to an accepting never claim. never { ![]P TO_init: if :: (!P) -> goto accept_all :: (1) -> goto TO_init fi; accept_all: skip } The model checker SPIN

SPIN Architecture LTL Translator  Simulator XSPIN Promela Model M SPIN Verifier Generator C Program Counter example Checker The model checker SPIN

Spin capabilities • Interactive simulation • For a particular path • For a random path • Exhaustive verification • Generate C code for verifier • Compile the verifier and execute • Returns counter-example • Lots of options for fine-tuning The model checker SPIN

State vector • A state vector is the information to uniquely identify a system state; it contains: • global variables • contents of the channels • for each process in the system: • local variables • process counter of the process • SPIN provides several algorithms to compress the state vector. The model checker SPIN

The model checker SPIN

Reduction algorithms • SPIN has several optimisation algorithms to make verification runs more effective: • partial order reduction: if in some global state, a process P can execute only “local” statements, then all other processes may be deferred until later • bitstate hashing: instead of storing each state explicitly, only one bit of memory are used to store a reachable state • minimised automaton encoding of states (not in a hashtable): states are stored in a dynamically changing, minimised DFA • inserting/deleting a state changes the DFA • close relationship with OBDDs • state vector compression: instead of storing a state explicitly, a compressed version of the state is stored in the state space • dataflow analysis • slicing algorithm: to get hints for possible reductions The model checker SPIN

Leader Election Protocol • N processes in a ring topology connected by unbounded channels • A process can only send messages in a clockwise manner • Initially each process has a unique identifier assumed to be a natural number • The purpose of a leader election protocol is to make sure that exactly one process will become the leader. • The idea that the process with the highest identier should be elected as a leader The model checker SPIN

LEP Algorithm Active: d:=ident; do forever begin send(d); receive(e); if e= d then stop; (*process d is the leader*); send(e); receive(f); if e>=max(d,f) then d:=e else goto relay end relay: do forever begin receive(d); send(d); end The model checker SPIN

Promela code The model checker SPIN

Global Variables • #define N 5 /*# of processes*/ • #define I 3 /*process with the smallest identifier*/ • #define L 10 /*size of buffer*/ • chan q[N] = [L] of {byte} The model checker SPIN

The Model Checker SPIN