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 Notation: [ [F] ] semantic meaning to syntactic object F 1 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

1Syntactic 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

• s1[

[A] ]s2 for all states s1 and s2 (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

2Independent 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

• ften: 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

• ne 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 }

3Other 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

• ften: 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

• ne 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 }

3Other 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 states4

4Independent 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

1

var n a t u r a l x , y=0;

2

do // i n f i n i t e loop

3

true → x := x + 1

4

[ ] // choice

5

true → y := y + 1

6

• d

13 / 37

Simple program

1

var n a t u r a l x , y=0;

2

do // i n f i n i t e loop

3

true → x := x + 1

4

[ ] // choice

5

true → y := y + 1

6

• d

InitΦ

• (x = 0) ∧ (y = 0)

initial condition A1

• (x′ = x + 1) ∧ (y′ = y)

1st branch does step A2

• (x′ = x) ∧ (y′ = y + 1)

2nd branch does step A

• A1 ∨ A2

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

• utside the program does something

doing nothing = variables unchanged

1

var n a t u r a l x , y=0;

2

do // i n f i n i t e loop

3

true → x := x + 1

4

[ ] // choice

5

true → y := y + 1

6

• d

Φ

• InitΦ ∧ A

closed program spec.

17 / 37

TLA: Adding stuttering

a program stutters = “it does nothing”, resp. something

• utside the program does something

doing nothing = variables unchanged

1

var n a t u r a l x , y=0;

2

do // i n f i n i t e loop

3

true → x := x + 1

4

[ ] // choice

5

true → y := y + 1

6

• d

Φ

• InitΦ ∧ A ∨ (x′ = x ∧ y′ = y)
• pen program spec.

18 / 37

TLA

TLA formulas must be stutter invariant writing “stutter equations” like before explicitly is cumbersome ⇒ special action syntax: [A]x

• A ∨ (x′ = 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

1

var n a t u r a l x , y=0;

2

do // i n f i n i t e loop

3

true → x := x + 1

4

[ ] // choice

5

true → y := y + 1

6

• d

does this progam satisfy (not strictly TLA): ♦(x = 1) ♦(x + y = 1)

20 / 37

What about “liveness properties”?

• spec. Φ from (4) is safety property

1

var n a t u r a l x , y=0;

2

do // i n f i n i t e loop

3

true → x := x + 1

4

[ ] // choice

5

true → y := y + 1

6

• d

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:

safety prop

Never anything bad happens (“”)

Liveness prop.

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:

safety prop

Never anything bad happens (“”)

Liveness prop.

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 ∧ ♦Ax,y (5)

23 / 37

Liveness under stuttering

Remember:

safety prop

Never anything bad happens (“”)

Liveness prop.

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 ∧ ♦Ax,y (5) (remember: ♦ ¬¬): [A]x

• A ∨ (x′ = x)

24 / 37

Liveness under stuttering

Remember:

safety prop

Never anything bad happens (“”)

Liveness prop.

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 ∧ ♦Ax,y (5) (remember: ♦ ¬¬): [A]x

• A ∨ (x′ = x)

Ax

• A ∧ (x′ = x)

25 / 37

What about fairness?

• cf. our program again:

1

var n a t u r a l x , y=0;

2

do // i n f i n i t e loop

3

true → x := x + 1

4

[ ] // choice

5

true → y := y + 1

6

• d

Does it/should it satisfy “♦(x = 1)”

• ne can refine the previous spec:

Φ InitΦ ∧ [A]x,y ∧ ♦A1x,y ∧ ♦A2x,y (6) these two red formulas are rough examples of fairness assumptions

26 / 37

Weak and strong fairness

standard “slogans”:

weak fairness

An action which is “long enough” continuously enabled, is taken.

strong fairness

(drop somehow the “continuous): an action which is “often enough” enabled, is taken. two “actions” needed

enabled 5 (= in principle executable) executed (= actually executed)

weak fairness ((♦executed) ∨ ♦(¬enabled)) (7) strong fairness ((♦executed) ∨ ♦(¬enabled)) (8)

5For any action A, enabled A is a predicate that is true for a state iff it is

possible to taken an A step starting in that state.

27 / 37

How to decrypt the formulas

Weak fairness: ((♦executed) ∨ ♦(¬enabled)) = (♦executed) ∨ ♦(¬enabled) (ϕ1 ∨ ϕ2) = ϕ1 ∨ ϕ2 strong fairness ((♦executed) ∨ ♦(¬enabled))

28 / 37

How to decrypt the formulas

Weak fairness: ((♦executed) ∨ ♦(¬enabled)) = (♦executed) ∨ ♦(¬enabled) (ϕ1 ∨ ϕ2) = ϕ1 ∨ ϕ2 Hint: try the negated formula: ¬weakfair strong fairness ((♦executed) ∨ ♦(¬enabled)) Hint: again, try the negated formula: ¬strongfair

29 / 37

System Specification in TLA

TLA system spec.

TLA system specifications have the form Init ∧ [Next]v ∧ L (9)

Init: State predicate of initial state(s) Next: Action formula specifies the next-state relation.

• usually disjunction A1 ∨ A2 ∨ ... ∨ An of all possible actions Ai

v: all flexible variables L: Temporal formula asserting liveness property

• usually written as conjunction WFv(Ai) ∧ ..... ∧ SFv(An)of

fairness conditions on actions

The example again, e.g.: Φ InitΦ ∧ [A]x,y ∧ WF x,y(A1) ∧ WF x,y(A2) (10)

30 / 37

What about “parallel” programs?

again: it’s a logical framework, there’s no programming languages however parallel composition = conjunction

31 / 37

TLA+

TLA is a program logic that expresses both programs and properties with a single language and TLA+ is a complete specification language based on TLA.

Modular structure Specifications can be incrementally refined to low level designs TLA+ is untyped: e.g. 5 = TRUE, 17 ∧ “abc” Type correctness checked by asserting invariance property

Type correctness of a TLA+ specification Sp is an invariance property asserting that, in every state reached during every possible execution satisfying Sp, each state variable is an element of an appropriate set (its type). One finds type errors by checking this invariance property.

32 / 37

TLA+: Type correctness example

1 MODULE HourClock 2 3 EXTENDS Naturals 4

VARIABLE hr

5 6

HCinit hr ∈ (0..23)

7

HCnext hr ′ = (hr%23) + 1

8

HC HCinit ∧ [HCnext]hr ∧ WF hrHCnext

9 10 THEOREM HC ⇒ HCinit # Type Correctness

HCinit is the Type Invariant also.

This theorem asserts that the formula, HC ⇒ HCinit, is true for all possible executions of HC.

33 / 37

Refinement

1

MODULE HourMinuteClock

2

EXTENDS Naturals, Hourclock

3

VARIABLE min

4 5

HMCinit HCinit ∧ min ∈ (0..59)

6

Min min′ = (min%59) + 1

7

Hr (min = 59 ∧ HCnext) ∨ (min < 59 ∧ hr′ = hr)

8

HMCnext Min ∨ Hr

9

HMC HMCinit ∧ [HMCnext]hr,min ∧ WFhr,minHMCnext

10

THEOREM HMC ⇒ HC

34 / 37

TLC

Interactive theorem provers

Applicable to TLA/TLA+ specifications Tedious to apply, needs more expertise

TLC: TLA+model checker

Finite state models can be analyzed Brute-Force model checker, explicit state representation Accepts TLA+specification and configuration file as inputs

Configuration file

SPECIFICATION Prog INVARIANT TypeInv PROPERTY NoDeadLock

35 / 37

How TLC Works

Distributed and non-distributed mode Uses disk for storing internal data structures and main memory as cache Set of worker threads and a master thread to co-ordinate A set seen and a FIFO queue sq Initially compute all states satisfying initial predicate and keeps in seen and sq Remove state s from head of sq and compute next state t for all possible subactions

Check if t is in seen. If it isn’t, check if t satisfies the invariant. If it does, add t to seen (with a pointer to s). If t satisfies the constraint, add it to the end of sq.

An error is reported if a next state t is found that does not satisfy the invariant, or if s has no next state(uses pointers to predecessor to generate error traces) State explosion problem

36 / 37

References I

[Lamport, 1994] Lamport, L. (1994). The temporal logic of actions. ACM Transactions on Programming Languages and Systems (TOPLAS), 16(3):872–923. [Yu et al., 1999] Yu, Y., Manolios, P., and Lamport, L. (1999). Model checking tla+ specifications. In Correct Hardware Design and Verification Methods, pages 54–66. Springer. 37 / 37