Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Oracle Semantics Aquinas Hobor. Why Proofs about Code are Hard Math proofs tend to have the form If A, then B 2 Lipton, Perlis, DeMillo 1977."— Presentation transcript:

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 11  11 RR RR  22 22 33 33 Memory 29 Global Resource Map 11  RR 22 33 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) 11  11 RR RR  22 22 33 33 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)


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

Similar presentations


Ads by Google