The Relationship Between Separation Logic and Implicit Dynamic Frames

Slides:



Advertisements
Similar presentations
Joint work with Mike Barnett, Robert DeLine, Manuel Fahndrich, and Wolfram Schulte Verifying invariants in object-oriented programs K. Rustan M. Leino.
Advertisements

Technologies for finding errors in object-oriented software K. Rustan M. Leino Microsoft Research, Redmond, WA Lecture 1 Summer school on Formal Models.
Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Automated Verification with HIP and SLEEK Asankhaya Sharma.
Constraint Semantics for Abstract Read Permissions 28 th July 2014, FTfJP, Uppsala John Tang Boyland (UW-Milwaukee/ETH Zurich) Peter Müller, Malte Schwerhoff,
Automated Software Verification with a Permission-Based Logic 20 th June 2014, Zürich Malte Schwerhoff, ETH Zürich.
Hoare’s Correctness Triplets Dijkstra’s Predicate Transformers
Formal Semantics of Programming Languages 虞慧群 Topic 5: Axiomatic Semantics.
A survey of techniques for precise program slicing Komondoor V. Raghavan Indian Institute of Science, Bangalore.
Partial correctness © Marcelo d’Amorim 2010.
ISBN Chapter 3 Describing Syntax and Semantics.
Copyright © 2006 Addison-Wesley. All rights reserved. 3.5 Dynamic Semantics Meanings of expressions, statements, and program units Static semantics – type.
CS 355 – Programming Languages
Changing perspective can be useful Relating alternative logics for automatic software verification Alex Summers (ETH Zurich) partly based on joint work.
Formal Methods of Systems Specification Logical Specification of Hard- and Software Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt.
Fractional Permissions without the Fractions Alex Summers ETH Zurich Joint work with: Stefan Heule, Rustan Leino, Peter Müller ETH Zurich MSR Redmond ETH.
Lecture 2 Towards a Verifying Compiler: Logic of Object oriented Programs Wolfram Schulte Microsoft Research Formal Methods 2006 Objects, references, heaps,
K. Rustan M. Leino Research in Software Engineering (RiSE) Microsoft Research, Redmond, WA part 0 Summer School on Logic and Theorem-Proving in Programming.
ECI 2007: Specification and Verification of Object- Oriented Programs Lecture 1.
On the Relationship Between Concurrent Separation Logic and Assume-Guarantee Reasoning Xinyu Feng Yale University Joint work with Rodrigo Ferreira and.
From last time S1: l := new Cons p := l S2: t := new Cons *p := t p := t l p S1 l p tS2 l p S1 t S2 l t S1 p S2 l t S1 p S2 l t S1 p L2 l t S1 p S2 l t.
Review: forward E { P } { P && E } TF { P && ! E } { P 1 } { P 2 } { P 1 || P 2 } x = E { P } { \exists … }
CS 330 Programming Languages 09 / 16 / 2008 Instructor: Michael Eckmann.
Well-cooked Spaghetti: Weakest-Precondition of Unstructured Programs Mike Barnett and Rustan Leino Microsoft Research Redmond, WA, USA.
Chair of Software Engineering Automatic Verification of Computer Programs.
Describing Syntax and Semantics
K. Rustan M. Leino RiSE, Joint work with: Peter Müller (ETH Zurich) Jan Smans (KU Leuven) Special thanks to Mike Barnett VMCAI, Madrid, Spain, 18 January.
Crowfoot: a verifier for higher order store programs Billiejoe (Nathaniel) Charlton Ben Horsfall Bernhard Reus University of Sussex VMCAI 2012.
Aquinas Hobor and Cristian Gherghina (National University of Singapore) TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.:
Automated Software Verification with Implicit Dynamic Frames 5 th December 2013, Leuven Malte Schwerhoff, ETH Zürich/KU Leuven.
Viper A Verification Infrastructure for Permission-Based Reasoning 1 st March 2015, ECOOP’15 PC Meeting, Zurich Uri Juhasz, Ioannis Kassios, Peter Müller,
Formal Verification Lecture 9. Formal Verification Formal verification relies on Descriptions of the properties or requirements Descriptions of systems.
Checking Reachability using Matching Logic Grigore Rosu and Andrei Stefanescu University of Illinois, USA.
Viper A Verification Infrastructure for Permission-Based Reasoning 24 th March 2015, JML Workshop, Leiden Uri Juhasz, Ioannis Kassios, Peter Müller, Milos.
Rustan Leino RiSE, Microsoft Research, Redmond MIT 5 June 2009 Joint work with: Peter Müller, ETH Zurich Jan Smans, KU Leuven.
Certifying Intermediate Programming Zhaopeng Li
Semantics In Text: Chapter 3.
Lecture 5 1 CSP tools for verification of Sec Prot Overview of the lecture The Casper interface Refinement checking and FDR Model checking Theorem proving.
Lightweight Support for Magic Wands in an Automatic Verifier Malte Schwerhoff and Alexander J. Summers 10 th July 2015, ECOOP, Prague.
An Introduction to Automated Program Verification with Permission Logics 15 th May 2015, Systems Group, ETH Zurich Uri Juhasz, Ioannis Kassios, Peter Müller,
CSE Winter 2008 Introduction to Program Verification for-loops; review.
ESOP 2010, Paphos, Cyprus, 22 March 2010 K. Rustan M. Leino (RiSE group, Microsoft Research) Peter Müller (ETH Zurich) Jan Smans (KU Leuven)
Faithful mapping of model classes to mathematical structures Ádám Darvas ETH Zürich Switzerland Peter Müller Microsoft Research Redmond, WA, USA SAVCBS.
DBC NOTES. Design By Contract l A contract carries mutual obligations and benefits. l The client should only call a routine when the routine’s pre-condition.
Prof. Necula CS 164 Lecture 171 Operational Semantics of Cool ICOM 4029 Lecture 10.
Program Analysis and Verification
IS 2620: Developing Secure Systems Formal Verification/Methods Lecture 9 March 15, 2012.
Towards a Semantic Model for Java Wildcards Sophia Drossopoulou Mariangiola Dezani-Ciancaglini Imperial College London Università di Torino Italy Nicholas.
Chapter 3 of Programming Languages by Ravi Sethi
Opeoluwa Matthews, Jesse Bingham, Daniel Sorin
Further with Hoare Logic Sections 6.12, 6.10, 6.13
A Verification Infrastructure for Permission-based Reasoning
Sparkle a functional theorem prover
Matching Logic An Alternative to Hoare/Floyd Logic
The Relationship Between Separation Logic and Implicit Dynamic Frames
Reasoning About Code.
Revisiting Predicate Logic LN chapters 3,4
(One-Path) Reachability Logic
Formal Verification/Methods
Matching Logic - A New Program Verification Approach -
Lecture 5 Floyd-Hoare Style Verification
IS 2935: Developing Secure Systems
Over-Approximating Boolean Programs with Unbounded Thread Creation
A Verification Infrastructure for Permission-Based Reasoning
This Lecture Substitution model
Semantics In Text: Chapter 3.
This Lecture Substitution model
This Lecture Substitution model
ONTOMERGE Ontology translations by merging ontologies Paper: Ontology Translation on the Semantic Web by Dejing Dou, Drew McDermott and Peishen Qi 2003.
A Considerate Specification of the Composite Pattern
Presentation transcript:

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

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

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...

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

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

⊂ ⊃ ≡ ≡ Overview SL+ 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

⊂ ⊃ ≡ ≡ ≡ Overview SL+ 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 ≡

Kripke semantics over partial heaps Weakest pre-condition definitions 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 ≡

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)

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

Chalice : verification condition generation 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 ≡

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

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

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

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

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

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

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

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

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

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

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 }

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 }

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 }

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 }

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 }

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 }

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 }

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

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

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

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

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

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

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

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

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

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

P ̶ Q Separation Logic partial heap IDF total heap

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

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

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

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

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

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

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

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

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

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

Self-framing revisited 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 IDF total heap 4 7 3 2 4 7 3 2

Self-framing revisited 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 IDF total heap 4 1 4 7 3 2 9 3 2 9 1

Self-framing revisited 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 IDF total heap 6 2 4 7 3 2 2 1 4 5 8

Self-framing revisited 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 IDF total heap 4 7 3 2 4 7 3 2

Self-framing revisited 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 Separation Logic partial heap 4 7 3 2 In Separation Logic, there would be partial heap which canonically represents all the total ones in our semantics

Faithfully represents separation logic Definition: the restriction of a total heap H to permissions P, is a partial heap H↾P defined by: H↾P(x) = H(x) provided P(x) > 1, H↾P(x) is undefined otherwise. Theorem If A is a separation logic assertion, then: P ⊧ A in SL+ ⇔ H↾P ⊧ A in SL

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

Chalice Weakest Pre-conditions Encoded using two special variables H : represents the values in the heap P : represents the permissions to access heap For example, wpch(inhale(acc(E.f)), A) = wpch(P[E,f] += 1; assume (P[E,f]==1), A) wpch(inhale(a*b), A) = wpch(inhale(a);inhale(b), A)

Translating SL+ to many sorted FOL Expressions ⌊⌊x⌋⌋ = x ⌊⌊ E.f ⌋⌋ = H [ ⌊⌊E⌋⌋ , f ] Formulae ⌊⌊acc(E.f)⌋⌋ = P [⌊⌊E⌋⌋,f] == 1 ⌊⌊A*B⌋⌋ = ∃P1,P2. ⌊⌊A⌋⌋ [P1/P] ∧ ⌊⌊B⌋⌋[P2/P] ∧ P1 * P2 = P P1 * P2 = P ⇔ ∀i. P1[i] + P2[i] = P[i] ∧ P[i] ≤ 1

Key points of the proof All existentials of array type introduced by ⌊⌊ ⌋⌋ are witnessed in Chalice VCs. Self-framing is checked in Chalice by a syntactic (left-to-right) criterion, which is stronger than the semantic notion. Note: asymmetry (left-to-right checking) of self-framing is essential for Chalice VC for inhale.

Faithfully representing Chalice Theorem wpch (exhale p, ⌊⌊ A ⌋⌋) ⇔ ⌊⌊wpsl(exhale p, A)⌋⌋ If p is (syntactically) self-framing, then wpch(inhale p, ⌊⌊ A ⌋⌋) ⇔ ⌊⌊wpsl(inhale p, A)⌋⌋

⊂ ⊃ ≡ ≡ ≡ Summary SL+ 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 ≡

Summary We defined a direct semantics for IDF logic We defined a total heaps semantics for SL We have formally connected the two logics We can encode SL assertions as IDF assertions ... and back again, for self-framing IDF assertions This suggests we could verify SL specifications directly in Chalice, via Boogie2/Z3...

Automation We can use our work to provide a new way of verifying separation logic specifications Apply our encoding to convert to IDF, then feed the specification to Chalice Allows the verification of sep. logic directly using a first-order theorem prover Requires extension to handle predicates Such experiments planned for future work..

Future/Ongoing work We found the (experimental) implementation of Chalice predicates to be unsound Once this is fixed, our connection will be extended to (partly) cover predicates Extending Chalice with more connectives can be aided by our concrete semantics Extending Separation Logic contracts with “old” expressions, using total heaps semantics

Thank you for listening.. 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 ≡