Logic Model Checking Lecture Notes 10:18 Caltech 101b.2 January-March 2004 Course Text: The Spin Model Checker: Primer and Reference Manual Addison-Wesley 2003, ISBN 0-321-22862-6, 608 pgs. the assignment some additional explanations Thread1: await (x!= 0); x = x 2 Thread2: await (x!= 0); x = x 3 Thread3: await (x == 0); x = x + 5 these are 3 sequential threads of two statements each no cycling is specified here... Thread1: while (x!= y) { x = x 1; y = y + 1; } Thread2: await (x == y); atomically { x = 8; y = 2; } the first thread is cyclic (repeating until x == y), the second is not cyclic unless statements are enclosed explicitly within an atomic block, they cannot be assumed to execute atomically Logic Model Checking [10 of 18] 2 1
some formalism (cf. p. 89 book) properties of models let E be the set of all executions of a model let f be a correctness property a model satisfies a property if all its executions do: (E = f ) ( δ, (δ E) (δ = f) ) a model violates a property if at least one of its executions does: (E = f ) ( δ, (δ E) (δ = f) ) δ:!p p!p!p!p!p!p p!p!q q q q q!q q q q x x x x x x true (p) (q) (q) (q) (δ = f) f: p always implies eventually!q Logic Model Checking [10 of 18] 3 negating a property showing that property f can be violated i.e., showing that (E = f ) is NOT the same as showing that f is satisfied i.e., showing that (E = f ) why not? (E = f ) ( δ, (δ E) (δ = f) ) but (E = f ) ( δ, (δ E) (δ = f) ) i.e. (E = f ) ( δ, (δ E) (δ = f) ) X Logic Model Checking [10 of 18] 4 2
synopsis (E = f ) (E = f ) but (E = f ) / (E = f ) (E = f) (E = f) f f (E = f) (E = f) EE E E (E = f) (E = f) both can be true at the same time Logic Model Checking [10 of 18] 5 an example (book p. 99) simple example where we can have simultaneously (E = f ) and (E = f ) byte x = 0; init { do :: x = 0 :: x = 2 od } never { f do :: assert(x == 0) od } never { f do :: assert(x!= 0) od } violated by x = 2 violated by x = 0 (x == 1) x=0 x=2 (x == 0) (x == 2) x is neither always zero nor is it always non-zero Logic Model Checking [10 of 18] 6 3
Outline introduction what is different about distributed systems the role of abstraction the concept of a verification model modeling concurrency, expressing correctness claims theoretical foundation automata and logic chapter 6 verification algorithms chapter 8 search optimization chapter 9 model checking in practice tools and tool design model building and model extraction challenges Logic Model Checking [10 of 18] 7 automata theory we ll now formally introduce the notion of finite automata, automata runs, words and languages ω-automata, ω-runs, and ω-regular languages Büchi acceptance the stuttering rule automata products linear temporal logic (LTL) and the link to ω-automata leading to our goal... the automata theoretic verification procedure Logic Model Checking [10 of 18] 8 4
finite state automata a finite state automaton is a tuple {S, s 0, L, F, T} S finite set of states s 0 S a distinguished initial state in S L finite set of labels (symbols) F S set of final states in S T SxLxS transition relation, connecting states in S dot notation: given an automaton A A.S is its set of states A.s 0 is its initial state... etc. Logic Model Checking [10 of 18] 9 an example finite state automaton A: {S, s0, L, F, T} α 0 s 0 s 1 α 2 α 4 α 1 s 2 s 4 α 5 A.S: { s 0, s 1, s 2, s 3, s 4 } A.L = { α, α 0 1, α 2, α 3, α 4, α 5 } A.F = { s 4 } A.T = {(s 0,α 0,s 1 ), (s 1, α 1,s 2 ),...} α 3 s 3 Logic Model Checking [10 of 18] 10 5
an interpretation of this automaton a process scheduler idle ready α 0 s 0 s 1 α 2 α 1 pre-empt run execute end α 4 s 2 s 4 α 5 unblock block α 3 s 3 Logic Model Checking [10 of 18] 11 never claim automaton never { idle: () -> ready: (run) -> execute: if :: (pre-empt) -> goto ready :: (block) -> goto :: -> goto end fi; : (unblock) -> goto execute; end: skip } idle ready pre-empt run execute unblock block end Logic Model Checking [10 of 18] 12 6
determinism and non-determism a finite state automaton A={S, s 0, L, F, T} is deterministic iff s l, ((s,l,s ) A.T (s,l,s ) A.T s s i.e., the destination state of a transition is uniquely determined by the source state and the transition label an automaton is called non-deterministic if it does not have this property deny s2 true s0 request approve s3 set F is empty here s1 true a very useful non-deterministic finite state automaton modeling a coarse abstraction of the behavior of a request server Logic Model Checking [10 of 18] 13 the definition of a run a run of finite state automaton {S, s 0, L, T, F} is an ordered, and possibly infinite, set of transitions from T: σ = {(s 0,l 0,s 1 ), (s 1,l 1,s 2 ), (s 2,l 2,s 3 ), } such that i, i 0 : (s i,l i,s i+1 ) T each run corresponds to a state sequence in S and a word in L idle ready (infinite) state sequence from a run: { idle, ready, { execute, } * } pre-empt run execute end the corresponding word in L: {, run, { block, unblock }* } unblock block note: for a non-deterministic automaton a single state sequence may correspond to more than one possible word Logic Model Checking [10 of 18] 14 7
the standard definition of acceptance an accepting run of finite state automaton A is a finite run σ for which the final transition (s n-1,l n-1,s n ) satisfies s n A.F i.e., the run ends in a final state idle ready state sequence of an accepting run: { idle, ready, execute,, execute, end } pre-empt run execute end the corresponding word in L: {, run, block, unblock, } unblock block Logic Model Checking [10 of 18] 15 the language accepted by an automaton the language of automaton A is the set of words in A.L that correspond to the set of all the accepting runs of automaton A (there can be infinitely many words in the language of even a small finite state automaton) idle ready pre-empt run execute unblock block end a characterization of the complete language of automaton A (an infinite set of words): {, run, { { pre-empt, run } + { block, unblock } }*, } a regular expression +: choose *: repeat zero or more times the shortest word in the language: {, run, } Logic Model Checking [10 of 18] 16 8
reasoning about runs formal properties of automata interpretation: sample property: if first p becomes true and then later q becomes true, then r can no longer become true reaching this state constitutes a complete match of the pattern that specifies the correctness violation this property is easily expressed with the standard definition of acceptance!q q r p error!r!p correctness claim: it is an error if in a run we see first p then q and then r Logic Model Checking [10 of 18] 17 but... sometimes we have to reason about potentially infinite delay... attempted interpretation: a classic liveness property:!p if p then eventually q!q error p q Problem: we cannot express with the standard definition of acceptance, we cannot express that a run may not remain in the error state infinitely long... this property can only be violated by an infinite run the standard notion of acceptance applies only to finite runs... Logic Model Checking [10 of 18] 18 9
how we would say this in a never claim better would be to use: true instead of!p (to state that every occurrence of p is eventually followed by q) never { s0: do ::!p :: p -> goto error od; error: accept: do ::!q od }!q error s0 p q!p acceptance states, though, are defined differently in classic automata theory... hence the switch to omega-automata theory... q takes us out of the error pattern, so need not be specified in the automaton Logic Model Checking [10 of 18] 19 notation for every infinite run σ of a finite automaton we can divide the transitions that appear in σ into two sets: a set σ + of transitions that are only taken finitely many times a set σ ω of transitions that are repeated infinitely often σ + σ σ ω Logic Model Checking [10 of 18] 20 10
Büchi acceptance a type of ω acceptance an accepting ω-run of finite state automaton A is an infinite run σ such that i 0,(s i-1,l i-1,s i ) σ : s i A.F s i σ ω i.e., at least one state in A.F is visited infinitely often idle ready pre-empt run execute unblock block end an accepting ω-run for this automaton: { idle, ready, {execute, ready}* } the corresponding ω-word: {, run, { pre-empt, run}* } the ω-language of an automaton is the set of all ω-words accepted Logic Model Checking [10 of 18] 21 accept-state labels Spin s accept-state label precisely capture the semantics of ω-acceptance we just defined Spin can report for any state marked with an accept-state label if the following two conditions can be met: the state is reachable from the initial system state, and the state is reachable from itself these are the necessary and sufficient conditions for an acceptance cycle to exist Q: but if we replace classic acceptance of finite runs with ω-acceptance on infinite runs, do we not lose the capability to reason about finite runs within this new theoretical framework? Logic Model Checking [10 of 18] 22 11
never claims precisely matches the definition of accept state labels in Promela never { idle: () -> ready: (run) -> accept: execute: : end: } if :: (pre-empt) -> goto ready :: (block) -> goto :: -> goto end fi; (unblock) -> goto execute; (false) idle ready pre-empt run execute unblock block end but what should we do with finite runs... Logic Model Checking [10 of 18] 23 the stutter extension rule interpreting finite runs as special cases of infinite runs the label set of the automaton is extended to L ε ε is a predefined nil symbol (a no-op or pause) to determine ω-acceptance, a finite run is (thought to be) extended into an equivalent infinite run by stuttering the final state on ε run: { idle, ready, execute, ready ε, execute, [end,]* } idle pre-empt unblock run execute block end word: {, run, block, unblock,, ε* } we can now use one single acceptance rule to reason about the liveness properties of both finite and infinite runs Logic Model Checking [10 of 18] 24 12
never claims allow us to reason about both infinite and finite runs never { idle: () -> ready: (run) -> accept: execute: : end: } if :: (pre-empt) -> goto ready :: (block) -> goto :: -> goto end fi; (unblock) -> goto execute; true idle ready true pre-empt run execute end unblock block accept2: do :: true od the default meaning of falling off the end of a never claim... which is an application of the stutter extension rule Logic Model Checking [10 of 18] 25 there are also other types of ω-acceptance generalized Büchi acceptance instead of one acceptance set F S, we define a family of sets F = { F 1,..., F n } we now require: j, 1 j n, i 0, (s i-1,l i-1,s i ) σ σ, s i F j s i σ ω i.e., some state in each acceptance set is visited infinitely often an automaton with generalized Büchi acceptance conditions is called a generalized Büchi automaton has the same expressive power as a standard Büchi automaton Logic Model Checking [10 of 18] 26 13
other types of ω-acceptance Muller automata Muller acceptance let F 2 S (F is a set if subsets of S) require: f, f F s, s f s σ ω (at least one of the elements of F contains all states that are visited infinitely often in σ) an automaton with Muller acceptance conditions is called a Muller automaton has the same expressive power as a Büchi automaton Logic Model Checking [10 of 18] 27 other types of ω-acceptance Rabin automata Rabin acceptance choose n pairs of sets (L i,u i ) with L i S and U i S require: i, (1 i n), s, (s L i s σ ω ) t, (t U i t σ ω ) (for at least one pair i, none of the states in L i and at least one state in U i appear infinitely often) an automaton with Rabin acceptance conditions is called a Rabin automaton has the same expressive power as a Büchi automaton Logic Model Checking [10 of 18] 28 14
other types of ω-acceptance Streett automata Streett acceptance choose n pairs of sets (L i,u i ) with L i S and U i S require i, (1 i n), s (s L i s σ ω ) t, (t U i t σ ω ) for at least one pair i, none of the states in U i or at least one state in L i appears infinitely often i.e., if you hit an L-state, you must also repeatedly hit a matching U state an automaton with Streett acceptance conditions is called a Streett automaton all these variants have the same expressive power Logic Model Checking [10 of 18] 29 useful properties of ω-automata Büchi automata, and ω-automata in general, are closed under all Boolean operations, e.g. for any two automata A and B: complement: C : L(C) = L ω \ L(A) there exists an automaton C that accepts precisely those runs that are not accepted by any given automaton A intersection: C : L(C) = L(A) L(B) there exists an automaton C that accepts all runs that are accepted by both A and by B union: C : L(C) = L(A) L(B) there exists an automaton C that accepts all runs that are accepted by either A or by B Logic Model Checking [10 of 18] 30 15
decidability issues two properties of Büchi automata in particular are of interest in applications of logic model checking: language emptiness are there any accepting runs? language intersection are there any runs that are accepted by 2 or more automata? both are formally decidable Spin s model checking algorithm is based on these two checks Spin determines if the intersection of the languages of a property automaton and a system automaton is empty even properties that are stated in linear temporal logic, can be converted into Büchi property automata (i.e., never claims) Logic Model Checking [10 of 18] 31 16