Separation logic

Using Hoare logic we can derive statements like this, which capture the specification of the inc() function:

 { x = n }
 inc(x)
 { x = n + 1}

We'd like to be able to use such statements to construct proofs of statements that involve procedures like inc().

 {x = n ∧ y = m }
 inc(x);
 inc(y);
 {x = n+1 ∧ y = m + 1}

The problem is that we need an intermediate proposition that is stronger than what the spec gives us directly: x = n+1 ∧ y = m. One approach is to strengthen the spec of inc clause Separation logic says what you are allowed to asccess: both access control and a specification of what the state is. The clause that says things other than x aren't modified becomes implicit.

 {x = n ∧ y = m }
 inc(x);
 inc(y);
 {x = n+1 ∧ y = m + 1}

There have been a number of attempts to extend the logic to support modular reasoning about heaps and procedures. Separation logic is probably the most popular. Separation logic has a similar structure to Hoare logic, but the meaning of {P}c{Q} is different. Semantically, ∀h1, ∀h2, if P(h1), then running c in heap (h1 ⨄ h2) yields a heap h3 = h4 ⨄ h2 where Q(h4). Note that by + here we mean disjoint union. Specifications in separation logic are defined by the following syntax

    emp            the heap is empty
    x ↦ v          the heap contains a single mapping from x to v
    P * Q          * is the _separating conjunction_ of separation logic.
                   Holds on heap h = h1 ⨄ h2 where P(h1) and Q(h2).
    P ∧ Q          Usual semantics
    P -* Q         The "magic wand" implication. Idea: a heap satisfies it 
                   if it satisfies Q when extended with some disjoint heap that
                   satisfies P. This is useful for weakest preconditions.

This is nice because the rules for assignment, consequence etc. still hold.

{x ↦ _ } x := v { x ↦ v}

With this module, we develop a separation logic for reasoning about imperative Coq programs. Separation logic gives us a crucial principle for modularly reasoning about programs — the frame rule.

Just to demonstrate things, let's fix the universe of storable types by giving some type names and an interpretation.

Heaps

We're going to store dynamic values -- a pair of an stype t and a value of type interp t.

We will continue to use lists of pointers and values as the model for heaps. However, to support an easy definition of disjoint union, we will impose the additional constraint that the list is sorted in (strictly) increasing order. It's possible to capture this constraint by defining heaps as a sigma type, where we include a proof that the heap is sorted. That makes some things easier (e.g., arguing that disjoint union is commutative) but makes other things harder. For example, equality on sigmas would demand we need to compare proofs, and use proof- irrelevance. To avoid this we can put in well-formedness constraints in just the right places.

Each pointer in h is greater than x

A heap is well-formed if each pointer is less than the rest of the heap, and the rest of the heap is well-formed.

A pointer is fresh for h when it's not in the domain of h.

Two heaps are disjoint when each pointer in h1 is fresh for h2.

Aha! Insertion sort arises again.

Merge two heaps using insertion

Commands

As before a command takes a heap and returns an optional heap and result

Some notation to approximate Haskell's "do" notation.

Untyped read returns a dynamic.

This abbreviation may look funny (since we don't use t), but it will make it easier for Coq to figure out the stype at which we're using things. Note that this is a little misleading because in general, a ptr can map to a value of any stype!

Typed read -- we do an untyped read, and then check that the stype matches what we expected, failing if not, and returning the underlying value otherwise.

Untyped write

Typed write.

When we allocate, we need to pick something fresh for the heap. So we choose the maximum value in the heap plus one.

Heap Predicates or hprops

An hprop is a predicate on heaps.

emp holds only when the heap is empty. One way to think of emp is that as a pre-condition, it tells us that we don't have the right to access anything in the heap. emp plays the role of a unit for star which is defined below.

top holds on any heap.

x ---> d holds when the heap contains exactly one pointer x which points to d. So we can think of this predicate as permission to read or write x and if we read it, we'll get out the dynamic value d. However, we're not allowed to read or write any other location if this is our only pre-condition.

x --> v is the same as above, except we make the type explicit.

P ** Q holds when the heap can be broken into disjoint heaps h1 and h2 such that h1 satisfies P and h2 satisfies Q. For example x --> v ** y --> v tells us that we have the right to access both x and y, but that x <> y.

When P is a pure predicate in the sense that it doesn't refer to a heap, then we can use pure P as a predicate on the heap. Note that we require that the heap that it corresponds to is empty.

sing h is the singleton predciate on heaps -- i.e., it holds on h' only when h' is equal to h.

This definition lifts an existential quantifier up to a predicate on heaps.

So for instance, we can define x -->? as follows

This notation will be useful for reasoning about when one separation predicate can be used in lieu of another -- i.e., a form of implication over heaps. Note that this is not the "magic-wand" of separation logic, but rather, a meta-level implication.

My old friend...

We need a ton of lemmas for reasoning about heaps. The keys ones are showing that various operations preserve well-formedness, or that merging well-formed heaps is commutative and associative, etc. removing a pointer keeps a heap well-formed

disjoint is commutative.

inserting a fresh pointer keeps a heap well-formed.

merging two well-formed, disjoint heaps results in a well-formed heap.

insert is commutative for distinct pointers

merge is commutative when the heaps are well-formed and disjoint.

well-formed merges are associative.

if p is fresh for merge h1 h2, then it's also fresh for both h1 and h2.

Separation Reasoning

Reasoning directly in terms of heaps is painful. So we will define some rules for reasoning directly at the level of the separation logic. This list of lemmas is by no means complete...

This little tactic helps prove things are disjoint:

This lemma will help me simplify some reasoning involving existentials.

Separation Logic Rules

Separation logic total correctness: {{ P }} c {{ Q }} holds iff (1) we start with a heap h that can be broken into two parts, one that satisfies P and another satisfying sing h2 for some h2, (2) we run the command c on heap h and get out Some heap h' and value v, and (3) the output heap h' satisfies Q v ** sing h2. That is, the output heap can be broken into two disjoint heaps, one satisfying Q v, and one satisfying sing h2. This effectively forces the command to be parametric in some part of the heap (h2) and leave it alone. In turn, this means that if we have proven a separate property about h2, this property will be preserved when we run c.

Lots of definitions to be unwound...

This says that ret v can be run in a heap satisfying emp and returns a heap satisfying emp and the return value is equal to v. But remember that this really means that ret can be run in any heap h that can be broken into a portion satisfying emp (i.e., the empty heap and some other heap (which must be h!) and that the other portion will be preserved. In short, the specification captures the fact that ret will not change the heap.

new v consumes an empty heap, and produces a pointer x and a heap satisfying x --> v. Because of the definition of the separation-total-correctness triple, x must be fresh for the whole heap.

free x is nicely dual to new.

write p v requires a heap where p points to some value, and ensures p points to v afterwards.

read p requires a heap where p points to some value v, and ensures p points to v afterwards, and the result is equal to v.

This is one possible proof rule for bind. Basically, we require that the post-condition of the first command implies the pre-condition of the second command.

And we also have a rule of consequence which allows us to strengthen the pre-condition and weaken the post-condition. Note however, that this will not allow us to "forget" any locations in our footprint.

This is a specialization of consequence that is a little more useful to use.

This is a specialization of consequence that is a little more useful to use.

Finally, this is the most important rule and the one we lacked with Hoare logic: If {{ P }} c {{ Q }}, then also {{ P ** R }} c {{ Q ** R }}. That is, properties such as R which are disjoint from the footprint are preserved when we run the command.

Examples

So this claims that if we start in a state where p holds n, then after running inc, we do not fail and get into a state where p holds 1+n. Notice that it's rather delicate to hang on to the fact that the value read out is equal to n. If we used binary post-conditions (a relation on both the input heap and output heap), this wouldn't be necessary.

The great part is that now if we have a property on some disjoint part of the state, say p2 --> n2, then after calling inc, we are guaranteed that property is preserved via the frame rule.

swap the contents of two pointers

Alas, reasoning isn't quite as simple as we might hope. We have to not only put in the right uses of the frame and consequence rules, but we must also so a lot of commuting and re-associating to discharge the verification conditions. For Ynot, Adam Chlipala wrote an Ltac tactic that mostly took care of this sort of simple reasoning for us. And Gonthier et al. have done some nice work showing how to use type-classes or canonical-structures to automate a lot of this sort of thing. Below, we'll see you an alternative technique based on reflection.

Reflection and a Simple, Correct Semi-Decision Procedure

Our goal is to build a Coq function that can simplify a separation implication P ==> Q and prove that function correct. One simple strategy is to flatten out all of the stars and cross off all of the simple predicates that appear in both P and Q. But of course, we can't just crawl over an hprop because in general, these are functions! So our trick is to write down some syntax that represents a particular predicate, and then give an interpretation that maps that syntax back to our real predicate. Then we can compute with the syntax. The Quote library should help us with this, but alas, it's not as clever as we might hope it would be...

We begin by giving a basic syntax for predicates. Atom will be used to represent things like abstract predicates (e.g., a variable P) or a points-to-predicate etc. We'll use an environment to map hprop_names to the real hprop.

assume we have an hprop_map lying around.

Now we given an interpreation to the syntax for predicates:

Flatten a predicate into a list of hprop_names.

Remove exactly one copy of the hprop_name n from the input list, returning None if we fail to find a copy of n.

This is the heart of our simplification algorithm. Here, we are running through the list of names hp1, trying to cross off each one that occurs in hp2. If the current name doesn't occur, we add it to the end of hp0 so that we can keep track of it. That is, our invariant at each step should be that hp0 ** hp1 ==> hp2 once we map the lists back to hprops.

Convert a list of names back into an Hprop.

Convert a list of names into an hprop.

So our cross-off algorithm takes two Hprops, flattens them into lists of names, simplifies the two lists by crossing off common names, and then returns the two Hprop's we get by collapsing the resulting simplified lists.

The following are various lemmas needed to reason about the interpretation of the syntax.

This is the key invariant for our simplify routine.

This is the proof that the cross_off algorithm is correct. That is, if we can prove that the resulting implication holds after crossing off, then the original implication holds.

Here is an example using the reflection. We have a large implication to prove that demands many re-associations, commutations, etc. So we first build an hmap from numbers to hprops, then we build syntax that parallels the predicates, being sure to use the right atoms according to the hmap, and finally we invoke the cross_off_corr lemma to get a much simplified routine. In this case, the simplification gets everything down to emp ==> emp.