Coinductive Program Verification Thesis Proposal Brandon Moore - - PowerPoint PPT Presentation

▶
coinductive program verification
SMART_READER_LITE
LIVE PREVIEW

Coinductive Program Verification Thesis Proposal Brandon Moore - - PowerPoint PPT Presentation

Dec 26, 2022 155 likes •1.16k views

Coinductive Program Verification Thesis Proposal Brandon Moore University of Illinois December 12, 2013 Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 1 / 58 Outline Introduction 1 Goals and

slide-1
SLIDE 1

Coinductive Program Verification

Thesis Proposal Brandon Moore

University of Illinois

December 12, 2013

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 1 / 58

slide-2
SLIDE 2

Outline

1

Introduction Goals and Motivation Operational Semantics Specifications as Reachability

2

Approach Reachability by Coinduction Coinduction with Derived Rules Higher-Order Specifications

3

Proposed Work Coinduction Principles Operational Semantics Automating Verification Validation

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 2 / 58

slide-3
SLIDE 3

Goal

Program Verification for every language

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 3 / 58

slide-4
SLIDE 4

Goal

Program Verification from (multi-step) Operational Semantics Always need executable semantics, to test formalization Can we avoid axiomatic semantics? Why operational?

◮ Denotational is a whole different story ◮ Don’t know how to handle big step Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 4 / 58

slide-5
SLIDE 5

Goal

Program Verification from (multi-step) Operational Semantics Always need executable semantics, to test formalization Can we avoid axiomatic semantics? Why operational?

◮ Denotational is a whole different story ◮ Don’t know how to handle big step Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 4 / 58

slide-6
SLIDE 6

Goal

Program Verification from (multi-step) Operational Semantics Always need executable semantics, to test formalization Can we avoid axiomatic semantics? Why operational?

◮ Denotational is a whole different story ◮ Don’t know how to handle big step Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 4 / 58

slide-7
SLIDE 7

Program verifiers should be at least certifying

Certifying

A certifying verifier produces a proof certificate along with claims

Certified

A certified verifier has a proof that it returns only true claims. Semantics in certificate language Translate specifications to claims about semantics Certificates are proofs claims are true Coq for certificate language, proof checker

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 5 / 58

slide-8
SLIDE 8

General Perspective

Language independence by passing from syntax to extension

◮ Semantics, specifications, proof principles, etc.

Truth/Proof as inclusion Coinduction

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 6 / 58

slide-9
SLIDE 9

Project Structure

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 7 / 58

slide-10
SLIDE 10

Operational semantics

Definition

An Operational Semantics is a set cfg of configurations and a one-step transition relation S⊆ cfg × cfg

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 8 / 58

slide-11
SLIDE 11

A simple imperative language

cfg = Stmt × (Var ⇀ Z), written code, store S contains steps like while(n!=0) {s=s+n; n=n-1}, {s→ 1,n→ 10} to s=s+n; n=n-1; while(n!=0) {s=s+n; n=n-1}, {s→ 1,n→ 10}

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 9 / 58

slide-12
SLIDE 12

Multiple Steps

Transitive closure S∗ takes multiple steps, e.g. while(n!=0) {s=s+n; n=n -1}; x=s, {s→ 1,n→ 10,x→ 0} to x = s, {s→ 56,n→ 10,x→ 1}

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 10 / 58

slide-13
SLIDE 13

Reachability

Definition

A configuration x ∈ cfg reaches a set P ⊆ cfg of configurations when x S∗ y for some y ∈ P, or x diverges in S

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 11 / 58

slide-14
SLIDE 14

Reachability in Pictures

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 12 / 58

slide-15
SLIDE 15

Reachability from Hoare Triples

Start with a standard Hoare Triple {s= s0,n= n0} while(n!=0) {s=s+n; n=n-1} {s= s0 + n0

i=0 i}

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 13 / 58

slide-16
SLIDE 16

Drop special syntax for variables

Ordinary predicates on store of configuration {store(s) = s0 ∧ store(n) = n0} while(n!=0) {s=s+n; n=n-1} {store(s) = s0 + n0

i=0 i}

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 14 / 58

slide-17
SLIDE 17

Drop special role of code

Ordinary predicates on configuration γ {γ.store(s) = s0 ∧ γ.store(n) = n0 ∧γ.code = while(n!=0) {s=s+n; n=n -1};R} {γ.store(s) = s0 + n0

i=0 i

∧γ.code = R}

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 15 / 58

slide-18
SLIDE 18

Matching Logic Reachability

Spec became a matching logic reachability property: ϕ ⇒RL ϕ′ (ϕ, ϕ′ predicates on cfg)

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 16 / 58

slide-19
SLIDE 19

Back to Basic Reachability

Expands to reachability claims ϕ ⇒RL ϕ′ iff ∀γ, ∀fv(ϕ), ϕ(γ) →

  • γ ⇒ {γ′ | ∃fv(ϕ′) \ fv(ϕ), ϕ′(γ′)}
  • Brandon Moore (University of Illinois)

Coinductive Program Verification December 12, 2013 17 / 58

slide-20
SLIDE 20

Approach

Specifications become sets of claims Proving sets of claims Coinduction Derived rules

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 18 / 58

slide-21
SLIDE 21

Truth as Set

Definition

Let claims = cfg ×P(cfg), naming the set of all reachability claims

Definition

Let reaches ⊆ claims be the set of true reachability claims, reaches = {(x, P) | x reaches P}

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 19 / 58

slide-22
SLIDE 22

Proof by Inclusion

x ⇒ P for all (x, P) ∈ R iff R ⊆ reaches

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 20 / 58

slide-23
SLIDE 23

Inclusion by Coinduction

Definition

Given set A and function F : P(A) → P(A), X ⊆ A is F-stable if X ⊆ F(X)

Coinduction

If G is the greatest fixpoint of a monotone F, X ⊆ F(X) implies X ⊆ G

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 21 / 58

slide-24
SLIDE 24

Reachability as a Fixpoint

reaches is the greatest fixpoint of step : P(claims) → P(claims) step[R] = done ∪ next[R] where done : P(claims), next : P(claims) → P(claims) done = {(x, P) | x ∈ P} next[R] = {(x, P) | ∃y.x S y ∧ (y, P) ∈ R}

(Proof) Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 22 / 58

slide-25
SLIDE 25

done in pictures

(a, P) ∈ done (b, P) ∈ done (c, P) ∈ done (d, P) ∈ done (a, Q) ∈ done (b, Q) ∈ done (c, Q) ∈ done (d, Q) ∈ done

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 23 / 58

slide-26
SLIDE 26

next in pictures

R

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 24 / 58

slide-27
SLIDE 27

next in pictures

next[R]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 24 / 58

slide-28
SLIDE 28

next in pictures

next[next[R]]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 24 / 58

slide-29
SLIDE 29

Reachability as a Fixpoint

reaches is the greatest fixpoint of step : P(claims) → P(claims) step[R] = done ∪ next[R] where done : P(claims), next : P(claims) → P(claims) done = {(x, P) | x ∈ P} next[R] = {(x, P) | ∃y.x S y ∧ (y, P) ∈ R}

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 25 / 58

slide-30
SLIDE 30

Direct coinduction 1

Goal: d ⇒ P

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 26 / 58

slide-31
SLIDE 31

Direct coinduction 1

Expand to stable set R

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 26 / 58

slide-32
SLIDE 32

Direct coinduction 1

step[R]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 26 / 58

slide-33
SLIDE 33

Direct coinduction 1

(e, P) ∈ done ⊆ step[R]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 26 / 58

slide-34
SLIDE 34

Direct coinduction 1

(e, P) ∈ done ⊆ step[R]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 26 / 58

slide-35
SLIDE 35

Direct coinduction 1

(e, P) ∈ R → (d, P) ∈ next[R] ⊆ step[R]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 26 / 58

slide-36
SLIDE 36

Direct coinduction 1

(e, P) ∈ R → (d, P) ∈ next[R] ⊆ step[R]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 26 / 58

slide-37
SLIDE 37

Direct coinduction 2

Goal: a ⇒ P

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 27 / 58

slide-38
SLIDE 38

Direct coinduction 2

Expand to stable set R

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 27 / 58

slide-39
SLIDE 39

Direct coinduction 2

step[R]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 27 / 58

slide-40
SLIDE 40

Direct coinduction 2

(b, P) ∈ R → (a, P) ∈ next[R] ⊆ step[R]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 27 / 58

slide-41
SLIDE 41

Direct coinduction 2

(b, P) ∈ R → (a, P) ∈ next[R] ⊆ step[R]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 27 / 58

slide-42
SLIDE 42

Direct coinduction 2

(c, P) ∈ R → (b, P) ∈ next[R] ⊆ step[R]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 27 / 58

slide-43
SLIDE 43

Direct coinduction 2

(c, P) ∈ R → (b, P) ∈ next[R] ⊆ step[R]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 27 / 58

slide-44
SLIDE 44

Direct coinduction 2

(a, P) ∈ R → (c, P) ∈ next[R] ⊆ step[R]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 27 / 58

slide-45
SLIDE 45

Direct coinduction 2

(a, P) ∈ R → (c, P) ∈ next[R] ⊆ step[R]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 27 / 58

slide-46
SLIDE 46

Direction coinduction on a program

To prove while(n!=0) {n=n-1}, {n→ n0} ⇒ {skip, {n→ 0}} must also claim n=n-1; while(n!=0) {n=n-1}, {n→ n0} ⇒ {skip, {n→ 0}} and skip, {n→ 0} ⇒ {skip, {n→ 0}}

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 28 / 58

slide-47
SLIDE 47

Recovering Rules

Direct coinduction tedious Replacements for proof rules

◮ Transitivity, Weakening, Assertion, etc.

Combine freely

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 29 / 58

slide-48
SLIDE 48

Multi-step coinduction

Given R : P(claims), close under step by fixpoint

(construction)

µC.R ∪ step[C]

Definition

R : P(claims) is step-stable using multiple steps if R ⊆ step[µC.R ∪ step[C]]

Multi-step coinduction

If R : P(claims) has R ⊆ step[µC.R ∪ step[C]] then (µC.R ∪ step[C]) ⊆ step[µC.R ∪ step[C]] and thus R ⊆ (µC.R ∪ step[C]) ⊆ reaches

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 30 / 58

slide-49
SLIDE 49

Proving with multiple steps

Goal: R = {(a, P)}

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 31 / 58

slide-50
SLIDE 50

Proving with multiple steps

Closing: step[∅]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 31 / 58

slide-51
SLIDE 51

Proving with multiple steps

Closing: R ∪ step[∅]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 31 / 58

slide-52
SLIDE 52

Proving with multiple steps

Closing: step[R ∪ step[∅]]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 31 / 58

slide-53
SLIDE 53

Proving with multiple steps

Closing: R ∪ step[R ∪ step[∅]]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 31 / 58

slide-54
SLIDE 54

Proving with multiple steps

Closing: step[R ∪ step[R ∪ step[∅]]]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 31 / 58

slide-55
SLIDE 55

Proving with multiple steps

Closing: R ∪ step[R ∪ step[R ∪ step[∅]]]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 31 / 58

slide-56
SLIDE 56

Proving with multiple steps

Closed: µC.R ∪ step[C]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 31 / 58

slide-57
SLIDE 57

Proving with multiple steps

Final step: step[µC.R ∪ step[C]]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 31 / 58

slide-58
SLIDE 58

Proving with multiple steps

Supported: R ⊆ step[µC.R ∪ step[C]]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 31 / 58

slide-59
SLIDE 59

Reasoning forward

Goal: any R which includes (a, P)

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 32 / 58

slide-60
SLIDE 60

Reasoning forward

(a, P) ∈ step[µC.R ∪ step[C]]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 32 / 58

slide-61
SLIDE 61

Reasoning forward

(a, P) ∈ done ∪ next[µC.R ∪ step[C]]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 32 / 58

slide-62
SLIDE 62

Reasoning forward

(a, P) ∈ next[µC.R ∪ step[C]]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 32 / 58

slide-63
SLIDE 63

Reasoning forward

(b, P) ∈ µC.R ∪ step[C]∧a S b → (a, P) ∈ next[µC.R ∪ step[C]]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 32 / 58

slide-64
SLIDE 64

Reasoning forward

(b, P) ∈ µC.R ∪ step[C]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 32 / 58

slide-65
SLIDE 65

Reasoning forward

(b, P) ∈ R ∪ step[µC.R ∪ step[C]]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 32 / 58

slide-66
SLIDE 66

Reasoning forward

(b, P) ∈ step[µC.R ∪ step[C]]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 32 / 58

slide-67
SLIDE 67

Reasoning forward

(b, P) ∈ next[µC.R ∪ step[C]]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 32 / 58

slide-68
SLIDE 68

Reasoning forward

(c, P) ∈ µC.R ∪ step[C]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 32 / 58

slide-69
SLIDE 69

Reasoning forward

(c, P) ∈ R ∪ step[µC.R ∪ step[C]]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 32 / 58

slide-70
SLIDE 70

Reasoning forward

(c, P) ∈ next[µC.R ∪ step[C]]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 32 / 58

slide-71
SLIDE 71

Reasoning forward

(a, P) ∈ µC.R ∪ step[C]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 32 / 58

slide-72
SLIDE 72

Reasoning forward

(a, P) ∈ R ∪ step[µC.R ∪ step[C]]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 32 / 58

slide-73
SLIDE 73

Reasoning forward

(a, P) ∈ R

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 32 / 58

slide-74
SLIDE 74

Multi-step coinduction on a program

The set of claims while(n!=0) {n=n-1}, {n→ n0} ⇒ {skip, {n→ 0}} is step-stable with multiple sets.

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 33 / 58

slide-75
SLIDE 75

Transitivity

Want x ⇒ Q if x ⇒ P and y ⇒ Q for all y ∈ P. As a function trans : P(claims) → P(claims) trans[X] = {(x, Q) | ∃P.(x, P) ∈ X ∧ ∀y ∈ P.(y, Q) ∈ X} As before, given R : P(claims), close under step and trans by fixpoint µC.R ∪ step[C] ∪ trans[C]

Definition

R : P(claims) is step-stable using multiple steps and transitivity if R ⊆ step[µC.R ∪ step[C] ∪ trans[C]] Is this sound?

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 34 / 58

slide-76
SLIDE 76

General rules

In general, any monotone F : P(claims) → P(claims)) may be rules

Definition

Given monotone F : P(claims) → P(claims) and claims R : P(claims), define the closure derived : (P(claims) → P(claims)) × P(claims) → P(claims) derived[F, R] = µD.R ∪ step[D] ∪ F[D]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 35 / 58

slide-77
SLIDE 77

Proving with rules

Definition

For monotone F : P(claims) → P(claims)), a set R : P(claims) is step-stable using F if R ⊆ step[derived[F, R]]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 36 / 58

slide-78
SLIDE 78

Rule Validity

Definition

Monotone F : P(claims) → P(claims) is simply valid if for any X : P(claims), X ⊆ step[derived[F, X]] implies derived[F, X] ⊆ step[derived[F, X]]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 37 / 58

slide-79
SLIDE 79

Compositional Validity

Composition

Given functions F, G : P(claims) → P(claims), define composition by (F + G)[X] = F[X] ∪ G[X] Composition preserves monotonicity, but not simple validity: strengthen

Definition

F : P(claims) → P(claims) is compositionally valid if it is monotone and ∀X.F[step[X]] ⊆ step[derived[F, X]]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 38 / 58

slide-80
SLIDE 80

Validity and Compositionality of Compositional Validity

Validity Lemma

If F : P(claims) → P(claims) is compositionally valid and R ⊆ claims satisfies R ⊆ step[derived[F, R]] then R ⊆ derived[F, R] ⊆ step[derived[F, R]] ⊆ reaches

Compositionality Lemma

If F, G : P(claims) → P(claims) are both compositionally, then (F + G) is also compositionally valid

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 39 / 58

slide-81
SLIDE 81

Validity Example: trans

To show trans is compositionally valid, fix R ⊆ claims, assume (x, P) ∈ step[R] forally ∈ P.(y, Q) ∈ step[R] If x ∈ P then (x, Q) ∈ step[R] by second hypopthesis Else x S z with (z, P) ∈ R. Then (z, Q) ∈ trans[R ∪ step[R]], (x, Q) ∈ step[trans[R ∪ step[R]]]. In either case, (x, Q) ∈ step[derived[trans, X]]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 40 / 58

slide-82
SLIDE 82

Interlude: Combining Proofs

To show (prog ∪ library ∪ internals) ⊆ step[derived[(trans +weaken + F), (prog ∪ library ∪ internals)]] it suffices to show prog ⊆ step[derived[trans +F], prog ∪ library]] and library ∪ internals ⊆ step[derived[trans +weaken, library ∪ internals]]

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 41 / 58

slide-83
SLIDE 83

“Second-Order” Program

What about higher order programs? Consider add3(plus ,x,y,z) = plus(plus(x,y),z) Specified by ∀p. (∀a b E σ.E[p(a, b)], σ ⇒ {E[a + b], σ)} → ∀x y z E σ.E[add3(p, x, y, z)], σ ⇒ {E[x + y + z], σ}

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 42 / 58

slide-84
SLIDE 84

“Second-Order” Specification

First-order specifications became sets of claims. Now abstract over set of claims to consider true in premises. Specification becomes function Spec : P(claims) → P(claims) Spec[H] = {(E[add3(p, x, y, z)], σ, {E[x + y + z], σ}) | ∀a b E ′ σ′.(E ′[p(a, b)], σ′, {E ′[a + b)], σ′)}) ∈ H}

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 43 / 58

slide-85
SLIDE 85

“Second-Order” Proof

Functions from claims to claims used as derived rules, re-use validity condition. If F is compositionally valid, ∀X. Spec[step[X]] ⊆ step[derived[F + Spec, X]] implies F + Spec is compositionally valid

Lemma

If F + Spec and F are compositionally valid, Spec[reaches] ⊆ reaches

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 44 / 58

slide-86
SLIDE 86

Higher-Order properties

In general, may take and return higher-order functions. Simple types τ := N | τ → τ give a reachability property type(N, v) = v is a number type(A → B, v) = ∀a. type(A, a) → E[v(a)] ⇒ {E[r] | type(B, r)} Can’t translate to spec of form P(claims) → P(claims), monotoniticy ruined by positive and negative occurances of ⇒

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 45 / 58

slide-87
SLIDE 87

Mixed-Variance Predicates

Splitting argument suffices: type : P(claims) → P(claims) → bool type(N, v, Neg, Pos) = v is a scalar type(A → B,v, Neg, Pos) = ∀a.type(A, a, Pos, Neg) → (E[v(a)], {E[r] | type(B, r, Neg, Pos)}) ∈ Pos Is monotone in Pos, anti-monotone in Neg

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 46 / 58

slide-88
SLIDE 88

Higher-Order proof

A higher-order specification is function Spec : P(claims) → P(claims) → P(claims) which is anti-monotone in the first argument and monotone in the second argument. Proved under rules F when ∀(Neg Pos : P(claims)) . step[derived[F, Spec[Neg, Pos]]] ⊆ Neg → Pos ⊆ step[derived[F, Spec[Neg, Pos]]] → Spec[Neg, Pos] ⊆ step[Spec[Neg, Pos]] When Spec proved under F and rules F valid, there exist some N, P ⊆ claims such that Spec[N, P] ⊆ reaches

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 47 / 58

slide-89
SLIDE 89

Project Structure

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 48 / 58

slide-90
SLIDE 90

Coinduction Principles

Formalize in Coq Publish Basic Theory

◮ Submit to LICS 2014, mid January, with MatchC examples.

Analyze derived rule conditions Develop higher-order case

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 49 / 58

slide-91
SLIDE 91

Operational Semantics

Handwritten semantics to start Generate from K definitions

◮ Reuse predicates, semantic domains from handwritten semantics.

Try existing Coq semantics, e.g. OTT

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 50 / 58

slide-92
SLIDE 92

Operational Semantics - Claims

Also need claims Begin writing by hand Extend K translator for annotations Abbreviations as needed

◮ Filling code component by embedding annotations in program ◮ Hoare style variable lookup abbreviation? ◮ Automatic threading of mixed-variance predicates? Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 51 / 58

slide-93
SLIDE 93

Automating Verification

Two major sorts of automation Order for applying proof rules

◮ MatchC successful with simple tactic: try in order to 1

Finish

2

Apply claim from specification

3

Take a step in semantics

4

Make a case split to enable above (generate tactic by analyzing semantics?)

◮ May replay trace from K reachability prover.

Folding, unfolding, simplifying predicates of specification

◮ Pure single-state domain reasoning, should be able to borrow Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 52 / 58

slide-94
SLIDE 94

Validating Power

Prove properties handled by MatchC (trees, Schorr-Waite) Bedrock (allocator, cooperative threads) FLINT (self-modifying code, interrupts)

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 53 / 58

slide-95
SLIDE 95

Validating Automation

After power, look at proof effort Bedrock Boogie Why

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 54 / 58

slide-96
SLIDE 96

Validating Adequacy

Proofs sound with respect to Coq semantics, may not match K interpreter Match exection of K tests Generate executable semantics, extract interpreter Formalize K, translate by deep embedding

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 55 / 58

slide-97
SLIDE 97

End

Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 56 / 58

slide-98
SLIDE 98

Reachability is Greatest Fixpoint

fixed

If x diverges, it has an immediate successor y which also diverges. If x S∗ z for some z ∈ P, then either x ∈ P already or x has an immediate successor y with y S∗ z as well, so reaches = step[reaches].

greatest

Suppose X ⊆ step[X], and (x, P) is a claim in X. Consider whether x

  • diverges. If so, (x, P) ∈ reaches. If x terminates, S is well-founded under x,

so by induction assume any claim (y, P) in X with x S+ y is also in reaches. As X is step-stable, either x ∈ P already, or x has some successor y with (y, P) ∈ X. In either case, (x, P) ∈ reaches.

Back Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 57 / 58

slide-99
SLIDE 99

ω not always enough

The least fixpoint is not necessarily reached by iterating a countable number

  • f times from ∅. The set of states which terminate along all paths is the

least fixpoint of F[S] = {x | ∀y.x S y → y ∈ S} but ∪∞

i=0F i[∅]

misses programs such as the one that picks any natural number, and then runs for that many more steps. It’s found in the next step: F[∪∞

i=0F i[∅]]

i.e, transfinite induction up to ω + 1. Higher ordinals can be required.

Back Brandon Moore (University of Illinois) Coinductive Program Verification December 12, 2013 58 / 58