oracle semantics n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Oracle Semantics PowerPoint Presentation
Download Presentation
Oracle Semantics

Loading in 2 Seconds...

play fullscreen
1 / 80

Oracle Semantics - PowerPoint PPT Presentation


  • 64 Views
  • Uploaded on

Oracle Semantics. Aquinas Hobor. Lipton, Perlis, DeMillo   1977. Why Proofs about Code are Hard. Math proofs tend to have the form If A, then B. Lipton, Perlis, DeMillo   1977. Why Proofs about Code are Hard. Math proofs tend to have the form If A, then B

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Oracle Semantics' - taran


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
oracle semantics

Oracle Semantics

Aquinas Hobor

why proofs about code are hard

Lipton, Perlis, DeMillo  1977

Why Proofs about Code are Hard

Math proofs tend to have the form

If A, then B

why proofs about code are hard1

Lipton, Perlis, DeMillo  1977

Why Proofs about Code are Hard

Math proofs tend to have the form

If A, then B

Proofs about real programs have the form

If A1 and A2 and A3 and A4 and A5…

why proofs about code are hard2

Lipton, Perlis, DeMillo  1977

Why Proofs about Code are Hard

Math proofs tend to have the form

If A, then B

Proofs about real programs have the form

If A1 and A2 and A3 and A4 and A5, then

B1 and B2 and B3

why proofs about code are hard3

Lipton, Perlis, DeMillo  1977

Why Proofs about Code are Hard

Math proofs tend to have the form

If A, then B

Proofs about real programs have the form

If A1 and A2 and A3 and A4 and A5, then

B1 and B2 and B3, except when

C1 or C2 or C3 or C4

why proofs about code are hard4

Lipton, Perlis, DeMillo  1977

Why Proofs about Code are Hard

Math proofs tend to have the form

If A, then B

Proofs about real programs have the form

If A1 and A2 and A3 and A4 and A5, then

B1 and B2 and B3, except when

C1 or C2 or C3 or C4, assuming

D1 and (D2 or D3)

why proofs about code are hard5
Why Proofs about Code are Hard

Two choices:

A) Prove something on paper about a simplification of the core ideas / algorithm

Problem: actual implementation will have bugs

B) Prove something about the actual code

Problem: too hard to do by hand

machine checked proofs
Machine-Checked Proofs

Solution:

Use computer to check your proofs (we use Coq)

Ideally the computer can help prove as well

Issue:

Machine-checked proofs are large and very time-consuming to write

Proof engineering becomes a real issue

goal for oracle semantics
Goal for Oracle Semantics

We want to add concurrency to large, realistic

systems in a provably correct, modular way

Those systems may already exist in a sequential

form; we would like to re-use existing code and

machine-checked proofs wherever possible

The key is to isolate the sequential and concurrent

reasoning from each other.

slide10

Leroy, 2006

CompCert Project

Sequential

Source Program

(C minor)

Sequential C minor

Operational Semantics

Compiler Correctness Proof

CompCert

Compiler

Sequential PowerPC

Operational Semantics

Sequential

Target Program

(Power PC)

Sequential

Translation Correctness Guarantee

User

Leroy

slide11

Leroy, 2006

CompCert Project

Sequential

Source Program

(C minor)

Sequential C minor

Operational Semantics

What is relationship here?

Compiler Correctness Proof

CompCert

Compiler

Sequential PowerPC

Operational Semantics

Sequential

Target Program

(Power PC)

Sequential

Translation Correctness Guarantee

User

Leroy

slide12

Appel & Blazy, 2007

  • Separation Logic for C minor

Sequential

Source Program

(C minor)

Axiomatic Semantics

(Separation Logic)

Sequential C minor

Operational Semantics

Program

Verification

Soundness

Proof

Compiler Correctness Proof

CompCert

Compiler

Sequential PowerPC

Operational Semantics

Sequential

Target Program

(Power PC)

Sequential

Translation Correctness Guarantee

User

Leroy

Appel & Blazy

slide13

Changes Required for Concurrency

Concurrent

Source Program

(C minor)

Axiomatic Semantics

(Concurrent

Separation Logic)

Concurrent C minor

Operational Semantics

Program

Verification

Soundness

Proof

Concurrency-Aware

Compiler Correctness Proof

Concurrency-Aware

CompCert

Compiler

Concurrent PowerPC

Operational Semantics

Concurrent

Target Program

(Power PC)

Concurrent

Translation Correctness Guarantee

User

Future Work

This work (Hobor, Appel, & Zappa Nardelli)

what this would mean
What this would mean

We would have machine-checked end-to-end

correctness proofs of concurrent programs

Since everything would be machine-checked, we

would have very high assurance that the actual

code running on the hardware had the correct,

expected behavior.

slide15

Changes Required for Concurrency

Concurrent

Source Program

(C minor)

Axiomatic Semantics

(Concurrent

Separation Logic)

Concurrent C minor

Operational Semantics

Program

Verification

Soundness

Proof

Concurrency-Aware

Compiler Correctness Proof

Concurrency-Aware

CompCert

Compiler

Concurrent PowerPC

Operational Semantics

Concurrent

Target Program

(Power PC)

Concurrent

Translation Correctness Guarantee

User

Future Work

This work (Hobor, Appel, & Zappa Nardelli)

additions to c minor language
Additions to C minor language

We add five new statements:

lock elock a lock

unlock eunlock a lock

makelocke Rturn an address into a lock

freelockerestore an address

fork e el start a new thread

additions to c minor language1
Additions to C minor language

We add five new statements:

lock elock a lock

unlock eunlock a lock

makelocke R turn an address into a lock

freelockerestore an address

fork e el start a new thread

Resource Invariant – Describes what resources a thread

acquires on lock and relinquishes on unlock

example program
Example Program

[l] := 0;

makelock l (∃y. x↦y+y);

[x] := 0;

unlock l;

fork child(l);

lock l;

[x] := [x] + 1;

[x] := [x] + 1;

unlock l;

modularity principle
Modularity Principle

Sequential Features

Concurrent Features

s1 ; s2

if e then s1 else s2

while e do s

break n

(x1, …, xn) := e (e1, …, em)

return (e1, …, en)

x := e

[e1] := e2

Skip

lock e

unlock e

fork e (e1, …, en)

makelock e R

freelock e

modularity principle1
Modularity Principle

Sequential Features

Concurrent Features

s1 ; s2

if e then s1 else s2

while e do s

break n

(x1, …, xn) := e (e1, …, em)

return (e1, …, en)

x := e

[e1] := e2

Skip

lock e

unlock e

fork e (e1, …, en)

makelock e R

freelock e

Connection Easy – Just Syntax

slide21

Changes Required for Concurrency

Concurrent

Source Program

(C minor)

Axiomatic Semantics

(Concurrent

Separation Logic)

Concurrent C minor

Operational Semantics

Program

Verification

Soundness

Proof

Concurrency-Aware

Compiler Correctness Proof

Concurrency-Aware

CompCert

Compiler

Concurrent PowerPC

Operational Semantics

Concurrent

Target Program

(Power PC)

Concurrent

Translation Correctness Guarantee

User

Future Work

This work (Hobor, Appel, & Zappa Nardelli)

modularity principle2
Modularity Principle

Sequential Reasoning

Concurrent Reasoning

Sequential Separation Logic Soundness

Sequential Compiler Correctness

Type Systems

Concurrent Separation Logic Soundness

Concurrent Compiler Correctness

Synchronization

modularity principle3
Modularity Principle

Sequential Reasoning

Concurrent Reasoning

Sequential Separation Logic Soundness

Sequential Compiler Correctness

Type Systems

Concurrent Separation Logic Soundness

Concurrent Compiler Correctness

Synchronization

Insert Magic Here

how is it done
How is it done?

Key: only consider well-synchronized programs

  • Mutual exclusion via Dijkstra Semaphores
  • Data-race free

Our operational semantics gets stuck on

ill-synchronized programs

changes to pure sequential semantics
Changes to Pure Sequential Semantics

C minor small-step sequential semantics

step relation: (1, 1) ↦ (2, 2)

 = (ρ, m)

 is a control stack

Resource map-aware C minor sequential semantics

step relation: (1, 1) ↦ (2, 2)

 = (ρ, , m)

 is a map from addresses to resources

resources
Resources

Basic resources:

| NONE

| VAL (data)

| LOCK of invariant (invariant comes from makelock)

Get stuck if you use memory without ownership

Thread resource maps are disjoint – at any time, only one

thread can access each address

Sequential instructions and proofs ignore LOCK

concurrent operational semantics
Concurrent Operational Semantics

Concurrent C minor step relation

(1, K1, m1, G1) ⇒ (2, K2, m2, G2)

 is scheduler

K is thread list (ρ1, 1, 1) :: (ρ2, 2, 2) :: …

m is memory

G is global resource map – owner of unlocked locks

To execute a sequential instruction, use the resource

map-aware sequential step relation

concurrent instructions
Concurrent Instructions
  • The concurrent step executes concurrent instructions directly
    • Updates memory at the lock instruction
    • Maintains thread list
    • Transfers resources between threads and global pool
  • unlock: resources transferred to global pool
  • lock: resources transferred from global pool
space
Space

Thread A

Thread B

Global Resource Map

1

R

2

3

Time

Memory

unlock 𝓁

2

1

R

3

Memory

lock 𝓁

1

R

2

3

Memory

R is the unique resource map that satisfies l’’s lock invariant

avoiding race conditions in semantics
Avoiding Race Conditions in Semantics

(ρ, lock, m) ⊩l⇝ P (ρ, lock, m) ⊩ ⊳P

m(l) = 0 m’ = [l↦ 1] m

’ lock =  G lock = G’

Ki = (ρ, , (unlock l) • ) K’ = [i -> (ρ, ’, )] K

(i :: , K, m, G) ⇒ (, K’, m’, G’)

Does not prevent compilation!

Unlock

avoiding race conditions in semantics1
Avoiding Race Conditions in Semantics

(ρ, lock, m) ⊩l⇝ P (ρ, lock, m) ⊩ ⊳P

m(l) = 0 m’ = [l↦ 1] m

’ lock =  G lock = G’

Ki = (ρ, , (unlock l) • ) K’ = [i -> (ρ, ’, )] K

(i :: , K, m, G) ⇒ (, K’, m’, G’)

Does not prevent compilation!

Unlock

avoiding race conditions in semantics2
Avoiding Race Conditions in Semantics

(ρ, lock, m) ⊩l⇝ P (ρ, lock, m) ⊩ ⊳P

m(l) = 0 m’ = [l↦ 1] m

’ lock =  G lock = G’

Ki = (ρ, , (unlock l) • ) K’ = [i -> (ρ, ’, )] K

(i :: , K, m, G) ⇒ (, K’, m’, G’)

Does not prevent compilation!

Unlock

avoiding race conditions in semantics3
Avoiding Race Conditions in Semantics

(ρ, lock, m) ⊩l⇝ P (ρ, lock, m) ⊩ ⊳P

m(l) = 0 m’ = [l↦ 1] m

’ lock =  G lock = G’

Ki = (ρ, , (unlock l) • ) K’ = [i -> (ρ, ’, )] K

(i :: , K, m, G) ⇒ (, K’, m’, G’)

Does not prevent compilation!

Unlock

avoiding race conditions in semantics4
Avoiding Race Conditions in Semantics

(ρ, lock, m) ⊩l⇝ P (ρ, lock, m) ⊩ ⊳P

m(l) = 0 m’ = [l↦ 1] m

’ lock =  G lock = G’

Ki = (ρ, , (unlock l) • ) K’ = [i -> (ρ, ’, )] K

(i :: , K, m, G) ⇒ (, K’, m’, G’)

Operational semantics is nonconstructive!

Unlock

avoiding race conditions in semantics5
Avoiding Race Conditions in Semantics

(ρ, lock, m) ⊩l⇝ P (ρ, lock, m) ⊩ ⊳P

m(l) = 0 m’ = [l↦ 1] m

’ lock =  G lock = G’

Ki = (ρ, , (unlock l) • ) K’ = [i -> (ρ, ’, )] K

(i :: , K, m, G) ⇒ (, K’, m’, G’)

Operational semantics is nonconstructive!

Unlock

avoiding race conditions in semantics6
Avoiding Race Conditions in Semantics

(ρ, lock, m) ⊩l⇝ P (ρ, lock, m) ⊩ ⊳P

m(l) = 0 m’ = [l↦ 1] m

’ lock =  G lock = G’

Ki = (ρ, , (unlock l) • ) K’ = [i -> (ρ, ’, )] K

(i :: , K, m, G) ⇒ (, K’, m’, G’)

Does not prevent compilation!

Unlock

coroutine interleaving
Coroutine Interleaving

Executes sequentially without interleaving

Interleave when we get to concurrent operation

Key: we have well-synchronized programs

reasoning about concurrency
Reasoning About Concurrency

Most of the time, concurrent programs are

executing sequential code

Proofs about sequential features are hard enough

We don’t want to add the extra complexity of

concurrency when reasoning about sequential code

Idea: why can’t we just pretend it is sequential?

sequential reasoning
Sequential Reasoning

x := x + 1

[y] := 2

lock l

a := [x]

sequential reasoning1
Sequential Reasoning

(1, 1)

  • (2, 2)
  • (3, 3)

STUCK

x := x + 1

[y] := 2

lock l

a := [x]

oracular reasoning
Oracular Reasoning

(1, 1)

  • (2, 2)
  • (3, 3)

STUCK

(o1, 1, 1)

  • (o1, 2, 2)
  • (o1, 3, 3)
  • (o2, 4, 4)
  • (o2, 5, 5)

x := x + 1

[y] := 2

lock l

a := [x]

oracular composition
Oracular Composition

An oracle o is (, K, G)

 is the scheduler

K is the other threads

G is the global resource map

The oracle simulates running all of the other

threads until the scheduler returns control to

this thread

soundness of oracular reasoning
Soundness of Oracular Reasoning

Theorem (connection of oracle and concurrent semantics)

If a thread executes in a certain way on the oracular machine, then it executes in the same way when executing in the concurrent machine

slide44

Changes Required for Concurrency

Concurrent

Source Program

(C minor)

Axiomatic Semantics

(Concurrent

Separation Logic)

Concurrent C minor

Operational Semantics

Program

Verification

Soundness

Proof

Concurrency-Aware

Compiler Correctness Proof

Concurrency-Aware

CompCert

Compiler

Concurrent PowerPC

Operational Semantics

Concurrent

Target Program

(Power PC)

Concurrent

Translation Correctness Guarantee

User

Future Work

This work (Hobor, Appel, & Zappa Nardelli)

hoare logic

Floyd, Hoare

Hoare Logic

A Hoare triple is {precondition} command {postcondition}

Example: {x = 2} x++ {x = 3}

In our setting, the precondition and postcondition are

predicates on state (locals, memory, resource map, …)

In Coq: Definition predicate : Type := state -> Prop.

A Hoare logic is a set of axioms for deriving valid triples

Example: {P} c1 {Q} {Q} c2 {R}

{P} c1;c2 {R}

separation logic

Reynolds, O’Hearn

Separation Logic

Problem: handling pointers

Example: {x ↦ 0 ⋀ y ↦ 0} [x] := 1 {???}

{x ↦ 1 ⋀ y ↦ 0}

{x ↦ 1 ⋀ y ↦ 1}

Solution: Separation

Use “∗” to split propositions into two disjoint halves

Example: {x ↦ 0 ∗ y ↦ 0} [x] := 1 {x ↦ 1 ∗ y ↦ 0}

Enables more local reasoning for programs with pointers

Key rule (Frame): {P} c {Q}

{P ∗ F} c {Q ∗ F}

concurrent separation logic 2 0

CSL 1.0 by O’Hearn, 2006

Concurrent Separation Logic 2.0

Extension of separation logic to handle concurrency

Includes all of typical the rules of separation logic

Associate with each lock an invariant R

l⇝ R ≡ l is a lock with invariant R

Rules for concurrent operations

{l⇝ R} lock l {(l⇝ R) * R}

{(l⇝ R) * R} unlock l {l⇝ R}

Programs proved in CSL are well-synchronized!

Separation

Logic

Concurrent

Separation Logic

space1
Space

Thread A

Thread B

Thread C

FB

FA

𝓁⇝ R

R

Time

1

R

2

3

Memory

lock 𝓁

unlock 𝓁

FA

𝓁⇝ R

R

FB

1

R

2

3

Memory

{𝓁 ⇝ R} lock 𝓁 {(𝓁 ⇝ R) ∗ R}

{FA∗ (𝓁 ⇝ R)} lock 𝓁 {FA∗ (𝓁 ⇝ R) ∗ R}

(lock rule)

(frame rule)

slide49

Changes Required for Concurrency

Concurrent

Source Program

(C minor)

Axiomatic Semantics

(Concurrent

Separation Logic)

Concurrent C minor

Operational Semantics

Program

Verification

Soundness

Proof

Concurrency-Aware

Compiler Correctness Proof

Concurrency-Aware

CompCert

Compiler

Concurrent PowerPC

Operational Semantics

Concurrent

Target Program

(Power PC)

Concurrent

Translation Correctness Guarantee

User

Future Work

This work (Hobor, Appel, & Zappa Nardelli)

verification of example program
Verification of Example Program

[l] := 0;

makelock l (∃y. x↦y+y);

[x] := 0;

unlock l;

fork child(l);

lock l;

[x] := [x] + 1;

[x] := [x] + 1;

unlock l;

verification of example program1
Verification of Example Program

{F * l⇝ (∃y. x↦y+y)}

lock l;

{F * l⇝ (∃y. x↦y+y) * (∃y. x↦y+y)}

[x] := [x] + 1;

[x] := [x] + 1;

unlock l;

verification of example program2
Verification of Example Program

lock l;

{F * l⇝ (∃y. x↦y+y) * (∃y. x↦y+y)}

[x] := [x] + 1;

{F * l⇝ (∃y. x↦y+y) * (∃y. x↦y+y + 1)}

[x] := [x] + 1;

unlock l;

verification of example program3
Verification of Example Program

lock l;

[x] := [x] + 1;

{F * l⇝ (∃y. x↦y+y) * (∃y. x↦y+y + 1)}

[x] := [x] + 1;

{F * l⇝ (∃y. x↦y+y) * (∃y. x↦y+y + 2)}

unlock l;

verification of example program4
Verification of Example Program

lock l;

[x] := [x] + 1;

{F * l⇝ (∃y. x↦y+y) * (∃y. x↦y+y + 1)}

[x] := [x] + 1;

{F * l⇝ (∃y. x↦y+y) * (∃y. x↦y+y + 2)}

unlock l;

(∃y. x↦y+y)

verification of example program5
Verification of Example Program

lock l;

[x] := [x] + 1;

{F * l⇝ (∃y. x↦y+y) * (∃y. x↦y+y + 1)}

[x] := [x] + 1;

{F * l⇝ (∃y. x↦y+y) * (∃y. x↦y+y)}

unlock l;

verification of example program6
Verification of Example Program

lock l;

[x] := [x] + 1;

[x] := [x] + 1;

{F * l⇝ (∃y. x↦y+y) * (∃y. x↦y+y)}

unlock l;

{F * l⇝ (∃y. x↦y+y)}

verification of example program7
Verification of Example Program

{F * l⇝ (∃y. x↦y+y)}

lock l;

{F * l⇝ (∃y. x↦y+y) * (∃y. x↦y+y)}

[x] := [x] + 1;

{F * l⇝ (∃y. x↦y+y) * (∃y. x↦y+y + 1)}

[x] := [x] + 1;

{F * l⇝ (∃y. x↦y+y) * (∃y. x↦y+y + 2)}

{F * l⇝ (∃y. x↦y+y) * (∃y. x↦y+y)}

unlock l;

{F * l⇝ (∃y. x↦y+y)}

verification of example program8
Verification of Example Program

{x↦ _ * l↦ _}

[l] := 0;

{x↦ _ * l↦ 0}

makelock l (∃y. x↦y+y);

{x↦ _ * l⇝ (∃y. x↦y+y)}

[x] := 0;

{x↦ 0 * l⇝ (∃y. x↦y+y)}

{x↦ (∃y. x↦y+y) * l⇝ (∃y. x↦y+y)}

unlock l;

{l⇝ (∃y. x↦y+y)}

fork child(l);

{l⇝ (∃y. x↦y+y)}

lock l;

{l⇝ (∃y. x↦y+y) * (∃y. x↦y+y)}

[x] := [x] + 1;

{l⇝ (∃y. x↦y+y) * (∃y. x↦y+y + 1)}

[x] := [x] + 1;

{l⇝ (∃y. x↦y+y) * (∃y. x↦y+y + 2)}

{l⇝ (∃y. x↦y+y) * (∃y. x↦y+y)}

unlock l;

{l⇝ (∃y. x↦y+y)}

lessons
Lessons

{x↦ _ * l↦ _}

[l] := 0;

{x↦ _ * l↦ 0}

makelock l (∃y. x↦y+y);

{x↦ _ * l⇝ (∃y. x↦y+y)}

[x] := 0;

{x↦ 0 * l⇝ (∃y. x↦y+y)}

{x↦ (∃y. x↦y+y) * l⇝ (∃y. x↦y+y)}

unlock l;

{l⇝ (∃y. x↦y+y)}

fork child(l);

{l⇝ (∃y. x↦y+y)}

lock l;

{l⇝ (∃y. x↦y+y) * (∃y. x↦y+y)}

[x] := [x] + 1;

{l⇝ (∃y. x↦y+y) * (∃y. x↦y+y + 1)}

[x] := [x] + 1;

{l⇝ (∃y. x↦y+y) * (∃y. x↦y+y + 2)}

{l⇝ (∃y. x↦y+y) * (∃y. x↦y+y)}

unlock l;

{l⇝ (∃y. x↦y+y)}

  • Many details!

(Actually, some omitted!)

  • Machine-checking is key
  • Has been done for larger example programs (in Coq)
  • Machine-generation would be very helpful
slide60

Changes Required for Concurrency

Concurrent

Source Program

(C minor)

Axiomatic Semantics

(Concurrent

Separation Logic)

Concurrent C minor

Operational Semantics

Program

Verification

Soundness

Proof

Concurrency-Aware

Compiler Correctness Proof

Concurrency-Aware

CompCert

Compiler

Concurrent PowerPC

Operational Semantics

Concurrent

Target Program

(Power PC)

Concurrent

Translation Correctness Guarantee

User

Future Work

This work (Hobor, Appel, & Zappa Nardelli)

difficulties in modeling
Difficulties in modeling

lock

even

lock

even

123

100

124

101

Invariants need to be able to refer to other invariants

  • Example: 50 ⇝∃l2. ((51 ↦ l2) ∗ (l2⇝ (∃x.l2+1 ↦ 2*x)
difficulties in modeling1
Difficulties in modeling

lock

pointer

lock

even

lock

even

123

100

50

124

51

101

Invariants need to be able to refer to other invariants

  • Example: 50 ⇝∃l2. ((51 ↦ l2) ∗ (l2⇝ (∃x.l2+1 ↦ 2*x)))

Nested Invariants are Difficult to Model

a modal substructural logic
A modal substructural logic

When a logical proposition describes when and where

another logical proposition holds, we have a modal logic

To describe approximation use the modal operator later “⊳”

⊳P means P will hold at all greater approximations; maybe not now

Key: Avoids circularity and gives clean induction principle

To describe space use ∗ and the operator fashionably “◯”

P * Q means P and Q hold on disjoint sub resource maps

◯ P means that P holds on all resource maps of equal approximation

a semantic model

Appel, Melliès, Richards, & Vouillon ‘07

A semantic model

To build a semantic model of the modal logic, we will

build on the “very modal model” of Appel, Melliès,

Richards, & Vouillon

Unlike in that work, where it was sufficient to have only

modal relationships, we also need to spatial properties

In general, we find that semantic models (as opposed

to syntactic techniques) scale better in large systems

shallow embedding
Shallow Embedding

Invariants are semantic and shallowly embedded in Coq

The shallow embedding means that our invariants are easy to

use and reason about in Coq

We use the same tactics at both the Coq-level and the invariant-level reasoning

We avoid messy reasoning about binders (that is, the POPLmark challenge quagmire)

This significantly simplifies the engineering work

another modeling difficulty
Another modeling difficulty

We want to embed our semantic assertions directly in

program syntax (for makelock)

Thus, the definitions for program syntax depend on the

definition of predicate

On the other hand, we want to allow a predicate to be

able to specify a function (i.e. f : {P} {Q})

But a this is a predicate about function behavior…

which of course is defined using program syntax

a modal definition of a hoare triple
A modal definition of a Hoare triple

The solution:

Define our Hoare triple using our modal logic

Thus, a Hoare triple becomes a predicate on state

just like any other predicate

Hypothesis: this will allow us to verify self-

modifying code, such as a JIT

just a little bit tricky
(Just a little bit tricky…)

Record semaxArg :Type := SemaxArg {

sa_G: predicate;

sa_R: list val -> predicate;

sa_B: nat -> predicate;

sa_P: predicate;

sa_c: stmt;

sa_Q: predicate

}.

Definition stackframe_of (f : function) : predicate :=

Assert.stackframe f.(fn_stackspace).

Definition prepost_match_sig (P Q : predicate) (sig: signature) : predicate :=

match sig with mksignatureargs ret =>

|> match_sig1 P args && |> match_sig1 Q ret

end.

Definition bind_args (ids: list ident) (P: predicate) : predicate :=

fun st => exists vl, exists locals,

list_norepet (locals ++ ids) /\ eqv_env (st_rhost) (set_locals locals (set_paramsvl ids))

/\ validate P (st_upd_rho (Assert.vl2env vl) st).

Definition claims psi (G P: predicate) : predicate :=

#!(in_prog psi && G --> TT * !(in_prog psi --> P)).

Parameter semax': predicate -> (list val -> predicate) -> (nat -> predicate) -> predicate -> stmt -> predicate -> predicate.

Definition semax G R B P c Q := forallst, semax' G R B P c Q st.

Definition fun_id (id: ident) (sh: Share.t) (A: Type) (P Q : A -> predicate) : predicate :=

Exists vf, global_id id =# vf ** Assert.fun_assertvfsh A P Q.

Definition believe (psi: genv) (G G': predicate) : predicate :=

All_ id: ident, All_ sh: Share.t, All_ A: Type, All_ P: A -> predicate, All_ Q: A -> predicate,

(claims psi G' (fun_id id sh A P Q)) >=>

Ex_ b: block, Ex_ f: function,

prop (Genv.find_symbol psi id = Some b /\ Genv.find_funct_ptr psi b = Some (Internal f)

/\ list_norepet (f.(fn_vars) ++ f.(fn_params)))

&& All_ x : A,

prepost_match_sig (P x) (Q x) f.(fn_sig)

&& |> semax' G (fun vl => Assert.apply (Q x) vl ** stackframe_of f) Assert.assert_env_nil

(bind_args f.(fn_params) (P x) ** stackframe_of f)

f.(fn_body) FF.

Definition program_ok psi G := believe psi ([^]G) ([^]G).

Axiom semax_fold_unfold:

semax' = fun G R B P c Q =>

All_ psi: genv, program_ok psi G -->

All_ k: control, All_ F: predicate,

rguard psi (gframe G F c) R k -->

bguard psi (gframe G F c) B k -->

guard psi (gframe G F c) Q k -->

guard psi (gframe G F c) P (Kseq c k).

proving the rules of csl
Proving the Rules of CSL

Key: Prove relative to the Oracle Step

Axioms of sequential separation logic are

proved by machine checked proofs of

Appel & Blazy with only minor modification

The additional axioms added by Concurrent

Separation Logic are able to ignore the

difficulties of sequential control flow and focus

on the truly concurrent behavior

Separation Logic

Appel & Blazy

Concurrent

Separation Logic

Hobor, Appel,

Zappa Nardelli

status of machine checked proofs
Status of Machine Checked Proofs

“As expected, it took longer than expected”

- Hobor, Appel, Zappa Nardelli

About 62k lines of proof script at the moment

“Building such scripts is surprisingly addictive, in

a videogame kind of way…”

- Xavier Leroy

status of machine checked proofs1
Status of Machine Checked Proofs

Definition of the Concurrent Machine

Definition of the Oracular Machine

Definition of Hoare Tuple

Sequential Separation Logic Rules

Concurrent S.L. Rules

Oracular Soundness

Done

Done

Done

Done

95% Done (Unlock)

90% Done (Fork)

slide72

Future Work

Concurrent

Source Program

(C minor)

Axiomatic Semantics

(Concurrent

Separation Logic)

Concurrent C minor

Operational Semantics

Program

Verification

Soundness

Proof

Concurrency-Aware

Compiler Correctness Proof

Concurrency-Aware

CompCert

Compiler

Concurrent PowerPC

Operational Semantics

Concurrent

Target Program

(Power PC)

Concurrent

Translation Correctness Guarantee

User

Future Work

This work (Hobor, Appel, & Zappa Nardelli)

key for compiler modification
Key For Compiler Modification

Lock predicates only look at memory and resource map

The CompCert compiler is designed so that at

each intermediate level, memory is preserved

Thus, the compiler does not have to modify – or

even understand – the predicates embedded in

the makelock statement

slide74

Future Work

Concurrent

Source Program

(C minor)

Axiomatic Semantics

(Concurrent

Separation Logic)

Concurrent C minor

Operational Semantics

Program

Verification

Soundness

Proof

Concurrency-Aware

Compiler Correctness Proof

Concurrency-Aware

CompCert

Compiler

Concurrent PowerPC

Operational Semantics

Concurrent

Target Program

(Power PC)

Concurrent

Translation Correctness Guarantee

User

Future Work

This paper (Hobor, Appel, & Zappa Nardelli)

weak memory models
Weak Memory Models

Real processors do not have our interleaving model

Actually, they don’t interleave at all!

They execute instructions out-of-order, subject to various

kinds of ordering constraints

However, for well-synchronized programs, our simplified

interleaving model is sufficient

slide76

Future Work

Concurrent

Source Program

(C minor)

Axiomatic Semantics

(Concurrent

Separation Logic)

Concurrent C minor

Operational Semantics

Program

Verification

Soundness

Proof

Concurrency-Aware

Compiler Correctness Proof

Concurrency-Aware

CompCert

Compiler

Concurrent PowerPC

Operational Semantics

Concurrent

Target Program

(Power PC)

Concurrent

Translation Correctness Guarantee

User

Future Work

This paper (Hobor, Appel, & Zappa Nardelli)

papers and related work
Papers and Related Work

Design and Soundness for Concurrent Separation Logic

Resources, Concurrency, and Local Reasoning

Peter O’Hearn, TCS 375, pp271-307, May 2007

A Semantics for Concurrent Separation Logic

Stephen Brookes, TCS 375, pp227-270, May 2007

Oracle Semantics for Concurrent SeparationLogic

Aquinas Hobor, Andrew W. Appel, Francesco Zappa Nardelli

ESOP 2008, pages 353-367

Local reasoning for storable locks and threads

Alexey Gotsman, Josh Berdine, Byron Cook, Noam Rinetzky, and MoolySagiv

APLAS'07, pages 19-37

papers and related work1
Papers and Related Work

Semantic Models & Multimodal Logics

A Very Modal Model of a Modern, Major, General Type System

Andrew W. Appel, Paul-Andre Mellies, Christopher Richards, and Jerome Vouillon

POPL 2007

Multimodal Separation Logic for Reasoning About Operational Semantics

Robert Dockins, Andrew W. Appel, Aquinas Hobor

To appear in MFPS 2008

Comparing Semantic and Syntactic Methods in Mechanized Proof FrameworksC. J. Bell, Robert Dockins, Aquinas Hobor, Andrew W. Appel, David WalkerCurrently submitted for publication

papers and related work2
Papers and Related Work

Sequential Separation Logic

Separation Logic for Small-step C minor

Andrew W. Appel and Sandrine Blazy

TPHOLs 2007, pages 5-21

Automating Program Verification for CSL

Thread-modular shape analysis

Alexey Gotsman, Josh Berdine, Byron Cook, and MoolySagiv

PLDI'07, pages 266-277

Automating Separation Logic for Concurrent C minor

William Mansky

Princeton senior thesis, currently being written up for publication

slide80

Concurrent C minor Project

Concurrent

Source Program

(C minor)

Axiomatic Semantics

(Concurrent

Separation Logic)

Concurrent C minor

Operational Semantics

Program

Verification

Soundness

Proof

Concurrency-Aware

Compiler Correctness Proof

Concurrency-Aware

CompCert

Compiler

Concurrent PowerPC

Operational Semantics

Concurrent

Target Program

(Power PC)

Concurrent

Translation Correctness Guarantee

User

Future Work

This work (Hobor, Appel, & Zappa Nardelli)