Compositional Software Model Checking Dan R. Ghica Oxford - - PowerPoint PPT Presentation

▶
compositional software model checking
SMART_READER_LITE
LIVE PREVIEW

Compositional Software Model Checking Dan R. Ghica Oxford - - PowerPoint PPT Presentation

Apr 02, 2024 464 likes •856 views

Compositional Software Model Checking Dan R. Ghica Oxford University Computing Laboratory October 18, 2002 Outline of talk program verification issues the semantic challenge programming languages the logical challenge

slide-1
SLIDE 1

Compositional Software Model Checking

Dan R. Ghica Oxford University Computing Laboratory October 18, 2002

slide-2
SLIDE 2

Outline of talk

  • program verification issues
  • the semantic challenge — programming languages
  • the logical challenge — specification logics
  • specialised quantifiers — a model-checking friendly logic

Dan R. Ghica, Compositional software model checking 1

slide-3
SLIDE 3

Program verification I — inferential

  • programming logics:

– Hoare logic; specification logic (Reynolds); dynamic logic (Harel)

  • common features:

– ‘exogenous’; compositional; sound; excruciating; – (partially) automated with proof checkers/assistants – can prove (partial) correctness; cannot find bugs

Dan R. Ghica, Compositional software model checking 2

slide-4
SLIDE 4

Program verification II — semantic

  • temporal logics (many)
  • common features:

– ‘endogenous’; non-compositional; unsound (‘semantic gap’); fun – algorithmic semantics – fully automated with model checkers (Slam, Bandera) – cannot prove correctness; can find bugs

Dan R. Ghica, Compositional software model checking 3

slide-5
SLIDE 5

Program verification desiderata

  • unify the two approaches: ‘compositional model checking’
  • inference rules

– correctness, compositionality

  • algorithmic semantics of program and logic

– automated model-checking, find counterexamples

  • fewer inferential steps

Dan R. Ghica, Compositional software model checking 4

slide-6
SLIDE 6

The semantic challenge

  • an algorithmic semantics of programming languages with

procedures

  • program (fragment) code ⇒ finite model
  • difficult problem

Dan R. Ghica, Compositional software model checking 5

slide-7
SLIDE 7

Games semantics

  • Hyland & Ong and (independently) Abramsky, Jagadeesan

& Malacaria and (independently) Nickau (93–94): Full abstraction for PCF

  • Abramsky & McCusker (96–97):

Full abstraction of Idealised Algol

  • many more important results followed

A complex combinatorial account of programming language se- mantics.

Dan R. Ghica, Compositional software model checking 6

slide-8
SLIDE 8

Regular-language semantics

Observation: for certain languages, if higher-order functions and recursion are omitted then much of the game-theoretic formal apparatus can be also omitted

  • second-order Idealised Algol can be modeled using regular

languages (Ghica & McCusker 2000)

  • second-order reduced ML can be modeled using regular lan-

guages (Ghica 01)

  • third-order Idealised Algol can be modeled using deterministic

context-free languages (Ong 02) A practicable algorithmic model.

Dan R. Ghica, Compositional software model checking 7

slide-9
SLIDE 9

The programming language IA

Data sets: booleans, bounded integers Ground types: variables, expressions, commands; Imperative features: assignment, branching, iteration, local variables; Functional features: first-order functions (uniformly on all types), call-by-name;

Dan R. Ghica, Compositional software model checking 8

slide-10
SLIDE 10

Semantic valuations

Γ ⊢ M:θ : Term → Regular Language

Helpful notation

Γ ⊢ E:int =

nq · Γ ⊢ E:intn · n

Γ ⊢ C:com = run · Γ ⊢ C:com · done Γ ⊢ V :var =

nread · Γ ⊢ V :varread n

· n +

nwrite(n) · Γ ⊢ V :varwrite n

· ok

Dan R. Ghica, Compositional software model checking 9

slide-11
SLIDE 11

RL interpretation

Language constants:

skip:com = run · done n:int = q · n loop:com = ∅

Imperative features:

C; C′ = C · C′ if B then C else C′ = B:booltt · C + B:boolff · C′ while B do C =

  • Btt · C

∗ · Bff

Dan R. Ghica, Compositional software model checking 10

slide-12
SLIDE 12

A simple example

Γ ⊢ while true do C ≡ loop

while true do C =

  • truett · C

∗ · trueff

=

  • ǫ · C

∗ · ∅

= ∅ = loop Because: truett = ǫ, trueff = ∅.

Dan R. Ghica, Compositional software model checking 11

slide-13
SLIDE 13

Free identifiers

c:com ⊢ c:com = run · runc · donec · done f:com → com ⊢ f:com → com

= run · runf · (runf1 · run1 · done1 · donef1)∗ · donef · done E.g.

f(skip) = run · runf · (runf1 · donef1)∗ · donef · done

Dan R. Ghica, Compositional software model checking 12

slide-14
SLIDE 14

Variables

Assignment:

V := E =

nEn · V write n

Dereferencing (reading):

!V : intn = V : varread

n

Obs: no causal relation between read and write actions:

let v be y :=!y + 1; y in · · ·

Dan R. Ghica, Compositional software model checking 13

slide-15
SLIDE 15

Local (block) variables

Only local variables are guaranteed to be well behaved: · · · writex(n) · okx · · · readx · nx · · · readx · nx · · · Interpretation of block variables:

Γ ⊢ int x in C =

  • Γ, x:var ⊢ C ∩

γx

  • ↾ Ax

Where γx =

  • n writex(n) · okx · (readx · nx)∗∗
  • Ax the alphabet of moves not tagged by x,

γx = γx ∐ (Ax)∗ (shuffle)

  • ↾ is restriction.

Dan R. Ghica, Compositional software model checking 14

slide-16
SLIDE 16

An example

c:com ⊢ int x in c ≡ c First proved using possible-worlds-style functor categories.

c:com ⊢ int x in c =

  • c:com, x:var ⊢ c ∩

γx

  • ↾ Ax

=

  • runc · donec ∩

γx

  • ↾ Ax

= runc · donec = c:com ⊢ c

Dan R. Ghica, Compositional software model checking 15

slide-17
SLIDE 17

The semantic gap is bridged.

  • algorithmic regular-language based model
  • sound and complete (fully abstract)
  • decidable (for most properties)

Dan R. Ghica, Compositional software model checking 16

slide-18
SLIDE 18

And now for something completely different... ...specification logic.

Dan R. Ghica, Compositional software model checking 17

slide-19
SLIDE 19

Common specification idiom

In Hoare-logic {P} C {Q} In (Reynolds) spec. logic, with non-local procedures ∀p : σ • Sproc(p) → Sprog(p) E.g. ∀c : comm • {v = v0} c {v = v0 + 1} → {v = z} c; c {v = z + 2}

Dan R. Ghica, Compositional software model checking 18

slide-20
SLIDE 20

A problem

Specification logic is undecidable

  • boolean, recursion-free, first-order fragment

Questionable suitability for model checking

Dan R. Ghica, Compositional software model checking 19

slide-21
SLIDE 21

Equational theory of IA is undecidable

φ ::= ∀x : σ.φ | ∃x : σ.φ | φ ∧ φ | φ ∨ φ | φ → φ | ¬φ | M ≡ N We can encode polynomials: − : N[X] → IA.

X = x : comm → comm 0 = λc.skip succ(n) = λc.(n)c; c m + n = λc.(n)c; (m)c m × n = λc.(n)((m)c)

Dan R. Ghica, Compositional software model checking 20

slide-22
SLIDE 22

Equational theory of IA is undecidable (cont’d)

Hilbert’s 10th problem corresponds to proving ∃ x : comm → comm.P1 ≡ P2, Pi ∈ N[X].

  • Spec. logic of IA is also undecidable
  • ∀p:assert.{true} c1 {p} ↔ {true} c2 {p}
  • ↔ c1 ≡ c2.

Dan R. Ghica, Compositional software model checking 21

slide-23
SLIDE 23

A solution

Common idiom: ∀p : σ • Sproc(p) → Sprog(p) Relativised quantifiers (syntactic): ∀p : Sproc • Sprog(p) Specialised quantifiers (semantic): Ψp : Sproc • Sprog(p)

Dan R. Ghica, Compositional software model checking 22

slide-24
SLIDE 24

Example: “effects quantifier”

Ψc : {v = v0} c {v = v0 + 1}

  • Sproc
  • {v = z} c; c {v = z + 2}
  • Sprog

All the variables above are global, distinct.

Dan R. Ghica, Compositional software model checking 23

slide-25
SLIDE 25

Another useful quantifier: “stability quantifier”

CBN+computational side-effects breaks arithmetic: x = x Context: let x be v := !v + 1; !v in · · · Obs: this is in general a difficult problem (Boehm 82) ∇x : σ.S E.g. ∇x : exp.x = x is always true. Semantics: similar to block variables (· · · ∩ γx

σ) ↾ Ax

Dan R. Ghica, Compositional software model checking 24

slide-26
SLIDE 26

A more generalised stability quantifier

∇x/ y : σ.S Interpretation: x is stable but the actions of identifiers in y may change its value. E.g. ∇y.∇x/y • x + x = 2 × x is true ∇y.∇x/y • x + y = y + x is not necessarily true

Dan R. Ghica, Compositional software model checking 25

slide-27
SLIDE 27

Our example, this time formally

∇v/c.Ψc : ∇v0.{v = v0} c {v = v0 + 1} • ∇z.{v = z} c; c {v = z + 2}

  • no need to restrict to global variables
  • more abstract formulations

∇e/c.Ψc : ∇e0.{e = e0} c {e = e0 + 1} • ∇z.{e = z} c; c {e = z + 2}

Dan R. Ghica, Compositional software model checking 26

slide-28
SLIDE 28

Why does it work? — a discussion

  • no true universal quantifier in the logic

– no quantification over languages – (no quantification over opponent behaviours)

  • specialised quantifiers are tamer

– regular-language interpretation – (encode a strategy for the opponent)

Dan R. Ghica, Compositional software model checking 27

slide-29
SLIDE 29

A bit of quantifier theory

introduced by Mostowski (57) and extended by Lindstroem (66); called “generalised” quantifiers; extend expressiveness without increasing order

  • “for uncountably many”
  • “for all connected graphs”

applications to descriptive complexity theory

Dan R. Ghica, Compositional software model checking 28

slide-30
SLIDE 30

What is a generalised quantifier?

any collection of structures closed under isomorphism type of a generalised quantifier (n1, n2, . . . , nk) ni identifiers are bound in the ith formula e.g. of type (1, 1) quantifier: Ψx, y : there are as many x with P(x) as there are y with Q(y) strict hierarchy (Hella et.al. 96) (1) < (1, 1) < · · · < (2) < (2, 1) < (2, 1, 1) · · · < (2, 2) < · · · < (3) · · ·

Dan R. Ghica, Compositional software model checking 29

slide-31
SLIDE 31

Proof theory of generalised quantifiers

substructural logics—substitution subject to extra conditions Ψ x1 : P1 . . . xk : Pk • S Pi( Mi) Mi # S, Mi # Mj, i = j S[ xi/ Mi] we call # non-interference work done by Alechina & Lambalgen (96)

Dan R. Ghica, Compositional software model checking 30

slide-32
SLIDE 32

Example

Ψc : {v = v0} c {v = v0 + 1} • {v = z} c; c {v = z + 2} {v = v0} v := v + 1 {v = v0 + 1} {v = z} v = v + 1; v = v + 1; {v = z + 2} Or Ψc : {v = v0} c {v = v0 + 1} • {v = z} c; c {v = z + 2} {v = v0} v := v + 1; k := k + 1 {v = v0 + 1} {v = z} v = v + 1; k := k + 1; v = v + 1; k := k + 1 {v = z + 2} But not Ψc : {v = v0} c {v = v0 + 1} • {v = z} c; c {v = z + 2} {v = v0} v := v + 1; z := z + 1 {v = v0 + 1} {v = z} v = v + 1; z := z + 1; v = v + 1; z := z + 1 {v = z + 2}

Dan R. Ghica, Compositional software model checking 31

slide-33
SLIDE 33

Non-interference

C # S C does not write to the ‘protected’ variables of S and vice versa.

Dan R. Ghica, Compositional software model checking 32

slide-34
SLIDE 34

Higher-type quantifiers and substitution

In the previous example we actually have a type (1,1) quantifier

  • ∇e/c

Ψc : ∇e0.{e = e0} c {e = e0 + 1}

  • ∇z.{e = z} c; c {e = z + 2}

Elimination must be simultaneous ∇v.∇(!v) ∇v.∇e0.{!v = e0} v := !v + 1 {!v = e0 + 1} ∇v.∇z.{!v = z} v := !v + 1; v := !v + 1 {!v = z + 2}

Dan R. Ghica, Compositional software model checking 33

slide-35
SLIDE 35

Highlights of the logical system

  • effects and stability quantifiers for ground and first order

types

  • quantifiers of type (1, 1, · · · , 1)
  • regular-language semantics, decidable
  • quantifiers discharged through substitution
  • also, Hoare axioms

Dan R. Ghica, Compositional software model checking 34

slide-36
SLIDE 36

Drawback

“algebraic” specifications involve quantifiers of higher type:

  

∇x/do, undo ∇y.{x = y} do; undo {x = y} ∇y.{x = y} undo; do {x = y}

   • · · · .

has type (1, 2), does not (?) have a RL semantics.

Dan R. Ghica, Compositional software model checking 35

slide-37
SLIDE 37

Conclusion

  • RL semantics, inference — compositional model checking
  • non-interference conditions — syntactic or semantic
  • challenging programming language — semantic and logic
  • not very complicated (?) — avoid “low level” axioms
  • some drawbacks
  • no verification tool yet

Dan R. Ghica, Compositional software model checking 36

slide-38
SLIDE 38

Related work

Interface automata, de Alfaro & Henzinger (2001)

  • emphasis on the automata model
  • the discharge of the interface — “refinement”

Dan R. Ghica, Compositional software model checking 37