THE SPIN MODEL CHECKER[HOLZMANN, 03]

CHAPTER 3, 4, AND 11

Takumi Kida

Mitsuharu Kurita

Ayato Miki

1

REVIEW

Parallel and distributed systems Validation of systems are difficult “Model checking tools”

Check models of them mechanically

2

Initial state

State transition

Assertion

CHAPTER 3AN OVERVIEW OF PROMELA

Mitsuharu Kurita

3

SPIN MODEL CHECKER AND PROMELA

Spin Model checker for parallel / distributed systems Validate the state transition of models Modeling language: Promela

Promela Modeling language with C-like syntax Not intended to be used in implementation

4

active proctype Sender(){again:to_rcvr!msg;to_sndr?ack;goto again}…………….

active proctype Sender(){again:to_rcvr!msg;to_sndr?ack;goto again}…………….

Promela codeSystem model

MODEL EXAMPLE 1 Primitive sender / receiver

5

mtype = {msg, ack};

chan to_sndr = [2] of {mtype};chan to_rcvr = [2] of {mtype};

active proctype Sender(){again: to_rcvr!msg;

to_sndr?ack;goto again

}active proctype Receiver(){again: to_rcvr?msg;

to_sndr!ack;goto again

}

msg

msg

ack

ack

ReceiverSender

THE STRUCTURE OF PROMELA CODE

3 main components in Promera

mtype = {msg, ack};

chan to_sndr = [2] of {mtype};chan to_rcvr = [2] of {mtype};

active proctype Sender(){again: to_rcvr!msg;

to_sndr?ack;goto again

}active proctype Receiver(){again: to_rcvr?msg;

to_sndr!ack;goto again

}

6

Processes

Message channels

Data objects

PROCESSES (1)

Multiple processes which work in parallel Different from “native” processes Expressed as objects of “proctype” type Process details are written like functions in C Up to 255 processes can be exist at the same

moment

active [2] proctype you_run(){printf("my pid is: %d\n",

_pid)}

my pid is: 0my pid is : 1

2 processes created

2 processes are defined

Each of them is executed

simultaneously 7

PROCESSES (2)

Another expression to run processes

8

proctype you_run(){printf("my pid is: %d\n",

_pid)}

init{run you_run();run you_run();

}

my pid is: 2 my pid is: 13 processes created

Process definition without “active”

DATA OBJECTS (1)

Basic data types Basically they are derived from C All of them can be used as int Some do not exist in C

chan Message channels mtype Message types pid Process id

Scope of variables Global Process local

No function exists in Promela

User-defined types are available

Type Typical Range

bit 0, 1

bool false(0), true(¬0)

byte 0 .. 255

chan 1 .. 255

mtype 1 .. 255

pid 0 .. 255

short -215 .. 215 - 1

int -231 .. 231 - 1

unsigned

0 .. 2n - 1

9

typedef Field{short f =

3;byte g

}

DATA OBJECTS (2)

mtype Variable type for labeling of kinds of messages Similar to “enum” in C

10

mtype = {msg, ack};

MESSAGE CHANNELS (1)

Message channels Interprocess communications which have buffer Message has some fields expressed as data

types User-defined types can be included

11

chan qname = [16] of {short, byte, bool}

qname!10,50,true

qname?var1,var2,var3qnam

e

MESSAGE CHANNELS (2)

Restricted reception You can restrict receiving messages with

constant value

12

qname?30,var2,var3

Messages whose value of the first field is 30 can be

received

qname?eval(var1),var2,var3

Restriction with contents of variable “var1”

MODEL EXAMPLE 1 (REVISITED) Primitive sender / receiver

13

mtype = {msg, ack};

chan to_sndr = [2] of {mtype};chan to_rcvr = [2] of {mtype};

active proctype Sender(){again: to_rcvr!msg;

to_sndr?ack;goto again

}active proctype Receiver(){again: to_rcvr?msg;

to_sndr!ack;goto again

}

msg

msg

ack

ack

ReceiverSender

CONTROL FLOW

Selections Repetitions Atomic sequences Deterministic steps Escape sequences

14

EXECUTABILITY

Each expression in Promela has “executability”

Processes block at “inexecutable” expression Basically it is boolean values of expressions

Example: a == b : blocks until a == b (same as while(a !=

b){} in C) chan!val1 / chan?var1 : blocks if chan is full /

empty false : eternally blocks a = b, printf : always executable 15

SELECTIONS (1)

Statements between “if” and “fi” Different from “if” block in C

Each option is marked with “::” A statement whose first expression is executable

is selected If more than 2 options are executable, one of

them is chosen randomly

16

if:: (a != b) -> option 1:: (a == b) -> option 2:: printf(“Hello, world.”)fi

printf can be executed regardless of values of a or b

SELECTIONS (2)

If all options are inexecutable, the process blocks until one or more options get executable

Options can include “else”, which is executed only when all of the other options are inexcutable

17

REPETITIONS

Statements between “do” and “od” It repeats selection same as “if” repeatedly

There is no “while” or “for” in Promela Simple loops are denoted by “goto”

18

do:: count++:: count—od

count randomly moves up and

down

ATOMIC SEQUENCES ANDDETERMINISTIC STEPS

Atomic sequences Statements in “atomic{}” Executed atomically as long as

the statements are executable Deterministic steps

Statements in “d_step{}” Each statement must be

executable and deterministic Cannot get into / out of block

with “goto”

19

atomic{tmp =

b;b = a;a =

tmp;}

d_step{tmp =

b;b = a;a =

tmp;}

ESCAPE SEQUENCES

2 code blocks connected by “until”

If the first statement in E is inexecutable, P is executed

As soon as E gets exutable, E is executed and the control flow never backs to P

If P is finished before E becomes executable, E is abandoned

20

{P}until{E}

MODEL EXAMPLE 2

Simple model of telephone system

21

SUMMERY

Introduced Promela Model definition language for Spin

Syntax and functions of Promela 3 main components

Data objects Message channels Processes

Control flow Executability Selection Repetition and so on

22

Chapter 4Takumi Kida

Outline of Chapter 4

About SPIN verification process Basic Types of Claims

Basic Assertions End State Labels Progress State Labels Accept State Labels Never Claims Trace Assertions

Built-in Variables and Functions Logical Formulations of Correctness

LTL (Linear Temporal Logic) The Link between LTL and Never Claims

About SPIN verification process

User can define some correctness requirement in PROMELA

Some types of properties , such as system deadlock states, need not be stated explicitly. They are checked by default.

SPIN does not care about

{

…

…

}

META labels, assertion claims

PROMALA Code

Verifier

Basic Assertions

Basic assertions are always executable The implied correctness property is that it is

never possible for the expression to evaluate to false (or zero)

Init{

assert ( expression ) /* assert that expression is true */

}

Init{

assert (false) /* error */

}

Examples

End State Labels In PROMELA, by default, the only valid end

states are those in which every process has reached the end of its code

The end state labels define additional valid end states

Every labels name that starts with the prefix ‘end’ means end state label

…(){

end:

…

…

} End of code is default end state

Additional end state defined by user

Progress State labels

Progress state labels is signifying that the executing process is making effective progress, rather than

Every potentially infinite execution cycle passes through at least one progress labels.

If cycles that do not have this property, it will be error of the existence of non-progress cycle

Variation with a prefix ‘progress’ is available

Examples

Dijkstra’s Semaphore (Model)

Count

User Processes

Semaphore

User1 User2 User3 …

P operation

If(count !=0)

Count --

V operation

Count ++

Examples Dijkstra’s Semaphore (Code)

mtype {p,v}; chan sema = [0] of {mtype};

active proctype Dijkstra(){ /* Semaphore Process */

byte count=1;

end: do /* this line is also valid end state ! */

:: (count == 1) ->

progress: sema!p; count =0;

:: (count == 0) ->

sema?v; count =1;

od

}

active[3] proctype user(){ do:: sema?p; /* Enter */

critical: skip; /* Critical Section */sema!v; /* Leave */

od }

An example of non-progress cycle

byte x =2; /* global */

active proctype A(){

do

:: x = 3 - x;

od

}active proctype B(){do

:: x = 3 - x;od}

/* x changes between 2 and 1 infiitely */

If there is no progerss labels, these cycles is guaranteed to be a non-progress cycle.

Accept State labels

The implicit correctness expressed by accept labels is that there should not be any infinite loops that pass through an accept state label.

Accept state labels is normally used in never claims (next section)

Variations with the prefix ‘accept’ is also available

never{accept:

do:: !q /* q must not be false infinitely (eventually becomes true )

*/od;

}

Examples

Never Claims

Never claim is normally used to specify either finite or infinite system behavior that should never occur

Never claim checks system properties just before and just after each statement execution

never{ /* p must remain true */

do

:: !p -> break /* break from never claim means error */

:: else

od

}

Example

Never Claims Another Expression

never{

do

:: assert (p)

od

}

active proctype monitor() {

atomic{ !p -> assert ( false)}

}

Never Claim as a State Machine

ERROR

S1

S0

never{

S0:

do

:: (p || !q ) -> break

:: ture

od

S1:

do

accept :: !q

:: ! (p || q) -> break

od

}

true

!( p || q)

!q

(p || !q)

Trace Assertions

Trace assertion expresses a correctness requirement on the properties of message channels

Trace assertion formalizes statements about valid or invalid sequences of operations that processes can perform on message channels

A trace assertion monitors only a subset of the events in a system that are mentioned in the trace clause

trace{

do

:: q1!a; q2?b

od

}

Examples

Predefined Variables and Functions

Predefined Variables _

_ refers to a global, predefined, write-only, integer variable that can be used to store scratch values.

_pid

read-only variable of type pid that stores the instantiation number of the executing process.

np_read-only variable of type boolean that becomes true when system states

are marked as non-progress states

_last_last is a predefined global variable that holds the instantiation number of the

process that performed the last step in the current execution sequence.

Predefined Variables and Functions

Predefined Functions pc_value(pid)

enabled(pid)

proctype[pid]@label

proctype[pid]: var (Remote Refernce, only SPIN 4.0 or later)

Logical Formulation using LTL

LTL is a modal temporal logic with modalities referring to time.

One can formulate logical condition and its temporal changes

Symbol Explanation

￢，∧，∨，→

the usual logical connectives

[ ] p p must be true on the entire subsequent path (Globally)

<> p p eventually has to become true (Eventually)

p U q q remains true until p becomes true (Until)

X p p has to become true at the next state (neXt)

Formulation by LTL

ERROR

S1

S0

true

!( p || q)

!q

(p || !q)

￢ [ ] ( p → (p U q) )

The Link between LTL and Never Claims In SPIN, there is an automatic generation tool

of never claims using LTL![ ] (p -> (p U q))

never {

T0_init:

if

:: ( ( !(q) ) && (p)) -> goto accept_S4

:: ( true ) -> goto T0_init

fi;

accept_S4:

if

:: ( ! (q)) -> goto accept_S4

:: ( !(p) && !(q) ) -> goto accept_all

fi;

accept_all:

skip

}

spin – f ‘ ) ’

CHAPTER 11USING SPIN

Ayato Miki

43

SPIN STRUCTURE

44

Syntax checker Promelaで記述したモデルの文法をチェックする

Simulatorランダムまたは指定のシーケンスで実行を行う

Verifier generator検証器のコードを生成する検証器は状態空間探索によってモデルの正当性を検証する

ROADMAP

Syntax check $ spin -A model

Random simulation $ spin model

Verification $ spin -a model $ gcc -o pan pan.c $ ./pan

Inspecting error traces $ spin -t -p model

45

SYNTAX CHECK モデルの文法をチェックする

$ spin -A model

46

RANDOM SIMULATION (1)ランダムシミュレーション

$ spin model -nN 乱数の種を Nに指定

いろいろと情報を出力する $ spin -p -l -g model

-p 全ての文の実行履歴を出力 -l 状態変化したプロセスのローカル変数を出力 -g グローバル変数の変化を出力

範囲を指定 $ spin -jN -uM model

Nステップから出力し、Mステップまでで打ち切る 47

RANDOM SIMULATION (2)チャネルによるメッセージの通信イベントを出力

$ spin -s -r model -s 送信イベント -r 受信イベント

$ spin -c model送受信イベントをプロセスごとにカラム表示

48

INTERACTIVE SIMULATION

実行するシーケンスを手動で選択 $ spin -i -p model

49

GUIDED SIMULATION

検証の後で、エラーになったシーケンスを再現する

50

GENERATING A VERIFIER検証器のコードを生成

$ spin -a model pan.b pan.c pan.h pan.m pan.l ができる

メッセージが失われるモデル $ spin -a -m model

-m チャネルキューが一杯のときメッセージを破棄

51

COMPILING THE VERIFIER

検証器をコンパイル $ gcc -o pan pan.c

物理メモリの限度をMB単位で指定 $ gcc -DMEMLIM=512 -o pan pan.c

使用メモリを節約するオプション群 $ gcc -DCOLLAPSE -o pan pan.c $ gcc -DHC4 -o pan pan.c $ gcc -DBITSTATE -o pan pan.c

52

BITSTATE VERIFICATION

普通は 1状態の表現に数十～数百バイト必要大きな探索空間ではメモリがあふれる

状態空間をビットで表現メモリ消費量を格段に削減するただし探索の完全性は保証されない状態数の 100倍以上のメモリがあれば 99％以上のカバー率

53

TUNING A VERIFICATION RUN

普通に検証を実行 $ ./pan

ハッシュテーブルサイズを調整 $ ./pan -wN

2^N個の状態を扱える小さすぎると探索時間大。大きすぎるとメモリ消費大。どちらでも探索の結果に影響はない

ただし、ビット状態空間のときは、小さいとカバー率低下サイズを増やしながら繰り返すのが効率的

54

SEARCH DEPTH (1)

探索の深さを調整 $ ./pan -mNデフォルトは N=10,000大きな状態空間を全探索したいときは深く浅いステップのエラーを見つけるときは浅く

探索スタックをディスクにスワップ $ gcc -DSC -o pan pan.c $ ./pan -mN Nステップまではメモリ、それ以降はディスク

55

SEARCH DEPTH (2)

深さ N以内で最短のエラーシーケンスを見つけたい $ gcc -DREACH -o pan pan.c $ ./pan -i -mNビット状態空間は完全性を欠くため使えない

幅優先探索 $ gcc -DBFS -o pan pan.c無限ループではなく、デッドロックや assert違反など、一瞬のエラー状態のみを見つけるとき

56

ERROR

そもそもエラーとは

Safety propertyデッドロック (invalid end states) assert違反

Liveness property Acceptance cycle

特定の状態を通過する無限ループ Non-progress cycle

特定の状態を通過しない無限ループ57

SAFETY PROPERTY

普通はこちらだけを検出

Assert違反を検出しない $ ./pan -A

Invalid end statesを検出しない $ ./pan -E

58

LIVENESS PROPERTY

Acceptance cyclesを検出 $ ./pan -a

Non-progress cyclesを検出 $ gcc -DNP -o pan pan.c $ ./pan -l

59

INSPECTING ERROR TRACES

Guided simulationエラーを起こすシーケンスを再現する $ spin -t -p model

N個目のエラーだけを検出 $ ./pan -cN

N=0だとエラーが出ても探索を継続する

60

XSPIN

SPINの GUI

61