Download presentation
Presentation is loading. Please wait.
Published byEric Sanders Modified over 8 years ago
1
Oracle Semantics Aquinas Hobor
2
Why Proofs about Code are Hard Math proofs tend to have the form If A, then B 2 Lipton, Perlis, DeMillo 1977
3
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 A 1 and A 2 and A 3 and A 4 and A 5 … 3 Lipton, Perlis, DeMillo 1977
4
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 A 1 and A 2 and A 3 and A 4 and A 5, then B 1 and B 2 and B 3 4 Lipton, Perlis, DeMillo 1977
5
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 A 1 and A 2 and A 3 and A 4 and A 5, then B 1 and B 2 and B 3, except when C 1 or C 2 or C 3 or C 4 5 Lipton, Perlis, DeMillo 1977
6
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 A 1 and A 2 and A 3 and A 4 and A 5, then B 1 and B 2 and B 3, except when C 1 or C 2 or C 3 or C 4, assuming D 1 and (D 2 or D 3 ) 6 Lipton, Perlis, DeMillo 1977
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 7
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 8
9
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. 9
10
Sequential C minor Operational Semantics 10 Sequential PowerPC Operational Semantics Sequential Target Program (Power PC) Sequential Translation Correctness Guarantee Compiler Correctness Proof Leroy, 2006 CompCert Project UserLeroy Sequential Source Program (C minor) CompCert Compiler
11
Sequential C minor Operational Semantics 11 Sequential PowerPC Operational Semantics Sequential Target Program (Power PC) Sequential Translation Correctness Guarantee Compiler Correctness Proof Leroy, 2006 CompCert Project What is relationship here? UserLeroy Sequential Source Program (C minor) CompCert Compiler
12
Sequential Source Program (C minor) CompCert Compiler Sequential C minor Operational Semantics 12 Sequential PowerPC Operational Semantics Sequential Target Program (Power PC) Sequential Translation Correctness Guarantee Compiler Correctness Proof Appel & Blazy, 2007 Separation Logic for C minor Axiomatic Semantics (Separation Logic) Soundness Proof Program Verification UserLeroyAppel & Blazy
13
Concurrent Source Program (C minor) Concurrency-Aware CompCert Compiler Concurrent C minor Operational Semantics 13 Concurrent PowerPC Operational Semantics Concurrent Target Program (Power PC) Concurrent Translation Correctness Guarantee Concurrency-Aware Compiler Correctness Proof Changes Required for Concurrency Axiomatic Semantics (Concurrent Separation Logic) Soundness Proof UserFuture WorkThis work (Hobor, Appel, & Zappa Nardelli) Program Verification
14
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. 14
15
Concurrent Source Program (C minor) Concurrency-Aware CompCert Compiler Concurrent C minor Operational Semantics 15 Concurrent PowerPC Operational Semantics Concurrent Target Program (Power PC) Concurrent Translation Correctness Guarantee Concurrency-Aware Compiler Correctness Proof Changes Required for Concurrency Axiomatic Semantics (Concurrent Separation Logic) Soundness Proof UserFuture Work Program Verification 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 16
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 17 Resource Invariant – Describes what resources a thread acquires 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; unlock l; 18
19
Modularity Principle Sequential FeaturesConcurrent Features 19 s 1 ; s 2 if e then s 1 else s 2 while e do s break n (x 1, …, x n ) := e (e 1, …, e m ) return (e 1, …, e n ) x := e [e 1 ] := e 2 Skip … lock e unlock e fork e (e 1, …, e n ) makelock e R freelock e …
20
Modularity Principle Sequential FeaturesConcurrent Features 20 s 1 ; s 2 if e then s 1 else s 2 while e do s break n (x 1, …, x n ) := e (e 1, …, e m ) return (e 1, …, e n ) x := e [e 1 ] := e 2 Skip … lock e unlock e fork e (e 1, …, e n ) makelock e R freelock e … Connection Easy – Just Syntax
21
Concurrent Source Program (C minor) Concurrency-Aware CompCert Compiler Concurrent C minor Operational Semantics 21 Concurrent PowerPC Operational Semantics Concurrent Target Program (Power PC) Concurrent Translation Correctness Guarantee Concurrency-Aware Compiler Correctness Proof Axiomatic Semantics (Concurrent Separation Logic) Soundness Proof UserFuture Work Program Verification Changes Required for Concurrency This work (Hobor, Appel, & Zappa Nardelli)
22
Modularity Principle Sequential ReasoningConcurrent Reasoning 22 Sequential Separation Logic Soundness Sequential Compiler Correctness Type Systems … Concurrent Separation Logic Soundness Concurrent Compiler Correctness Synchronization …
23
Modularity Principle Sequential ReasoningConcurrent Reasoning Insert Magic Here 23 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 on ill-synchronized programs 24
25
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 25
26
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 26
27
Concurrent Operational Semantics Concurrent C minor step relation ( 1, K 1, m 1, G 1 ) ⇒ ( 2, K 2, m 2, G 2 ) 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 27
28
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 28
29
Space Thread AThread B lock unlock Time 11 11 RR RR 22 22 33 33 Memory 29 Global Resource Map 11 RR 22 33 Memory R is the unique resource map that satisfies l ’’s lock invariant
30
Avoiding Race Conditions in Semantics ( ρ, lock, m) ⊩ l ⇝ P ( ρ, lock, m) ⊩ ⊳ P m( l ) = 0 m’ = [ l ↦ 1] m ’ lock = G lock = G’ K i = ( ρ, , ( unlock l ) )K’ = [i -> ( ρ, ’, )] K (i :: , K, m, G) ⇒ ( , K’, m’, G’) Does not prevent compilation! 30 Unlock
31
Avoiding Race Conditions in Semantics ( ρ, lock, m) ⊩ l ⇝ P ( ρ, lock, m) ⊩ ⊳ P m( l ) = 0 m’ = [ l ↦ 1] m ’ lock = G lock = G’ K i = ( ρ, , ( unlock l ) )K’ = [i -> ( ρ, ’, )] K (i :: , K, m, G) ⇒ ( , K’, m’, G’) Does not prevent compilation! 31 Unlock
32
Avoiding Race Conditions in Semantics ( ρ, lock, m) ⊩ l ⇝ P ( ρ, lock, m) ⊩ ⊳ P m( l ) = 0 m’ = [ l ↦ 1] m ’ lock = G lock = G’ K i = ( ρ, , ( unlock l ) )K’ = [i -> ( ρ, ’, )] K (i :: , K, m, G) ⇒ ( , K’, m’, G’) Does not prevent compilation! 32 Unlock
33
Avoiding Race Conditions in Semantics ( ρ, lock, m) ⊩ l ⇝ P ( ρ, lock, m) ⊩ ⊳ P m( l ) = 0 m’ = [ l ↦ 1] m ’ lock = G lock = G’ K i = ( ρ, , ( unlock l ) )K’ = [i -> ( ρ, ’, )] K (i :: , K, m, G) ⇒ ( , K’, m’, G’) Does not prevent compilation! 33 Unlock
34
Avoiding Race Conditions in Semantics ( ρ, lock, m) ⊩ l ⇝ P ( ρ, lock, m) ⊩ ⊳ P m( l ) = 0 m’ = [ l ↦ 1] m ’ lock = G lock = G’ K i = ( ρ, , ( unlock l ) )K’ = [i -> ( ρ, ’, )] K (i :: , K, m, G) ⇒ ( , K’, m’, G’) Operational semantics is nonconstructive! 34 Unlock
35
Avoiding Race Conditions in Semantics ( ρ, lock, m) ⊩ l ⇝ P ( ρ, lock, m) ⊩ ⊳ P m( l ) = 0 m’ = [ l ↦ 1] m ’ lock = G lock = G’ K i = ( ρ, , ( unlock l ) )K’ = [i -> ( ρ, ’, )] K (i :: , K, m, G) ⇒ ( , K’, m’, G’) Operational semantics is nonconstructive! 35 Unlock
36
Avoiding Race Conditions in Semantics ( ρ, lock, m) ⊩ l ⇝ P ( ρ, lock, m) ⊩ ⊳ P m( l ) = 0 m’ = [ l ↦ 1] m ’ lock = G lock = G’ K i = ( ρ, , ( unlock l ) )K’ = [i -> ( ρ, ’, )] K (i :: , K, m, G) ⇒ ( , K’, m’, G’) Does not prevent compilation! 36 Unlock
37
Coroutine Interleaving Executes sequentially without interleaving Interleave when we get to concurrent operation Key: we have well-synchronized programs 37
38
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? 38
39
Sequential Reasoning x := x + 1 [y] := 2 lock l a := [x] 39
40
Sequential Reasoning x := x + 1 [y] := 2 lock l a := [x] 40 ( 1, 1 ) ( 2, 2 ) ( 3, 3 ) STUCK ↦ ↦
41
Oracular Reasoning x := x + 1 [y] := 2 lock l a := [x] 41 ( 1, 1 ) ( 2, 2 ) ( 3, 3 ) STUCK (o 1, 1, 1 ) (o 1, 2, 2 ) (o 1, 3, 3 ) (o 2, 4, 4 ) (o 2, 5, 5 ) ↦ ↦ ↦ ↦ ↦ ↦
42
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 42
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 43
44
Concurrent Source Program (C minor) Concurrency-Aware CompCert Compiler Concurrent C minor Operational Semantics 44 Concurrent PowerPC Operational Semantics Concurrent Target Program (Power PC) Concurrent Translation Correctness Guarantee Concurrency-Aware Compiler Correctness Proof Changes Required for Concurrency Axiomatic Semantics (Concurrent Separation Logic) Soundness Proof UserFuture Work Program Verification 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 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} c 1 {Q}{Q} c 2 {R} {P} c 1 ; c 2 {R} 45 Floyd, Hoare
46
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} 46 Reynolds, O’Hearn
47
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! 47 CSL 1.0 by O’Hearn, 2006 Separation Logic Concurrent Separation Logic
48
Space Thread AThread BThread C lock unlock Time ⇝ R FAFA FAFA R R FBFB FBFB { ⇝ R} lock {( ⇝ R) ∗ R} {F A ∗ ( ⇝ R)} lock {F A ∗ ( ⇝ R) ∗ R} (lock rule) (frame rule) 11 11 RR RR 22 22 33 33 Memory 48
49
Concurrent Source Program (C minor) Concurrency-Aware CompCert Compiler Concurrent C minor Operational Semantics 49 Concurrent PowerPC Operational Semantics Concurrent Target Program (Power PC) Concurrent Translation Correctness Guarantee Concurrency-Aware Compiler Correctness Proof Axiomatic Semantics (Concurrent Separation Logic) Soundness Proof UserFuture Work Program Verification 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; unlock l; 50
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; unlock l; 51
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; 52
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; 53
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; 54 ( ∃ 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; 55
56
Verification of Example Program lock l; [x] := [x] + 1; { F * l ⇝ ( ∃ y. x ↦ y+y) * ( ∃ y. x ↦ y+y) } unlock l; { F * l ⇝ ( ∃ y. x ↦ y+y) } 56
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) } 57
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) } 58
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) } 59 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
60
Concurrent Source Program (C minor) Concurrency-Aware CompCert Compiler Concurrent C minor Operational Semantics 60 Concurrent PowerPC Operational Semantics Concurrent Target Program (Power PC) Concurrent Translation Correctness Guarantee Concurrency-Aware Compiler Correctness Proof Axiomatic Semantics (Concurrent Separation Logic) Soundness Proof UserFuture Work Program Verification Changes Required for Concurrency This work (Hobor, Appel, & Zappa Nardelli)
61
Difficulties in modeling Invariants need to be able to refer to other invariants – Example: 50 ⇝ ∃ l 2. ((51 ↦ l 2 ) ∗ (l 2 ⇝ ( ∃ x.l 2 +1 ↦ 2*x) lock even 123 124 lock even 100 101 61
62
Difficulties in modeling Invariants need to be able to refer to other invariants – Example: 50 ⇝ ∃ l 2. ((51 ↦ l 2 ) ∗ (l 2 ⇝ ( ∃ x.l 2 +1 ↦ 2*x))) Nested Invariants are Difficult to Model lock pointer 50 51 lock even 123 124 lock even 100 101 62
63
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 63
64
A semantic model To build a semantic model of the modal logic, we will build on the “very modal model” of Appel, Mellie ̀ 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 64 Appel, Mellie ̀ s, Richards, & Vouillon ‘07
65
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 65
66
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 66
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 state just like any other predicate Hypothesis: this will allow us to verify self- modifying code, such as a JIT 67
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). 68
69
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 69 Separation Logic Appel & Blazy Concurrent Separation 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, in a videogame kind of way…” - Xavier Leroy 70
71
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 71 Done 95% Done (Unlock) 90% Done (Fork)
72
Concurrent Source Program (C minor) Concurrency-Aware CompCert Compiler Concurrent C minor Operational Semantics 72 Concurrent PowerPC Operational Semantics Concurrent Target Program (Power PC) Concurrent Translation Correctness Guarantee Concurrency-Aware Compiler Correctness Proof Future Work Axiomatic Semantics (Concurrent Separation Logic) Soundness Proof UserFuture Work Program Verification This work (Hobor, Appel, & Zappa Nardelli)
73
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 73
74
Concurrent Source Program (C minor) Concurrency-Aware CompCert Compiler Concurrent C minor Operational Semantics 74 Concurrent PowerPC Operational Semantics Concurrent Target Program (Power PC) Concurrent Translation Correctness Guarantee Concurrency-Aware Compiler Correctness Proof Axiomatic Semantics (Concurrent Separation Logic) Soundness Proof UserFuture Work Program Verification 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 various kinds of ordering constraints However, for well-synchronized programs, our simplified interleaving model is sufficient 75
76
Concurrent Source Program (C minor) Concurrency-Aware CompCert Compiler Concurrent C minor Operational Semantics 76 Concurrent PowerPC Operational Semantics Concurrent Target Program (Power PC) Concurrent Translation Correctness Guarantee Concurrency-Aware Compiler Correctness Proof Axiomatic Semantics (Concurrent Separation Logic) Soundness Proof UserFuture Work Program Verification Future Work This paper (Hobor, Appel, & Zappa Nardelli)
77
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 Separation Logic 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 Mooly Sagiv APLAS'07, pages 19-37 77
78
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 Frameworks C. J. Bell, Robert Dockins, Aquinas Hobor, Andrew W. Appel, David Walker Currently submitted for publication 78
79
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 Mooly Sagiv PLDI'07, pages 266-277 Automating Separation Logic for Concurrent C minor William Mansky Princeton senior thesis, currently being written up for publication 79
80
Concurrent Source Program (C minor) Concurrency-Aware CompCert Compiler Concurrent C minor Operational Semantics 80 Concurrent PowerPC Operational Semantics Concurrent Target Program (Power PC) Concurrent Translation Correctness Guarantee Concurrency-Aware Compiler Correctness Proof Concurrent C minor Project Axiomatic Semantics (Concurrent Separation Logic) Soundness Proof UserFuture Work Program Verification This work (Hobor, Appel, & Zappa Nardelli)
Similar presentations
© 2024 SlidePlayer.com Inc.
All rights reserved.