Changing perspective can be useful Relating alternative logics for automatic software verification - PowerPoint PPT Presentation

hien
changing perspective can be useful relating alternative logics for automatic software verification n.
Skip this Video
Loading SlideShow in 5 Seconds..
Changing perspective can be useful Relating alternative logics for automatic software verification PowerPoint Presentation
Download Presentation
Changing perspective can be useful Relating alternative logics for automatic software verification

play fullscreen
1 / 44
Download Presentation
Changing perspective can be useful Relating alternative logics for automatic software verification
100 Views
Download Presentation

Changing perspective can be useful Relating alternative logics for automatic software verification

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Changing perspective can be usefulRelating alternative logics for automatic software verification Alex Summers (ETH Zurich) partly based on joint work with Matthew Parkinson and Daniel Jost

  2. Topic • This talk is concerned with specification logics • heap-based (usually concurrent) programs • aimed at automatic verification • There are many alternative logics out there; investigating their relationships can • be helpful for comparing expressiveness/usability • promote understanding between research groups • suggest adapting features from one to another • I’ll talk about some work relating two logics: separation logic and implicit dynamic frames

  3. Separation Logic • Idea: reason in terms of heap fragments • Specialised connectives for describing heaps • e.g., x.f↦ v (“points-to predicate”) • The only way for an assertion to dereference x.f • Specifies value v currently stored at the location x.f v

  4. Separation Logic • Separating conjunction connective * • A*B means A and B hold in disjoint heaps • e.g., x.f↦ v * y.f↦ 5 the disjointnessguarantees: x and y are not aliases h ⊨ A*B iff∃h1,h2.(h=h1⊎h2 and h1⊨ A and h2⊨ B) x.f y.f v 5

  5. Implicit Dynamic Frames • Extend standard first-order assertions to additionally include “accessibility predicates”: acc(x.f) is an assertion; we have permission to x.f • Unlike in sep. logic, assertions can also include heap-dependent expressions: e.g., x.f > 3 • Idea: verification based on a total heap • prover “sees” a value for every heap location • but these values are only guaranteed meaningful if the thread also holds permission to the location

  6. Implicit Dynamic Frames • For example acc(x.f) * x.f= 4 * acc(x.g)

  7. Implicit Dynamic Frames • For example acc(x.f) * x.f= 4 * acc(x.g) x.f

  8. Implicit Dynamic Frames • For example acc(x.f) * x.f= 4 * acc(x.g) x.f

  9. Implicit Dynamic Frames • For example acc(x.f) * x.f= 4 * acc(x.g) x.f 4

  10. Implicit Dynamic Frames • For example acc(x.f) * x.f= 4 * acc(x.g) x.f x.g 4

  11. Implicit Dynamic Frames • For example acc(x.f) * x.f= 4* acc(x.g) • Expressions include heap dereferences x.f x.g 4

  12. Implicit Dynamic Frames • For example acc(x.f) * x.f= 4 * acc(x.g) • Expressions include heap dereferences • Permissions need not match “read footprint” x.f x.g 4

  13. Implicit Dynamic Frames • For example 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

  14. Implicit Dynamic Frames • For example 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

  15. Self-framing assertions An IDF assertion is self-framing if: For any state in which the assertion is true,

  16. Self-framing assertions 4 3 2 7 4 3 2 7 0 0 • IDF total heap An IDF assertion is self-framing if: For any state in which the assertion is true, it remains true if we replace the heap with any that agrees on the locations to which it requires permissions

  17. Self-framing assertions 4 3 2 7 9 3 2 1 4 1 • IDF total heap An IDF assertion is self-framing if: For any state in which the assertion is true, it remains true if we replace the heap with any that agrees on the locations to which it requires permissions

  18. Self-framing assertions 4 3 2 7 8 4 2 1 6 2 5 • IDF total heap An IDF assertion is self-framing if: For any state in which the assertion is true, it remains true if we replace the heap with any that agrees on the locations to which it requires permissions

  19. Self-framing assertions 4 3 2 7 4 3 2 7 0 0 • IDF total heap An IDF assertion is self-framing if: For any state in which the assertion is true, it remains true if we replace the heap with any that agrees on the locations to which it requires permissions

  20. Self-framing assertions 4 3 2 7 • Separation Logic partial heap In Separation Logic, there would be partial heap which canonically represents all of these total heaps An IDF assertion is self-framing if: For any state in which the assertion is true, it remains true if we replace the heap with any that agrees on the locations to which it requires permissions

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

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

  23. A*B 0 4 3 2 4 3 7 7 4 3 2 7 0 2 Separation Logic partial heap IDF total heap A A B B Idea: x.f↦ v ⇔ acc(x.f) * x.f = v

  24. The “Magic Wand” Separation Logic partial heap An assertion A ― B means: “If, to the current heap,we add a disjoint heap satisfying A then the resulting heapis guaranteed to satisfy B” Or: h ⊨ A ― Biff∀h’⊥h.( h’ ⊨ A ⇒ h ⊎ h’ ⊨ B)  

  25. The “Magic Wand” Separation Logic partial heap An assertion A ― B means: “If, to the current heap,we add a disjoint heap satisfying A then the resulting heapis guaranteed to satisfy B” Or: h ⊨ A ― Biff∀h’⊥h.( h’ ⊨ A ⇒ h ⊎ h’ ⊨ B)  A 

  26. The “Magic Wand” Separation Logic partial heap An assertion A ― B means: “If, to the current heap,we add a disjoint heap satisfying A then the resulting heapis guaranteed to satisfy B” Or: h ⊨ A ― Biff∀h’⊥h.( h’ ⊨ A ⇒ h ⊎ h’ ⊨ B)  A 

  27. The “Magic Wand” Separation Logic partial heap An assertion A ― B means: “If, to the current heap,we add a disjoint heap satisfying A then the resulting heapis guaranteed to satisfy B” Or: h ⊨ A ― Biff∀h’⊥h.( h’ ⊨ A ⇒ h ⊎ h’ ⊨ B)  A B 

  28. The “Magic Wand” Separation Logic partial heap IDF total heap A B

  29. The “Magic Wand” Separation Logic partial heap IDF total heap A A ? B

  30. How to model heap extension? IDF total heap A ?

  31. How to model heap extension? Idea 1: IDF total heap Just add extra permissions to the original state Problem: We attach significance to the values that were previously stored in the heap, at the new locations A ?

  32. How to model heap extension? Idea 2: IDF total heap Assign new (arbitrary) values to unreadable heap locations, and then add new permissions Problem: In IDF, A may involve heap-dependent expressions A ?

  33. How to model heap extension? Idea 2: IDF total heap Assign new (arbitrary) values to unreadable heap locations, and then add new permissions Problem: In IDF, A may involve heap-dependent expressions A ?

  34. How to model heap extension? Idea 2: IDF total heap Assign new (arbitrary) values to unreadable heap locations, and then add new permissions Problem: In IDF, A may involve heap-dependent expressions A ?

  35. How to model heap extension? Idea 2: IDF total heap Assign new (arbitrary) values to unreadable heap locations, and then add new permissions Problem: In IDF, A may involve heap-dependent expressions A ?

  36. How to model heap extension? Idea 2: IDF total heap Assign new (arbitrary) values to unreadable heap locations, and then add new permissions Problem: In IDF, A may involve heap-dependent expressions A ?

  37. How to model heap extension? Idea 2: IDF total heap Assign new (arbitrary) values to unreadable heap locations, and then add new permissions Problem: In IDF, A may involve heap-dependent expressions A ?

  38. How to model heap extension? Idea 2: IDF total heap Assign new (arbitrary) values to unreadable heap locations, and then add new permissions Problem: In IDF, A may involve heap-dependent expressions A ?

  39. How to model heap extension? Idea 2: For example, acc(x.f) * (x.f≠ null ― acc(x.f.g)) The intention is that the meaning of x.f is fixed by the permission “elsewhere” When we judge the magic wand, if we consider assigning arbitrary values to x.f, then we lose the meaning IDF total heap Assign new (arbitrary) values to unreadable heap locations, and then add new permissions Problem: In IDF, Amay involve heap-dependent expressions 

  40. Minimal State Extensions • Idea: only consider “extending” the state by the smallest amount possible We modify the original semantics: h ⊨ A ― Biff ∀h’⊥h. (h’ ⊨ A ⇒ h ⊎ h’ ⊨ B)⇒ h ⊎ h’ ⊨ B) A kind of “optimised” semantics for Separation Logic (but still equivalent, for SL assertions) For IDF, we can analogously take new values for exactly the new permissions required by A 

  41. Minimal State Extensions • Idea: only consider “extending” the state by the smallest amount possible We modify the original semantics to be: h ⊨ A ― Biff ∀h’⊥h. (h’ ⊨ A ∧ ∀h’’(h’’⊂ h’ ⇒ h’’ ⊨ A) ⇒ h ⊎ h’ ⊨ B) A kind of “optimised” semantics for Separation Logic (but still equivalent, for SL assertions) For IDF, we can analogously take new values for exactly the new permissions required by A  /

  42. Where did this get us? • well, we wrote some papers • joint with Matthew Parkinson: ESOP’11,LMCS’12 • Gave formal assertion semantics to IDF logic • new connectives “migrated” from SL (e.g., A ― B) • We gave translation from SL assertions to IDF • formally relates the semantics of each • We gave a total heapssemantics for Sep. Logic • suggests new implementation strategies 

  43. But, it gets (even) better.. • Making the comparison practical, required a story for recursive predicates/functions • In joint work with Daniel Jost, we translate VeriFast examples to Chalice (VSTTE’13) • we can encode SL verification for Z3 SMT solver • required static analysis for recursive definitions • Pulling ideas from both sides is productive • Kassios/Kritikos: [ESOP’13] add backpointers to SL • “magic wand” handling might be implementable.. • other fun ideas in infancy (stay tuned)

  44. Ways of investigating relationships • Formalising and proving relationships between semantics of specification logics (e.g., described) • joint work with Matthew Parkinson: ESOP’11,LMCS’12 • Providing encodings/translations between languages of different implemented verifiers • Joint work with Daniel Jost: VSTTE’13 (this weekend!) • Specifying and verifying challenging examples using multiple different approaches/tools • e.g., verification competitions for VSTTE and FM events • interesting to try out variety of methodologies by hand