oracle semantics for concurrent separation logic
DESCRIPTION
Oracle Semantics for Concurrent Separation Logic. Aquinas Hobor Joint work with Andrew W. Appel & Francesco Zappa Nardelli. Why Proofs about Code are Hard. Math proofs tend to have the form If A, then B. Why Proofs about Code are Hard. Math proofs tend to have the form If A, then B - PowerPoint PPT PresentationTRANSCRIPT
Oracle Semantics for Concurrent Separation Logic
Aquinas Hobor
Joint work withAndrew W. Appel & Francesco Zappa Nardelli
2
Why Proofs about Code are Hard
Math proofs tend to have the formIf A, then B
3
Why Proofs about Code are Hard
Math proofs tend to have the formIf A, then B
Proofs about real programs have the formIf A1 and A2 and A3 and A4 and A5…
4
Why Proofs about Code are Hard
Math proofs tend to have the formIf A, then B
Proofs about real programs have the formIf A1 and A2 and A3 and A4 and A5, thenB1 and B2 and B3
5
Why Proofs about Code are Hard
Math proofs tend to have the formIf A, then B
Proofs about real programs have the formIf A1 and A2 and A3 and A4 and A5, thenB1 and B2 and B3, except whenC1 or C2 or C3 or C4
6
Why Proofs about Code are Hard
Math proofs tend to have the formIf A, then B
Proofs about real programs have the formIf A1 and A2 and A3 and A4 and A5, thenB1 and B2 and B3, except whenC1 or C2 or C3 or C4, assumingD1 and (D2 or D3)
7
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
8
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
9
Goal for Oracle Semantics
We want to add concurrency to large, realisticsystems in a provably correct, modular way
Those systems may already exist in a sequentialform; we would like to re-use existing code andmachine-checked proofs wherever possible
The key is to isolate the sequential and concurrentreasoning from each other.
Sequential C minorOperational Semantics
10
Sequential PowerPCOperational Semantics
SequentialTarget Program
(Power PC)
SequentialTranslation Correctness
Guarantee
Compiler
Correctn
ess Proof
Leroy, 2006
CompCert Project
User Leroy
SequentialSource Program
(C minor)
CompCertCompiler
Sequential C minorOperational Semantics
11
Sequential PowerPCOperational Semantics
SequentialTarget Program
(Power PC)
SequentialTranslation Correctness
Guarantee
Compiler
Correctn
ess Proof
Leroy, 2006
CompCert Project
What is relationship here?
User Leroy
SequentialSource Program
(C minor)
CompCertCompiler
SequentialSource Program
(C minor)
CompCertCompiler
Sequential C minorOperational Semantics
12
Sequential PowerPCOperational Semantics
SequentialTarget Program
(Power PC)
SequentialTranslation Correctness
Guarantee
Compiler
Correctn
ess Proof
Appel & Blazy, 2007
Separation Logic for C minorAxiomatic Semantics
(Separation Logic)
SoundnessProof
ProgramVerification
User Leroy Appel & Blazy
ConcurrentSource Program
(C minor)
Concurrency-AwareCompCertCompiler
Concurrent C minorOperational Semantics
13
Concurrent PowerPCOperational Semantics
ConcurrentTarget Program
(Power PC)
ConcurrentTranslation Correctness
Guarantee
Concurre
ncy-Aware
Compiler
Correctn
ess Proof
Changes Required for ConcurrencyAxiomatic Semantics
(Concurrent Separation Logic)
SoundnessProof
User Future Work This work (Hobor, Appel, & Zappa Nardelli)
ProgramVerification
14
What this would mean
We would have machine-checked end-to-endcorrectness proofs of concurrent programs
Since everything would be machine-checked, wewould have very high assurance that the actualcode running on the hardware had the correct,expected behavior.
ConcurrentSource Program
(C minor)
Concurrency-AwareCompCertCompiler
Concurrent C minorOperational Semantics
15
Concurrent PowerPCOperational Semantics
ConcurrentTarget Program
(Power PC)
ConcurrentTranslation Correctness
Guarantee
Concurre
ncy-Aware
Compiler
Correctn
ess Proof
Changes Required for ConcurrencyAxiomatic Semantics
(Concurrent Separation Logic)
SoundnessProof
User Future Work
ProgramVerification
This work (Hobor, Appel, & Zappa Nardelli)
16
Additions to C minor language
We add five new statements: lock e lock a lock unlock e unlock a lock makelock e R turn an address into a
lock freelock e restore an address fork e el start a new thread
17
Additions to C minor language
We add five new statements: lock e lock a lock unlock e unlock a lock makelock e R turn an address into a
lock freelock e restore an address fork e el start a new thread
Resource Invariant – Describes what resources a threadacquires on lock and relinquishes on unlock
18
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;
19
Modularity Principle
Sequential Features Concurrent Features
s1 ; s2
if e then s1 else s2
while e do sbreak n(x1, …, xn) := e (e1, …, em)return (e1, …, en)x := e[e1] := e2
Skip…
lock eunlock efork e (e1, …, en)makelock e Rfreelock e…
20
Modularity Principle
Sequential Features Concurrent Features
s1 ; s2
if e then s1 else s2
while e do sbreak n(x1, …, xn) := e (e1, …, em)return (e1, …, en)x := e[e1] := e2
Skip…
lock eunlock efork e (e1, …, en)makelock e Rfreelock e…
Connection Easy – Just Syntax
ConcurrentSource Program
(C minor)
Concurrency-AwareCompCertCompiler
Concurrent C minorOperational Semantics
21
Concurrent PowerPCOperational Semantics
ConcurrentTarget Program
(Power PC)
ConcurrentTranslation Correctness
Guarantee
Concurre
ncy-Aware
Compiler
Correctn
ess Proof
Axiomatic Semantics(Concurrent
Separation Logic)Soundness
Proof
User Future Work
ProgramVerification
Changes Required for Concurrency
This work (Hobor, Appel, & Zappa Nardelli)
22
Modularity Principle
Sequential Reasoning Concurrent Reasoning
Sequential Separation Logic Soundness
Sequential Compiler Correctness
Type Systems
…
Concurrent Separation Logic Soundness
Concurrent Compiler Correctness
Synchronization
…
23
Modularity Principle
Sequential Reasoning Concurrent Reasoning
Insert Magic Here
Sequential Separation Logic Soundness
Sequential Compiler Correctness
Type Systems
…
Concurrent Separation Logic Soundness
Concurrent Compiler Correctness
Synchronization
…
24
How is it done?
Key: only consider well-synchronized programs – Mutual exclusion via Dijkstra Semaphores– Data-race free
Our operational semantics gets stuck onill-synchronized programs
25
Changes to Pure Sequential Semantics
C minor small-step sequential semantics
step relation: (1, 1) ↦ (2, 2) = (ρ, m) is a control stack
World-aware C minor sequential semantics
step relation: (1, 1) ↦ (2, 2) = (ρ, w, m)w is a map from addresses to ownerships
26
OwnershipsBasic ownerships:
| NONE| VAL (data)| LOCK of invariant (invariant comes from makelock)
Get stuck if you use memory without ownership
Thread worlds are disjoint – at any time, only one thread canaccess each address
Sequential instructions and proofs ignore LOCK
27
Concurrent Operational SemanticsConcurrent C minor step relation
(1, K1, m1, G1) ⇒ (2, K2, m2, G2)
is schedulerK is thread list (ρ1, w1, 1) :: (ρ2, w2, 2) :: …m is memoryG is global world – owner of unlocked locks
To execute a sequential instruction, use the world-awaresequential step relation
28
Concurrent Instructions
• The concurrent step executes concurrent instructions directly– Updates memory at the lock instruction– Maintains thread list– Transfers world between threads and global pool
• unlock: world transferred to global pool• lock: world transferred from global pool
29
SpaceThread A Thread B
lock 𝓁
unlock 𝓁
Time
w1 w
w1
wR
wRw
w2
w2
w3
w3
Memory
Memory
Global World
w1 w wRw2 w3Memory
wR is the unique world that satisfies l’’s lock invariant
30
Avoiding Race Conditions in Semantics
(ρ, wlock, m) ⊩ l ⇝ P (ρ, wlock, m) ⊩ ⊳P m(l) = 0 m’ = [l ↦ 1] mw’ wlock = w G wlock = G’Ki = (ρ, w, (unlock l) • ) K’ = [i -> (ρ, w’, )] K
(i :: , K, m, G) ⇒ (, K’, m’, G’)
Does not prevent compilation!
Unlock
31
Avoiding Race Conditions in Semantics
(ρ, wlock, m) ⊩ l ⇝ P (ρ, wlock, m) ⊩ ⊳P m(l) = 0 m’ = [l ↦ 1] mw’ wlock = w G wlock = G’Ki = (ρ, w, (unlock l) • ) K’ = [i -> (ρ, w’, )] K
(i :: , K, m, G) ⇒ (, K’, m’, G’)
Does not prevent compilation!
Unlock
32
Avoiding Race Conditions in Semantics
(ρ, wlock, m) ⊩ l ⇝ P (ρ, wlock, m) ⊩ ⊳P m(l) = 0 m’ = [l ↦ 1] mw’ wlock = w G wlock = G’Ki = (ρ, w, (unlock l) • ) K’ = [i -> (ρ, w’, )] K
(i :: , K, m, G) ⇒ (, K’, m’, G’)
Does not prevent compilation!
Unlock
33
Avoiding Race Conditions in Semantics
(ρ, wlock, m) ⊩ l ⇝ P (ρ, wlock, m) ⊩ ⊳P m(l) = 0 m’ = [l ↦ 1] mw’ wlock = w G wlock = G’Ki = (ρ, w, (unlock l) • ) K’ = [i -> (ρ, w’, )] K
(i :: , K, m, G) ⇒ (, K’, m’, G’)
Does not prevent compilation!
Unlock
34
Avoiding Race Conditions in Semantics
(ρ, wlock, m) ⊩ l ⇝ P (ρ, wlock, m) ⊩ ⊳P m(l) = 0 m’ = [l ↦ 1] mw’ wlock = w G wlock = G’Ki = (ρ, w, (unlock l) • ) K’ = [i -> (ρ, w’, )] K
(i :: , K, m, G) ⇒ (, K’, m’, G’)
Operational semantics is nonconstructive!
Unlock
35
Avoiding Race Conditions in Semantics
(ρ, wlock, m) ⊩ l ⇝ P (ρ, wlock, m) ⊩ ⊳P m(l) = 0 m’ = [l ↦ 1] mw’ wlock = w G wlock = G’Ki = (ρ, w, (unlock l) • ) K’ = [i -> (ρ, w’, )] K
(i :: , K, m, G) ⇒ (, K’, m’, G’)
Operational semantics is nonconstructive!
Unlock
36
Avoiding Race Conditions in Semantics
(ρ, wlock, m) ⊩ l ⇝ P (ρ, wlock, m) ⊩ ⊳P m(l) = 0 m’ = [l ↦ 1] mw’ wlock = w G wlock = G’Ki = (ρ, w, (unlock l) • ) K’ = [i -> (ρ, w’, )] K
(i :: , K, m, G) ⇒ (, K’, m’, G’)
Does not prevent compilation!
Unlock
37
Coroutine Interleaving
Executes sequentially without interleaving
Interleave when we get to concurrent operation
Key: we have well-synchronized programs
38
Reasoning About Concurrency
Most of the time, concurrent programs areexecuting sequential code
Proofs about sequential features are hard enough
We don’t want to add the extra complexity ofconcurrency when reasoning about sequential code
Idea: why can’t we just pretend it is sequential?
39
Sequential Reasoning
x := x + 1
[y] := 2
lock l
a := [x]
40
Sequential Reasoning
x := x + 1
[y] := 2
lock l
a := [x]
(1, 1)
(2, 2)
(3, 3)
STUCK
↦↦
41
Oracular Reasoning
x := x + 1
[y] := 2
lock l
a := [x]
(1, 1)
(2, 2)
(3, 3)
STUCK
(o1, 1, 1)
(o1, 2, 2)
(o1, 3, 3)
(o2, 4, 4)
(o2, 5, 5)
↦↦
↦↦
↦↦
42
Oracular Composition
An oracle o is (, K, G) is the schedulerK is the other threadsG is the global world
The oracle simulates running all of the otherthreads until the scheduler returns control tothis thread
43
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
ConcurrentSource Program
(C minor)
Concurrency-AwareCompCertCompiler
Concurrent C minorOperational Semantics
44
Concurrent PowerPCOperational Semantics
ConcurrentTarget Program
(Power PC)
ConcurrentTranslation Correctness
Guarantee
Concurre
ncy-Aware
Compiler
Correctn
ess Proof
Changes Required for ConcurrencyAxiomatic Semantics
(Concurrent Separation Logic)
SoundnessProof
User Future Work
ProgramVerification
This work (Hobor, Appel, & Zappa Nardelli)
45
Hoare Logic
A Hoare triple is {precondition} command {postcondition}Example: {x = 2} x++ {x = 3}
In our setting, the precondition and postcondition arepredicates on state (locals, memory, world, …)
In Coq: Definition predicate : Type := state -> Prop.
A Hoare logic is a set of axioms for deriving valid triplesExample: {P} c1 {Q} {Q} c2 {R}
{P} c1;c2 {R}
Floyd, Hoare
46
Separation LogicProblem: handling pointers
Example: {x ↦ 0 ⋀ y ↦ 0} [x] := 1 {???}{x ↦ 1 ⋀ y ↦ 0}{x ↦ 1 ⋀ y ↦ 1}
Solution: SeparationUse “∗” to split propositions into two disjoint halvesExample: {x ↦ 0 ∗ y ↦ 0} [x] := 1 {x ↦ 1 ∗ y ↦ 0}
Enables more local reasoning for programs with pointersKey rule (Frame): {P} c {Q}
{P ∗ F} c {Q ∗ F}
Reynolds, O’Hearn
47
Concurrent Separation Logic 2.0Extension of separation logic to handle concurrency
Includes all of typical the rules of separation logic
Associate with each lock an invariant Rl ⇝ 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!
CSL 1.0 by O’Hearn, 2006
SeparationLogic
ConcurrentSeparation Logic
48
SpaceThread A Thread B Thread C
lock 𝓁 unlock 𝓁
Time
𝓁⇝ RFA
𝓁⇝ RFA R
R FB
FB
{ 𝓁 ⇝ R} lock {( 𝓁 𝓁 ⇝ R) ∗ R}
{FA ∗ ( 𝓁 ⇝ R)} lock {F𝓁 A ∗ ( 𝓁 ⇝ R) ∗ R}
(lock rule)
(frame rule)
w1 w
w1
wR
wRw
w2
w2
w3
w3
Memory
Memory
ConcurrentSource Program
(C minor)
Concurrency-AwareCompCertCompiler
Concurrent C minorOperational Semantics
49
Concurrent PowerPCOperational Semantics
ConcurrentTarget Program
(Power PC)
ConcurrentTranslation Correctness
Guarantee
Concurre
ncy-Aware
Compiler
Correctn
ess Proof
Axiomatic Semantics(Concurrent
Separation Logic)Soundness
Proof
User Future Work
ProgramVerification
Changes Required for Concurrency
This work (Hobor, Appel, & Zappa Nardelli)
50
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;
51
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;
52
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;
53
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;
54
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)
55
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;
56
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)}
57
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)}
58
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)}
59
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)}
A) Many details!(Actually, some omitted!)
B) Machine-checking is key
C) Has been done for larger example programs (in Coq)
D) Machine-generation would be very helpful
ConcurrentSource Program
(C minor)
Concurrency-AwareCompCertCompiler
Concurrent C minorOperational Semantics
60
Concurrent PowerPCOperational Semantics
ConcurrentTarget Program
(Power PC)
ConcurrentTranslation Correctness
Guarantee
Concurre
ncy-Aware
Compiler
Correctn
ess Proof
Axiomatic Semantics(Concurrent
Separation Logic)Soundness
Proof
User Future Work
ProgramVerification
Changes Required for Concurrency
This work (Hobor, Appel, & Zappa Nardelli)
61
Difficulties in modelingInvariants need to be able to refer to other invariants
– Example: 50 ⇝ ∃l2. ((51 ↦ l2) ∗ (l2 ⇝ (∃x.l2+1 ↦ 2*x)
lock
even
123
124
lock
even
100
101
62
Difficulties in modelingInvariants 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
lock
pointer
50
51
lock
even
123
124
lock
even
100
101
63
A modal substructural logicWhen a logical proposition describes when and whereanother logical proposition holds, we have a modal logic
To describe time use the modal operator later “⊳”⊳P means that P will hold at all future times; maybe not now
Key: Avoids circularity and gives clean induction principle
To describe space use ∗ and the operator fashionably “◯”P * Q means that P and Q hold on disjoint subworlds◯ P means that P holds on all worlds of equal age
64
A semantic model
To build a semantic model of the modal logic, we willbuild on the “very modal model” of Appel, Mellie ̀s, Richards, & Vouillon
Unlike in that work, where it was sufficient to have onlymodal relationships, we also need to spatial properties
In general, we find that semantic models (as opposedto syntactic techniques) scale better in large systems
Appel, Mellie ̀s, Richards, & Vouillon ‘07
65
Shallow EmbeddingInvariants are semantic and shallowly embedded in Coq
The shallow embedding means that our invariants are easy touse 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
66
Another modeling difficultyWe want to embed our semantic assertions directly inprogram syntax (for makelock)
Thus, the definitions for program syntax depend on thedefinition of predicate
On the other hand, we want to allow a predicate to beable 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
67
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 statejust like any other predicate
Hypothesis: this will allow us to verify self-modifying code, such as a JIT
68
(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 mksignature args 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_rho st) (set_locals locals (set_params vl
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 := forall st, 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_assert vf sh 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).
69
Proving the Rules of CSLKey: 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 ConcurrentSeparation Logic are able to ignore thedifficulties of sequential control flow and focuson the truly concurrent behavior
Separation Logic
Appel & Blazy
ConcurrentSeparation Logic
Hobor, Appel, Zappa Nardelli
70
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, ina videogame kind of way…”
- Xavier Leroy
71
Status of Machine Checked Proofs
Definition of the Concurrent MachineDefinition of the Oracular MachineDefinition of Hoare TupleSequential Separation Logic RulesConcurrent S.L. RulesOracular Soundness
DoneDoneDoneDone
95% Done (Unlock)90% Done (Fork)
ConcurrentSource Program
(C minor)
Concurrency-AwareCompCertCompiler
Concurrent C minorOperational Semantics
72
Concurrent PowerPCOperational Semantics
ConcurrentTarget Program
(Power PC)
ConcurrentTranslation Correctness
Guarantee
Concurre
ncy-Aware
Compiler
Correctn
ess Proof
Future WorkAxiomatic Semantics
(Concurrent Separation Logic)
SoundnessProof
User Future Work
ProgramVerification
This work (Hobor, Appel, & Zappa Nardelli)
73
Key For Compiler Modification
Lock predicates only look at memory and world
The CompCert compiler is designed so that ateach intermediate level, memory is preserved
Thus, the compiler does not have to modify – oreven understand – the predicates embedded inthe makelock statement
ConcurrentSource Program
(C minor)
Concurrency-AwareCompCertCompiler
Concurrent C minorOperational Semantics
74
Concurrent PowerPCOperational Semantics
ConcurrentTarget Program
(Power PC)
ConcurrentTranslation Correctness
Guarantee
Concurre
ncy-Aware
Compiler
Correctn
ess Proof
Axiomatic Semantics(Concurrent
Separation Logic)Soundness
Proof
User Future Work
ProgramVerification
Future Work
This paper (Hobor, Appel, & Zappa Nardelli)
75
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 variouskinds of ordering constraints
However, for well-synchronized programs, our simplifiedinterleaving model is sufficient
ConcurrentSource Program
(C minor)
Concurrency-AwareCompCertCompiler
Concurrent C minorOperational Semantics
76
Concurrent PowerPCOperational Semantics
ConcurrentTarget Program
(Power PC)
ConcurrentTranslation Correctness
Guarantee
Concurre
ncy-Aware
Compiler
Correctn
ess Proof
Axiomatic Semantics(Concurrent
Separation Logic)Soundness
Proof
User Future Work
ProgramVerification
Future Work
This paper (Hobor, Appel, & Zappa Nardelli)
77
Papers and Related Work
Design and Soundness for Concurrent Separation Logic
Resources, Concurrency, and Local ReasoningPeter O’Hearn, TCS 375, pp271-307, May 2007
A Semantics for Concurrent Separation LogicStephen Brookes, TCS 375, pp227-270, May 2007
Oracle Semantics for Concurrent Separation Logic Aquinas Hobor, Andrew W. Appel, Francesco Zappa NardelliESOP 2008, pages 353-367
Local reasoning for storable locks and threadsAlexey Gotsman, Josh Berdine, Byron Cook, Noam Rinetzky, and Mooly SagivAPLAS'07, pages 19-37
78
Papers and Related Work
Semantic Models & Multimodal Logics
A Very Modal Model of a Modern, Major, General Type SystemAndrew W. Appel, Paul-Andre Mellies, Christopher Richards, and Jerome VouillonPOPL 2007
Multimodal Separation Logic for Reasoning About Operational SemanticsRobert Dockins, Andrew W. Appel, Aquinas HoborTo 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
79
Papers and Related WorkSequential Separation Logic
Separation Logic for Small-step C minorAndrew W. Appel and Sandrine BlazyTPHOLs 2007, pages 5-21
Automating Program Verification for CSL
Thread-modular shape analysisAlexey Gotsman, Josh Berdine, Byron Cook, and Mooly SagivPLDI'07, pages 266-277
Automating Separation Logic for Concurrent C minorWilliam ManskyPrinceton senior thesis, currently being written up for publication
80
A related thing I have done
Designed and prototyped an annotation-basedchecker to find concurrency bugs in Windows
The tool now runs over the Windows codebase,demonstrating the techniques are scalable anduseful for large, complex pieces of software
ConcurrentSource Program
(C minor)
Concurrency-AwareCompCertCompiler
Concurrent C minorOperational Semantics
81
Concurrent PowerPCOperational Semantics
ConcurrentTarget Program
(Power PC)
ConcurrentTranslation Correctness
Guarantee
Concurre
ncy-Aware
Compiler
Correctn
ess Proof
Concurrent C minor ProjectAxiomatic Semantics
(Concurrent Separation Logic)
SoundnessProof
User Future Work
ProgramVerification
This work (Hobor, Appel, & Zappa Nardelli)