Model Checking in Practice

with Spin

© Riccardo Sisto, Politecnico di Torino

Spin

• “General purpose” formal verification and

debugging tool developed at AT&T (Bell labs,

Lucent)

– for concurrent/distributed systems

– based on state exploration

– LTL model checking, assertion checking, simulation, …

– open source, very reliable and stable, large user

community, ACM system software award

– Very efficient, user friendly

– Documentation, references, download:

www.spinroot.com

DIISFV 2 Spin

Spin

• ’80 : Spin ancestors (for communication

protocols)

• 1991: Spin 1.0

• 1995: Spin 2.0

• 1997: Spin 3.0

• 2002: Spin 4.0 (Embedded C source code)

• 2007: Spin 5.0 (Support for multi-core)

• 2010: Spin 6.0 (inline LTL formulas)

increasing

efficiency

DIISFV 3 Spin

Spin Architecture

Promela

Parser

LTL

Translator

Interactive

Simulator

Verifier

Generator

SPIN

spin

pan.* Checker

(C source)

C compiler

Checker

(exe) verification

results

pan.exe

User

Interface

(xSpin

iSpin,

jSpin)

Finite model

(communicating state machines)

DIISFV 4 Spin

Promela

• Model specification language

– C-like syntax (with C pre-processor)

– model: concurrent finite-state processes

• Synchronous and asynchronous interaction

• Shared variables

• Non-determinism

• Dynamic Process Creation/Destruction

• Missing features:

– functions, pointers

DIISFV 5 Spin

Proctype (extended state machine)

• A process described by a proctype can be instantiated by the statement:

• The special proctype init is automatically instantiated, and similarly the proctype with the active qualifier:

proctype identifier ( formal arguments ) { declarations and statements }

run identifier( actual arguments )

init { … }

active proctype … ( … ) { … }

DIISFV 6 Spin

Types and Variables

• Global Variables (shared): are declared outside proctypes

• Local variables (private) : are declared in the proctypes

• Types:

– builtin (bool, bit, byte, short, int)

– Defined by enumeration:

• mtype { F0, F1, ACK }

– Arrays and structs

• C syntax

DIISFV 7 Spin

Statement

• A statement can be executable or non-executable

– Example:

(a>b); executable if condition is true

a=b; always executable (assignment)

• The control flow of a process proceeds only on executable statements.

• A sequence of statements can be constrained to be executed atomically, by the atomic block: atomic { temp=a; a=b; b=temp }

DIISFV 8 Spin

Channels

• Are a means for inter-process synchronization and communication

• Communication/synchronization events are data n-tuples (messages)

• Declaration syntax:

chan identifier = [n] of {type,type,...}

• n=0: synchronous coupling

• n>0: asynchronous coupling (on n-slots fifo channel)

• Example: 1-slot channel, event represented by an integer:

– chan buf1= [1] of { int }

DIISFV 9 Spin

Interaction on Channels

• Send message on channel (output):

channel ! message

– is executable if channel not full (and queue policy is no-discard)

• Receive message from channel (input):

channel ? variable

– is executable if a message can be received from the channel

– A scratch “ _” variable can be used if message is to be discarded

• Example (synchronous coupling channel): chan c = [0] of byte

byte x;

c!0; c?x; c?_;

DIISFV 10 Spin

Control Statements

• non-deterministic n-way selection: if

:: statement 1 ...

:: statement n fi

• loop (repeats non-deterministic n-way selection): do

:: statement 1 ...

:: statement n od

• Unconditioned jump:

goto label

....

...

DIISFV 11 Spin

Example: AB Protocol

mtype = {F0, F1, ACK}; chan ch12 = [1] of {mtype, byte}; chan ch21 = [1] of {mtype, byte}; chan sap1 = [0] of {byte}; chan sap2 = [0] of {byte}; init { atomic { run Tx(sap1,ch12,ch21); run Rx(sap2,ch21,ch12); run Errors(ch12); run Errors(ch21); run UpperLayer(sap1,sap2); } }

Tx Rx

sap1 sap2

Errors

UpperLayer

Errors

DIISFV 12 Spin

proctype Tx(chan sap; chan cout; chan cin) { bit nexttosend=0, ack; byte mess; do :: sap?mess; do :: cout!nexttosend,mess; if :: cin?ACK,_; break; :: skip /* timeout */ fi od; nexttosend = (nexttosend + 1)%2; od }

Sender

DIISFV 13 Spin

proctype Rx(chan sap; chan cout; chan cin) { bit expected=0,seqn; byte mess; do :: cin?seqn,mess; if ::(seqn == expected); sap!mess; expected = (expected + 1)%2; ::(seqn != expected)-> skip; fi; cout!ACK; od }

Receiver

DIISFV 14 Spin

proctype Errors(chan ch) { do :: ch?_,_ /* eliminates a message from channel */ od }

Errors

DIISFV 15 Spin

Builtin Reachability Analysis

• Spin automatically checks for

– Absence of deadlocks (invalid endstates)

– Absence of unreachable code

– assertions

• Expressed in Promela by the statement

assert(predicate)

• Any safety property can be verified in this way

– More efficient than LTL model checking!

DIISFV 16 Spin

Verification of a []P invariant

• Since P must be true in all states, we can add a monitor

process:

active proctype monitor {

assert(P);

}

• The monitor is more efficient if written as:

active proctype monitor {

!P -> assert(P);

}

DIISFV 17 Spin

LTL Model Checking

• Uses the automata theoretic approach

• Good practice: don’t use the next operator if possible

(many spin optimizations do not apply with this operator)

– Next-free formulas are said “stuttering-invariant”

– The most interesting properties can be expressed this way

• Built-in property:

– Absence of non-progress cycles

DIISFV 18 Spin

Reduction Techniques

• Spin uses several memory compression algorithms

(selectable):

– Standard compression

– “minimized-automata” compression

• Partial-order reductions can be selected

– Cannot be used for non stuttering-invariant formulas

– No symmetry-based reductions (but are implemented in a spin

extension)

DIISFV 19 Spin

Bit state hashing

• Is like a lossy compression technique

– Visited states are stored in a fixed-size hash table (with

selectable size)

– Each state is represented by a single bit (or few bits) in the table

– In case of collision, more states share the same memory

representation

• The result is a non-exhaustive search

– spin uses heuristics for estimating coverage

DIISFV 20 Spin

Spin Usage

There are several “verification levels” of a model:

1. Interactive simulation and random simulation

• Lets the user detect and correct the first main errors (like code debugging)

2. Partial verification

• Fast verification (bit state hashing) that can intercept more errors than simple simulation

3. Exhaustive Verification

• Can lead to proof of correctness

DIISFV 21 Spin