Changing perspective can be useful

Relating alternative logics for automatic software verification

Alex Summers (ETH Zurich) partly based on joint work with Matthew Parkinson and Daniel Jost

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

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

v

x.f

Separation Logic

• Separating conjunction connective *• A*B means A and B hold in disjoint heaps• e.g., x.f ↦ v * y.f ↦ 5

the disjointness guarantees: x and y are not aliasesh A*B iff ⊨ ∃h1,h2.(h=h1 h⊎ 2 and h1 A and h⊨ 2 B)⊨

y.f

v

x.f

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

• For exampleacc(x.f) * x.f = 4 * acc(x.g)

Implicit Dynamic Frames

• For exampleacc(x.f) * x.f = 4 * acc(x.g)

x.f

Implicit Dynamic Frames

• For exampleacc(x.f) * x.f = 4 * acc(x.g)

x.f

Implicit Dynamic Frames

• For exampleacc(x.f) * x.f = 4 * acc(x.g)

4

x.f

Implicit Dynamic Frames

Implicit Dynamic Frames

• For exampleacc(x.f) * x.f = 4 * acc(x.g)

4

x.f x.g

Implicit Dynamic Frames

• For exampleacc(x.f) * x.f = 4 * acc(x.g)

• Expressions include heap dereferences

4

x.f x.g

Implicit Dynamic Frames

• For exampleacc(x.f) * x.f = 4 * acc(x.g)

• Expressions include heap dereferences• Permissions need not match “read footprint”

4

x.f x.g

Implicit Dynamic Frames

• For exampleacc(x.f) * x.f = 4 * acc(x.g) * y.f = 3

• Expressions include heap dereferences• Permissions need not match “read footprint”

4

x.f x.g

Implicit Dynamic Frames

• For exampleacc(x.f) * x.f = 4 * acc(x.g) * y.f = 3

• Expressions include heap dereferences• Permissions need not match “read footprint”

3y.f

x.g

4

x.f

Self-framing assertionsAn IDF assertion is self-

framing if:For any state in which

the assertion is true,

Self-framing assertionsIDF total heap

4

3 2

7

4

3 2

7

0 0

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

IDF total heap

4

3 2

7

9

3 2

1

4 1

Self-framing assertionsAn 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

Self-framing assertionsIDF total heap

4

3 2

7

8 4

2 1

6 2

5

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

Self-framing assertionsIDF total heap

4

3 2

7

4

3 2

7

0 0

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

Self-framing assertionsSeparation Logic partial heap

4

3 2

7

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

A*B

Separation Logic partial heap

AB

IDF total heap

AB

A*B

Separation Logic partial heap IDF total heap

AB

AB

A*B

Separation Logic partial heap IDF total heap

AB

AB

4

3 2

7 4

3 2

7

4

3 2

7

0 0

Idea: x.f ↦ v ⇔ acc(x.f) * x.f = v

The “Magic Wand”

Separation Logic partial heapAn assertion A ― B means:“If, to the current heap, we add a disjoint heap satisfying A then the resulting heap is guaranteed to satisfy B”

Or: h A ― B iff ⊨h’ h.( h’ A h h’ ∀ ⊥ ⊨ ⇒ ⊎ ⊨

B)

Separation Logic partial heap

A

The “Magic Wand”

An assertion A ― B means:“If, to the current heap, we add a disjoint heap satisfying A then the resulting heap is guaranteed to satisfy B”

Or: h A ― B iff ⊨h’ h.( h’ A h h’ ∀ ⊥ ⊨ ⇒ ⊎ ⊨

B)

Separation Logic partial heap

A

The “Magic Wand”

An assertion A ― B means:“If, to the current heap, we add a disjoint heap satisfying A then the resulting heap is guaranteed to satisfy B”

Or: h A ― B iff ⊨h’ h.( h’ A h h’ ∀ ⊥ ⊨ ⇒ ⊎ ⊨

B)

Separation Logic partial heap

A

B

The “Magic Wand”

An assertion A ― B means:“If, to the current heap, we add a disjoint heap satisfying A then the resulting heap is guaranteed to satisfy B”

Or: h A ― B iff ⊨h’ h.( h’ A h h’ ∀ ⊥ ⊨ ⇒ ⊎ ⊨

B)

Separation Logic partial heap IDF total heap

A

B

The “Magic Wand”

Separation Logic partial heap IDF total heap

A ?

B

A

The “Magic Wand”

IDF total heap

A ?

How to model heap extension?

Idea 1:

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

IDF total heap

A ?

How to model heap extension?

Idea 2:

Assign new (arbitrary) values to unreadable heap locations, and then add new permissions

Problem:In IDF, A may involve heap-dependent expressions

IDF total heap

A ?

How to model heap extension?

Idea 2:

Assign new (arbitrary) values to unreadable heap locations, and then add new permissions

Problem:In IDF, A may involve heap-dependent expressions

IDF total heap

A ?

How to model heap extension?

Idea 2:

Assign new (arbitrary) values to unreadable heap locations, and then add new permissions

Problem:In IDF, A may involve heap-dependent expressions

IDF total heap

A ?

How to model heap extension?

Idea 2:

Assign new (arbitrary) values to unreadable heap locations, and then add new permissions

Problem:In IDF, A may involve heap-dependent expressions

IDF total heap

A ?

How to model heap extension?

Idea 2:

Assign new (arbitrary) values to unreadable heap locations, and then add new permissions

Problem:In IDF, A may involve heap-dependent expressions

IDF total heap

A ?

How to model heap extension?

Idea 2:

Assign new (arbitrary) values to unreadable heap locations, and then add new permissions

Problem:In IDF, A may involve heap-dependent expressions

IDF total heap

A ?

How to model heap extension?

Idea 2:

Assign new (arbitrary) values to unreadable heap locations, and then add new permissions

Problem:In IDF, A may involve heap-dependent expressions

IDF total heap

A ?

How to model heap extension?

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

Idea 2:

Assign new (arbitrary) values to unreadable heap locations, and then add new permissions

Problem:In IDF, A may involve heap-dependent expressions

IDF total heap

How to model heap extension?

Minimal State Extensions

• Idea: only consider “extending” the state by the smallest amount possible

We modify the original semantics:h A ― B iff ⊨

∀ 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

Minimal State Extensions

• Idea: only consider “extending” the state by the smallest amount possible

We modify the original semantics to be:h A ― B iff ⊨

∀ 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

/

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 heaps semantics for Sep. Logic– suggests new implementation strategies

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)

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