The Relationship Between Separation Logic and Implicit Dynamic Frames

1. The Relationship Between Separation Logic and Implicit Dynamic Frames Matthew Parkinson (MSR-Cambridge) Alex Summers (ETH Zurich)

2. ETAPS 2010 What do you think about Chalice? Isn’t it just like separation logic? Not really, you can refer to heap with out permission So what are the semantics of that then? Well, it is defined by this translation with VCs I am sure we can give them a semantics with separation logic Does that mean we can translate separation logic into Chalice? Maybe

3. What? • Separation Logic and Implicit Dynamic Frames are two program specification logics • pre/post conditions, modular verification • Both have been adapted to support verification of concurrent programs • threads, locks/monitors, fork/join etc. • Chalice is a verification tool based on IDF • encodes all verification to Boogie2, Z3 prover • We wanted to formally connect two logics...

4. Overview Separation Logic(SL) Implicit Dynamic Frames (IDF) ⊂ ⊃ SL+ Kripke semantics over partial heaps ... ? ... ? Weakest pre-condition definitions Chalice : verification condition generation

5. Overview Separation Logic(SL) Implicit Dynamic Frames (IDF) ⊂ ⊃ SL+ Kripke semantics over partial heaps Kripke semantics over total heaps ? Weakest pre-condition definitions Chalice : verification condition generation

6. Overview Separation Logic(SL) Implicit Dynamic Frames (IDF) ⊂ ⊃ SL+ Kripke semantics over partial heaps Kripke semantics over total heaps Kripke semantics over total heaps ≡ ≡ Weakest pre-condition definitions Chalice : verification condition generation

7. Overview Separation Logic(SL) Implicit Dynamic Frames (IDF) ⊂ ⊃ SL+ Kripke semantics over partial heaps Kripke semantics over total heaps Kripke semantics over total heaps ≡ ≡ Weakest pre-condition definitions Chalice : verification condition generation ≡

8. Overview Separation Logic(SL) Implicit Dynamic Frames (IDF) SL+ Kripke semantics over partial heaps Kripke semantics over total heaps Kripke semantics over total heaps ≡ ≡ Weakest pre-condition definitions Chalice : verification condition generation ≡

9. What is separation logic? Four key things: • x.f↦ v (“points-to predicate”) • Permission to access location x.f • Specifies value v currently stored at the location • A * B : Splitting of heap into disjoint parts • A -̶B : Hypothetical addition of disjoint part • { P } C { Q } : Frame rule { P * R} C { Q * R} (extra stuff unmodified)

10. Weakest preconditions • Standard weakest pre-condition world: wp(assume A, B) = A ⇒ B wp(assert A, B) = A ∧ B • Other verification features can be “compiled” to assume/assert statements (e.g., method calls) • In SL, there are two analogous commands wp(assume* A, B) = A -̶ B wp(assert* A, B) = A * B

11. Overview Separation Logic(SL) Implicit Dynamic Frames (IDF) SL+ Kripke semantics over partial heaps Kripke semantics over total heaps Kripke semantics over total heaps ≡ ≡ Weakest pre-condition definitions Chalice : verification condition generation ≡

12. Implicit Dynamic Frames: permissions • Idea: use permissions to control which threads can read/write to heap locations • Permissions can be fractional, to allow multiple concurrent readers, but see paper • Extend first-order assertions to additionally include “accessibility predicates”: acc(x.f) is an assertion : we have permission to x.f • Assertions concern both heap and permissions

13. Implicit Dynamic Frames: permissions • For example (note * is written && in Chalice) acc(x.f) * x.f == 4 * acc(x.g)

14. Implicit Dynamic Frames: permissions • For example (note * is written && in Chalice) acc(x.f) * x.f == 4 * acc(x.g) x.f

15. Implicit Dynamic Frames: permissions • For example (note * is written && in Chalice) acc(x.f) * x.f == 4 * acc(x.g) x.f

16. Implicit Dynamic Frames: permissions • For example (note * is written && in Chalice) acc(x.f) * x.f == 4 * acc(x.g) x.f 4

17. Implicit Dynamic Frames: permissions • For example (note * is written && in Chalice) acc(x.f) * x.f == 4 * acc(x.g) x.f x.g 4

18. Implicit Dynamic Frames: permissions • For example (note * is written && in Chalice) acc(x.f) * x.f== 4* acc(x.g) • Expressions include heap dereferences x.f x.g 4

19. Implicit Dynamic Frames: permissions • For example (note * is written && in Chalice) acc(x.f) * x.f == 4 * acc(x.g) • Expressions include heap dereferences • Permissions need not match “read footprint” x.f x.g 4

20. Implicit Dynamic Frames: permissions • For example (note * is written && in Chalice) acc(x.f) * x.f == 4 * acc(x.g) * y.f == 3 • Expressions include heap dereferences • Permissions need not match “read footprint” x.f x.g 4

21. Implicit Dynamic Frames: permissions • For example (note * is written && in Chalice) acc(x.f) * x.f == 4 * acc(x.g) * y.f == 3 • Expressions include heap dereferences • Permissions need not match “read footprint” y.f x.f x.g 3 4

22. Inhale and Exhale • “inhale p” and “exhale p” are used in Chalice to encode transfers between threads/calls • “inhale p” means: • assume heap properties in p • gain permissions in p • havoc newly-readable locations • “exhale p” means: • assert heap properties in p • check and give up permissions void m() requires p ensures q { // inhale p ... // exhale p call m() // inhale q ... // exhale q }

23. Inhale and Exhale • “inhale p” and “exhale p” are used in Chalice to encode transfers between threads/calls • “inhale p” means: • assume heap properties in p • gain permissions in p • havoc newly-readable locations • “exhale p” means: • assert heap properties in p • check and give up permissions void m() requires p ensures q { // inhale p ... // exhale p call m() // inhale q ... // exhale q }

24. Inhale and Exhale • “inhale p” and “exhale p” are used in Chalice to encode transfers between threads/calls • “inhale p” means: • assume heap properties in p • gain permissions in p • havoc newly-readable locations • “exhale p” means: • assert heap properties in p • check and give up permissions void m() requires p ensures q { // inhale p ... // exhale p call m() // inhale q ... // exhale q }

25. Inhale and Exhale • “inhale p” and “exhale p” are used in Chalice to encode transfers between threads/calls • “inhale p” means: • assume heap properties in p • gain permissions in p • havoc newly-readable locations • “exhale p” means: • assert heap properties in p • check and give up permissions void m() requires p ensures q { // inhale p ... // exhale p call m() // inhale q ... // exhale q }

26. Inhale and Exhale • “inhale p” and “exhale p” are used in Chalice to encode transfers between threads/calls • “inhale p” means: • assume heap properties in p • gain permissions in p • havoc newly-readable locations • “exhale p” means: • assert heap properties in p • check and give up permissions void m() requires p ensures q { // inhale p ... // exhale p call m() // inhale q ... // exhale q }

27. Inhale and Exhale • “inhale p” and “exhale p” are used in Chalice to encode transfers between threads/calls • “inhale p” means: • assume heap properties in p • gain permissions in p • havoc newly-readable locations • “exhale p” means: • assert heap properties in p • check and give up permissions void m() requires p ensures q { // inhale p ... // exhale p call m() // inhale q ... // exhale q }

28. Inhale and Exhale • “inhale p” and “exhale p” are used in Chalice to encode transfers between threads/calls • “inhale p” means: • assume heap properties in p • gain permissions in p • havoc newly-readable locations • “exhale p” means: • assert heap properties in p • check and give up permissions void m() requires p ensures q { // inhale p ... // exhale p call m() // inhale q ... // exhale q }

29. Self-framing • Inhaled assertions model new information from another thread (e.g., heap values) • But, this information must be “framed” by suitable permissions, to be sound to assume • Inhaled/exhaled assertions are required to be “self-framing”: • essentially, they include enough permissions to preserve the truth of their heap assertions • e.g., acc(x.f)*x.f==4 but not x.f==4 alone

30. Overview Separation Logic(SL) Implicit Dynamic Frames (IDF) Kripke semantics over partial heaps ? Weakest pre-condition definitions Chalice : verification condition generation

31. A common semantics? Separation Logic Chalice Controls permissions and values separately Semantics defined via translation, and total heaps Encoding defined by modification of global maps for heap and permissions • Controls access to heap locations along with values • Semantics defined in terms of partial heaps • Key connectives defined by adding/removing heap fragments How can we formally relate the two?

32. SL+ Basically, a union of the syntaxes of SL and IDF Semantics defined over total heaps... Expressions (can access the heap) E ::= E.f | E + E | n | x | … Formulae (both acc and “points to” predicates) A,B ::= acc(x.f) | x.f ↦ v | E = E | A * B | … Intuition: x.f ↦ v ⇔ acc(x.f) * x.f = v

33. A*B Separation Logic partial heap IDF total heap A A B B

34. A*B Separation Logic partial heap IDF total heap A A B B

35. A*B 0 2 4 3 0 4 7 2 7 4 3 2 7 3 Separation Logic partial heap IDF total heap A A B B

36. A*B 0 2 4 3 0 4 7 2 7 4 3 2 7 3 Separation Logic partial heap IDF total heap A A B B

37. Heap agreement up to permissions 0 7 4 3 2 7 4 3 2 0 0 4 3 2 7 4 3 2 7 0 IDF total heap IDF total heap IDF total heap

38. Heap agreement up to permissions 0 4 4 3 2 7 9 3 2 1 1 0 9 4 3 2 7 4 3 2 7 IDF total heap IDF total heap

39. P ̶Q Separation Logic partial heap IDF total heap

40. P ̶Q Separation Logic partial heap IDF total heap P

41. P ̶Q Separation Logic partial heap IDF total heap P

42. P ̶Q Separation Logic partial heap IDF total heap P Q

43. P ̶Q Separation Logic partial heap IDF total heap P Q

44. P ̶Q Separation Logic partial heap IDF total heap P P ? Q

45. P ̶Q Separation Logic partial heap IDF total heap P Q

46. P ̶Q Separation Logic partial heap IDF total heap P Q

47. P ̶Q Separation Logic partial heap IDF total heap P P Q

48. P ̶Q Separation Logic partial heap IDF total heap P P Q Q

49. Self-framing revisited An assertion is self-framing if:

50. Self-framing revisited 4 3 2 7 4 3 2 7 0 0 • IDF total heap An assertion is self-framing if: For any heap and permission mask satisfying it, assertion remains true if we replace the heap with any that agrees on the permissions