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

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 — specification logics • specialised quantifiers — a model-checking friendly logic Dan R. Ghica, Compositional software model checking 1

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

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

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

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

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

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

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

Semantic valuations � Γ ⊢ M : θ � : Term → Regular Language Helpful notation � Γ ⊢ E : int � = � n q · � Γ ⊢ E : int � n · n � Γ ⊢ C : com � = run · � Γ ⊢ C : com � · done � Γ ⊢ V : var � = � n read · � Γ ⊢ V : var � read · n n + � n write ( n ) · � Γ ⊢ V : var � write · ok n Dan R. Ghica, Compositional software model checking 9

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 : bool � tt · � C � + � B : bool � ff · � C ′ � � � ∗ · � B � ff � while B do C � = � B � tt · � C � Dan R. Ghica, Compositional software model checking 10

A simple example Γ ⊢ while true do C ≡ loop � � ∗ · � true � ff � while true do C � = � true � tt · � C � � � ∗ · ∅ = ǫ · � C � = ∅ = � loop � Because: � true � tt = ǫ, � true � ff = ∅ . Dan R. Ghica, Compositional software model checking 11

Free identifiers � c : com ⊢ c : com � = run · run c · done c · done � f : com → com ⊢ f : com → com � = run · run f · ( run f 1 · run 1 · done 1 · done f 1 ) ∗ · done f · done E.g. � f ( skip ) � = run · run f · ( run f 1 · done f 1 ) ∗ · done f · done Dan R. Ghica, Compositional software model checking 12

Variables Assignment: � V := E � = � n � E � n · � V � write n Dereferencing (reading): � ! V : int � n = � V : var � read 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

Local (block) variables Only local variables are guaranteed to be well behaved: · · · write x ( n ) · ok x · · · read x · n x · · · read x · n x · · · Interpretation of block variables: � � ↾ A x � Γ , x : var ⊢ C � ∩ � γ x � Γ ⊢ int x in C � = �� n write x ( n ) · ok x · ( read x · n x ) ∗ � ∗ Where γ x = • A x the alphabet of moves not tagged by x , γ x = γ x ∐ ( A x ) ∗ • � (shuffle) • ↾ is restriction. Dan R. Ghica, Compositional software model checking 14

An example c : com ⊢ int x in c ≡ c First proved using possible-worlds-style functor categories. � � ↾ A x � c : com , x : var ⊢ c � ∩ � γ x � c : com ⊢ int x in c � = � � run c · done c ∩ � ↾ A x γ x = = run c · done c = � c : com ⊢ c � Dan R. Ghica, Compositional software model checking 15

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

And now for something completely different... ...specification logic. Dan R. Ghica, Compositional software model checking 17

Common specification idiom In Hoare-logic { P } C { Q } In (Reynolds) spec. logic, with non-local procedures ∀ p : σ • S proc ( p ) → S prog ( p ) E.g. ∀ c : comm • { v = v 0 } c { v = v 0 + 1 } → { v = z } c ; c { v = z + 2 } Dan R. Ghica, Compositional software model checking 18

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

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

Equational theory of IA is undecidable (cont’d) Hilbert’s 10th problem corresponds to proving ∃ � x : comm → comm . � P 1 � ≡ � P 2 � , P i ∈ N [ X ] . Spec. logic of IA is also undecidable � � ∀ p : assert . { true } c 1 { p } ↔ { true } c 2 { p } ↔ c 1 ≡ c 2 . Dan R. Ghica, Compositional software model checking 21

A solution Common idiom: ∀ p : σ • S proc ( p ) → S prog ( p ) Relativised quantifiers (syntactic): ∀ p : S proc • S prog ( p ) Specialised quantifiers (semantic): Ψ p : S proc • S prog ( p ) Dan R. Ghica, Compositional software model checking 22

Example: “effects quantifier” Ψ c : { v = v 0 } c { v = v 0 + 1 } • { v = z } c ; c { v = z + 2 } � �� � � �� � S proc S prog All the variables above are global, distinct. Dan R. Ghica, Compositional software model checking 23

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 σ ) ↾ A x Dan R. Ghica, Compositional software model checking 24

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

Our example, this time formally ∇ v/c. Ψ c : ∇ v 0 . { v = v 0 } c { v = v 0 + 1 } • ∇ z. { v = z } c ; c { v = z + 2 } • no need to restrict to global variables • more abstract formulations ∇ e/c. Ψ c : ∇ e 0 . { e = e 0 } c { e = e 0 + 1 } • ∇ z. { e = z } c ; c { e = z + 2 } Dan R. Ghica, Compositional software model checking 26

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

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