Model Checking TLA+ Specifications Shiji Bijo shijib@ifi.uio.no - PowerPoint PPT Presentation

Model Checking TLA+ Specifications Shiji Bijo shijib@ifi.uio.no Institutt for informatikk, Universitetet i Oslo June 2, 2015 1 / 37

Introduction TLA: temporal logic of actions combination of Logic of actions standard temporal logics Formal specification language for describing and reasoning concurrent and distributed systems. inventend and “pushed” by Leslie Lamport TLA+: extension of TLA Supported by TLC model checker also: deductive verification (TLAPS is a proof system). deductive verification applicable if: system has form of a mathematical theory 2 / 37

Model checking vs. deductive verification Leslie is “in love with” logics (logics is good, programming notation is bad). = ? ϕ remember: model checking: model | (mostly) for finite state systems automatic method deductive verification (mostly) requires user interaction can handle infinite systems TLA/TLA+: Note: framework with one uniform (logical) notation for “specification” of the system and the “properties” to be verified. ⇒ verification (MC or deductive) here then means implication 3 / 37

How does one “program” in logics? remember: Lamport does not use programming notation! However: underlying a very conventional “progamming model”: execution is change of state! ⇒ “logical” representation of change of state prime notation (prime = “ ′ ”) BAD: x:=x+1 ! (in PL’s mostly written x=x+1 ) ⇒ GOOD: x ′ = x + 1 4 / 37

States, actions, predicates in principle: rather conventional concepts state = mapping of variables to values s : Var → Val ] semantic meaning to syntactic object F 1 Notation: [ [ F ] actions syntax for state transformers or transitions boolean expression over variables and primed variable ( Var and Var ′ ) meaning of an action A : relation between states (= “state transformer”). Notation s [ [ A ] ] t predicate P : as usual = boolean expression s [ [ P ] ] is true or false for all states s P includes only unprimed variables and constants 1 Syntactic objects includes variables, states, predicates, actions etc. 5 / 37

Validity and provability valid formula = “always” true. 2 for actions : “universal transition relation” States × States Valid action � | = A s 1 [ [ A ] ] s 2 for all states s 1 and s 2 (1) similarly for predicates � | = P s [ [ P ] ] is true for all states s . Formula F is provable by rules of the logic. notation: provability of formula F in a given proof system (for instance for TLA. ⊢ F (2) Soundness: Every provable formula is valid, ⊢ F ⇒| = F 2 Independent from variable values etc. “always” is not meant as TL � . 6 / 37

Rigid (and flexible) var’s so far: variables mainly motivated by the “programming language” motivation (states of a program, state change/transition) remember: TLA = uniform (logic-based) formalism for specs. and programs often: not only program variables, but also logical variables don’t change their values (= no primed versions) used to talk/reason about the program For instance: parameters of a system one name used here rigid variables (the other ones = flexible vars) 3 compare: Pre/post conditions in Hoare-logic: { x = 3 } x := x + 1 { x = 4 } 3 Other terminology exists as well 7 / 37

Rigid (and flexible) var’s so far: variables mainly motivated by the “programming language” motivation (states of a program, state change/transition) remember: TLA = uniform (logic-based) formalism for specs. and programs often: not only program variables, but also logical variables don’t change their values (= no primed versions) used to talk/reason about the program For instance: parameters of a system one name used here rigid variables (the other ones = flexible vars) 3 compare: Pre/post conditions in Hoare-logic: { x = y } x := x + 1 { x = y + 1 } 3 Other terminology exists as well 8 / 37

Quantification (and rigid var’s) rigid var’s can be used in actions, expressions, predicates etc rigid variables cannot be primed, but quantfied over flexible variables: can be primed, but not quantified over A state is still an assignment of values to flexible variables (Note: validity | = of actions need to take free rigid variables into account). = x ′ + y + m ∈ Nat ⇒ ∀ n ∈ Nat : n ( x ′ + y + m ) ≥ ( x ′ + y + m ) | 9 / 37

Temporal logic remember = TLA = actions + temporal logics choice for TLA: linear time temporal logics! standard operators: boolean connectives temporal operators � ( ♦ can be defined as usual) remark: U is not included. note: � not included the role of � is taken by the actions semantics: standard, based on infinite sequences of states validity of temporal formulas | = ϕ , also as expected: ϕ is valid, if it’s true for all infinite sequences of states 4 4 Independent from any model, etc. 10 / 37

Unseful formulas and “Leads to” as repetition infinitely often: �♦ ϕ stabilization/eventually always: ♦� ϕ “leads to” (written � ): ϕ 1 � ϕ 2 � � ( ϕ 1 → ♦ ϕ 2 ) 11 / 37

Raw TLA as intermediate step to TLA elementary temporal formulas = actions raw logics: logical operators and � and actions However: RTLA is too powerful: can express properties which should not be expressible. note: for the next illustrative very simple example, RTLA would be ok (at least at first sight). 12 / 37

Simple program var n a t u r a l x , y=0; 1 do // i n f i n i t e loop 2 � true → x := x + 1 � 3 [ ] // choice 4 � true → y := y + 1 � 5 od 6 13 / 37

Simple program var n a t u r a l x , y=0; 1 do // i n f i n i t e loop 2 � true → x := x + 1 � 3 [ ] // choice 4 � true → y := y + 1 � 5 od 6 � Init Φ ( x = 0 ) ∧ ( y = 0 ) initial condition ( x ′ = x + 1 ) ∧ ( y ′ = y ) � A 1 1st branch does step ( x ′ = x ) ∧ ( y ′ = y + 1 ) � A 2 2nd branch does step � A A 1 ∨ A 2 non-determinism � Init Φ ∧ � A Φ Note: A describes all steps of the simple program ⇒ � A Remark: instead of choice, � would not change things 14 / 37

Why is RTLA too strict? note: Φ describes (more or less) exactly how the program behaves Isn’t that a good thing? 15 / 37

Why is RTLA too strict? note: Φ describes (more or less) exactly how the program behaves Isn’t that a good thing? Note: an exact description corresponds to a closed world assumption ⇒ No room for partial description, for instance: describing one program running in parallel with other programs (not captured (yet) by the specification) No room for changes (“refinement”) Example: Hour-minute-clock refined to an hour-minute-second clock 16 / 37

TLA: Adding stuttering a program stutters = “it does nothing”, resp. something outside the program does something doing nothing = variables unchanged var n a t u r a l x , y=0; 1 do // i n f i n i t e loop 2 � true → x := x + 1 � 3 [ ] // choice 4 � true → y := y + 1 � 5 od 6 � Init Φ ∧ � A Φ closed program spec. 17 / 37

TLA: Adding stuttering a program stutters = “it does nothing”, resp. something outside the program does something doing nothing = variables unchanged var n a t u r a l x , y=0; 1 do // i n f i n i t e loop 2 � true → x := x + 1 � 3 [ ] // choice 4 � true → y := y + 1 � 5 od 6 Init Φ ∧ � A ∨ ( x ′ = x ∧ y ′ = y ) � Φ open program spec. 18 / 37

TLA TLA formulas must be stutter invariant writing “stutter equations” like before explicitly is cumbersome ⇒ special action syntax: A ∨ ( x ′ = x ) � [ A ] x (3) can be used also for many variables (or even more generally for so-called “state functions”, left out here) TLA: actions can only be written like equation (3) In the previous example Φ � Init Φ ∧ � [ A ] � x , y � (4) 19 / 37

What about “liveness properties”? spec. Φ from (4) is safety property var n a t u r a l x , y=0; 1 do // i n f i n i t e loop 2 � true → x := x + 1 � 3 [ ] // choice 4 � true → y := y + 1 � 5 od 6 does this progam satisfy (not strictly TLA): ♦ ( x = 1 ) ♦ ( x + y = 1 ) 20 / 37

What about “liveness properties”? spec. Φ from (4) is safety property var n a t u r a l x , y=0; 1 do // i n f i n i t e loop 2 � true → x := x + 1 � 3 [ ] // choice 4 � true → y := y + 1 � 5 od 6 does this progam satisfy (not strictly TLA): ♦ ( x = 1 ) ♦ ( x + y = 1 ) as closed program: first property NO , second property YES stuttering-invariants is a problem for “progress” 21 / 37

Liveness under stuttering Remember: Liveness prop. safety prop Never anything bad happens Eventually something “good” (“ � ”) happens (“ ♦ ”) program should not stutter forever (Safety-only) specification Φ of before: does not capture progress of the program (but it should) Φ � Init Φ ∧ � [ A ] � x , y � ∧ �♦ A (5) 22 / 37

Liveness under stuttering Remember: Liveness prop. safety prop Never anything bad happens Eventually something “good” (“ � ”) happens (“ ♦ ”) program should not stutter forever (Safety-only) specification Φ of before: does not capture progress of the program (but it should) Φ � Init Φ ∧ � [ A ] � x , y � ∧ �♦ �A� � x , y � (5) 23 / 37