An IsabelleHOL Framework for Proof Carrying Code

1
An Isabelle/HOL Frameworkfor Proof Carrying Code

• Martin Wildmoser
• 16.4.2003

2
Contents

• Proof Carrying Code (PCC)
• PCC Framework
• Live Demo
• Conclusion

3
Motivation

• Problem Untrusted Code
• Solution Certification

A Proof Carrying Code (PCC) system checks and
assists the construction of certificates (proofs)
that guarantee a program's safety at runtime.
4
Proof Carrying Code Overview
serves as certificate
Producer
Consumer

• receives a program and a proof object
• generates vc
• checks whether the
• proof fits vc.

• produces annotated programs
• generates verification condition (vc)
• proves vc

5
Common factors in PCC Systems

• A PCC System depends on
• The Programming Language(syntax and semantics of
  annotated programs)
• The Safety Policy(conditions programs must
  satisfy)
• The Safety Logic(formal notation and derivation
  calculus for formulas characterising machine
  states)

6
A Framework for PCC

• takes Programming Language, Safety Policy and
  Safety Logic as parameters.
• provides skeletons for PCC components
• states assumptions that guarantee soundness.

7
Our PCC Framework ...
requires a Safety Policy in form of a predicate
on states
declares functions and states assumptions for a
Safety Logic.
declares functions for an Interpreter
defines and verifies a verification condition
generator.
8
Interpreter Framework

• interprets programs as state machines (I,S,T).
• I predicate describing initial states
• S predicate describing safe states
• T small step execution relation

9
Safety of Programs
Started on a safe initial state a safe state
machine only reaches safe states.
A program is safe iff its state machine is safe.
A PCC system helps answering and checks the
answer for this question
?
10
Example MicroAssembler (MA)
Syntax of MA programs.
A program that eventually sets X to the maximum
of X and Y.
11
MA Semantics and Safety Policy
All initial values are bounded by the maximum
value MX.
Safety Policy The INC instruction at position 1
in our example program must not overflow.
The execution relation for our example program
12
Safety Logic Framework

• A Safety Logic needs ...
• constants for truth values
• conjunction and implication
• judgements for provability and validity of
  formulas.

If a Safety Logic provides these functions and
satisfies these assumptions we can guarantee
soundness later on.
13
Example MA Safety Logic
We instantiate Isabelle/HOL as a Safety Logic for
MA.
expresses that s lies on a trace of length n
starting at some initial state s0 and all
states on this trace satisfy the precondition
preF prg(which we define later on)
14
VC Generator Framework

• The Verification Condition Generator (VCG) ...
• takes an annotated program as input
• returns a Safety Logic formula as verification
  condition.

Soundness Theorem for the VCG
expresses that each loop in prg has at least
oneannotated position
15
VCG Framework (2)

• The VCG ...
• views programs as directed graphs (positions,
  edges to successors)
• expects annotations at each exit position and
  once per loop.
• respects branch conditions, which specify what
  successors are accessible from a particular
  state.

our exampleprogram in anabstract view
positions
edges branch conditions
16
VCG Framework (3)

• For the verification condition we need
• Annotations anF
• Safety Policy appF (appI encoded as SL formula)
• Weakest Precondition Operator wpF (semantics
  encoded as SL formula)

Annotations of our example program.
Overflow Safety as a Safety Logic formula..
To express the effect of a program prg at a
position pc with successor pc in the Safety
Logic, we have to construct a (weakest)
precondition
wpF prg pc pc Q , which
guarantees
post condition Q at pc.
17
VCG Assumptions

• To guarantee soundness our VCG assumes
• succsF returns all successor positions that
  are accessible at runtime
• A provable formula holds for any state on trace
  of safe states.
• the logical Safety Policy appF implies the
  dynamic one appI.
• the wpF Operator computes the a valid
  precondition

18
Constructing Preconditions
At least one position in each loop must be
annotated in order to guarantee termination of
preF. The partialAnnotationConstraints express
this condition formally.
19
Example Constructed Preconditions
Here are the constructed preconditions for
positions 0 and 2 of our example program.
20
Constructed Preconditions (2)
This is the preconditon for position 1 in our
example program.
21
Verification Condition Generation
VC For every annotated position the pre- and
branch condition must imply the precondition for
each successor after executing the current
instruction.
22
Example Verification Condition
The VC Pattern for our example program.
In the real VC the branch conditionsand the
terms for wpF and preF would be expanded.
23
LIVE DEMO
In this demo we will ...

• write a MA program in Isabelle
• generate code for the vcg
• compute the vc for the example
• verify the vc
• check the vc against its proof object

24
Conclusion

• Summary
• Future Work

25
Summary

• Features of our PCC Framework
• Programming Language, Safety Policy and Safety
  Logic as parameters.
• Executable VCG (generated from Isabelle)
• Machine Checked VCG

26
Summary (2)

• Problems and their reasons
• Huge verification conditionsReasons - missing
  annotations (-gt more paths)
• - delay of simplifications
  due to shallow embedding
  (structure of HOL formulas
  cannot be exploited)
• Huge proof objectsReasons - Huge verification
  conditions - unnecessary
  simplifications
• Problems in Code GenerationReason Shallow
  Embedding complicates distinction
  between HOL and Safety Logic.Solution Use
  quotations and antiquotations (term, toterm)

27
Future Work

• Increasingly powerful platforms
• - procedures (done by now)
• - computed jumps (idea interval types)
• - real world machine (DLX, x86, Java Bytecode,
  .net)
• Compression of verification conditions.
  (Sharing?)
• Assist the code producer
• - Automatic annotations (as compiler output)
• - Automatic proofs for Runtime and Space
  Properties.