Crowfoot: a verifier for higher
order store programs
Billiejoe (Nathaniel) Charlton
Ben Horsfall
Bernhard Reus
University of Sussex
VMCAI 2012
Outline
•
Background on Higher Order Store (HOS)
- What is HOS? Why should I care?
- Reasoning about HOS programs: Hoare logic with nested triples
•
Automated reasoning in Hoare logics with nested triples
- What are the difficulties?
- How we address them in our Crowfoot tool
•
Some things we have verified using Crowfoot
What is higher order store?
•
A programming language is said to feature HOS when:
a program’s code / commands / procedures are part of the
mutable store which the program manipulates as it runs
What is higher order store?
•
A programming language is said to feature HOS when:
a program’s code / commands / procedures are part of the
mutable store which the program manipulates as it runs
•
So HOS programs can modify their own code while running
What is higher order store?
•
A programming language is said to feature HOS when:
a program’s code / commands / procedures are part of the
mutable store which the program manipulates as it runs
•
So HOS programs can modify their own code while running
•
Where does HOS occur?
- in functional languages with mutable higher order state e.g. ML
- dynamic loading and unloading of code e.g. Plugins, OSes
- “hot update” – updating a program while it is running
- runtime code generation
square brackets indicate heap access
square brackets indicate heap access
stores procedure
onto the
heap, possibly doing partial
application at the same time
square brackets indicate heap access
stores procedure
onto the
heap, possibly doing partial
application at the same time
runs the procedure stored in the heap
at address , with arguments
square brackets indicate heap access
stores procedure
onto the
heap, possibly doing partial
application at the same time
ordinary procedure call
runs the procedure stored in the heap
at address , with arguments
But what should we write here?
We need to describe the code
which must be stored on the
heap at address f
First attempt: says exactly
which code is stored at f.
But only allows us to invoke
P if we’re adding 10! 
Second attempt: better.
But still not really satisfying.
Doesn’t seem like a generic
specification.
Instead, we use a nested Hoare triple to
talk about the behaviour of the code,
rather than which exact code it is.
Instead, we use a nested Hoare triple to
talk about the behaviour of the code,
rather than which exact code it is.
Instead, we use a nested Hoare triple to
talk about the behaviour of the code,
rather than which exact code it is.
Nested triples first
appear in work by
Honda, Yoshida
and Berger; later
developments by
many others.
Our tool Crowfoot
•
Our tool Crowfoot implements (semi-) automated verification of HOS
programs, using nested triples
•
Employs symbolic execution with separation logic technique, as in
Smallfoot, VeriFast, jStar ...
•
What issues did we face in implementing Crowfoot?
Issues for implementation
•
Assertion language: must include nested triples but still be restricted
enough that automated reasoning is possible
Assertion language
Assertion language
This is all circular! So triples can be nested to arbitrary depth.
Issues for implementation
•
Assertion language: must include nested triples but still be restricted
enough that automated reasoning is possible
•
New symbolic execution rules for the HOS statements: those which
write code to the heap, and invoke code stored on the heap
Issues for implementation
•
Assertion language: must include nested triples but still be restricted
enough that automated reasoning is possible
•
New symbolic execution rules for the HOS statements: those which
write code to the heap, and invoke code stored on the heap
•
Entailment prover for assertions involving nested triples
Consider the following entailment between symbolic states:
Consider the following entailment between symbolic states:
Consider the following entailment between symbolic states:
We need to find c to make this entailment between specifications hold:
Consider the following entailment between symbolic states:
We need to find c to make this entailment between specifications hold:
So, unlike in existing tools
-
Solving entailments between symbolic states requires solving
entailments between specifications
-
And vice versa
Issues for implementation
•
Assertion language: must include nested triples but still be restricted
enough that automated reasoning is possible
•
New symbolic execution rules for the HOS statements: those which
write code to the heap, and invoke code stored on the heap
•
Entailment prover for assertions involving nested triples
•
Recursive specifications for programs which perform “recursion through
the store”
Issues for implementation
•
Assertion language: must include nested triples but still be restricted
enough that automated reasoning is possible
•
New symbolic execution rules for the HOS statements: those which
write code to the heap, and invoke code stored on the heap
•
Entailment prover for assertions involving nested triples
•
Recursive specifications for programs which perform “recursion through
the store”
•
Implementing the deep frame rule
Provers: the
of Crowfoot
At its heart, crowfoot implements provers for five related judgements.
1. Symbolic execution:
Provers: the
of Crowfoot
At its heart, crowfoot implements provers for five related judgements.
1. Symbolic execution:
predicate definitions,
procedure context
Provers: the
of Crowfoot
At its heart, crowfoot implements provers for five related judgements.
1. Symbolic execution:
predicate definitions,
procedure context
For example:
2. Entailment between symbolic states:
I maps existentially bound variables
to appropriate instance
Inferred frame
2. Entailment between symbolic states:
I maps existentially bound variables
to appropriate instance
For example:
Inferred frame
2. Entailment between symbolic states:
I maps existentially bound variables
to appropriate instance
For example:
Inferred frame
2. Entailment between symbolic states:
I maps existentially bound variables
to appropriate instance
For example:
3. Entailment between specifications:
For example:
Inferred frame
4. Computing the post-condition for a ‘call’ or ‘eval’:
specification of
routine about
to be run
current symbolic state
4. Computing the post-condition for a ‘call’ or ‘eval’:
specification of
routine about
to be run
current symbolic state
For example:
4. Computing the post-condition for a ‘call’ or ‘eval’:
specification of
routine about
to be run
current symbolic state
For example:
4. Computing the post-condition for a ‘call’ or ‘eval’:
specification of
routine about
to be run
current symbolic state
For example:
5. Finding a nested triple to use with ‘eval’:
current symbolic state
address of
code on heap
to be run
4. Computing the post-condition for a ‘call’ or ‘eval’:
specification of
routine about
to be run
current symbolic state
For example:
5. Finding a nested triple to use with ‘eval’:
For example:
current symbolic state
address of
code on heap
to be run
4. Computing the post-condition for a ‘call’ or ‘eval’:
specification of
routine about
to be run
current symbolic state
For example:
5. Finding a nested triple to use with ‘eval’:
For example:
current symbolic state
address of
code on heap
to be run
Two of the proof rules
Recursion through the store
•
Recursion through the store is when code on the heap invokes itself
through a pointer
•
Specifications for such code needs to appear in their own preconditions!
•
Crowfoot allows the declaration of such specifications:
The deep frame rule
•
The deep frame rule (introduced by Birkedal, Torp-Smith and Yang)
allows adding invariants to a specification
- like the regular frame rule
- but the invariant is added at all nesting levels
- allows some very nice modular proofs
- we’ve implemented this in Crowfoot
The deep frame rule
•
The deep frame rule (introduced by Birkedal, Torp-Smith and Yang)
allows adding invariants to a specification
- like the regular frame rule
- but the invariant is added at all nesting levels:
- allows some very nice modular proofs
- we’ve implemented this in Crowfoot
Some things we have verified
We have used Crowfoot to verify for example (models of):
•
A generic memoiser for recursive functions (see the paper)
- Makes very neat use of deep frame rule
•
Updateable web server
- A server which can be updated without stopping it running
•
Programs that load and unload plugins as they run
•
Higher order expression evaluator
Try Crowfoot online
www.sussex.ac.uk/informatics/crowfoot
The End
Main rule for
Main rule for
Main rule for
Main rule for
Main rule for