foundational certified code in a metalogical framework karl crary and susmit sarkar carnegie mellon...
TRANSCRIPT
Foundational Certified Code in a Metalogical
FrameworkKarl Crary and Susmit Sarkar
Carnegie Mellon University
2
Motivation: Grid Computing Make use of idle computing cycles over the
network [e.g. SETI] Computer owners download and execute
code from developers A key issue: Unknown developers, so
consumers are concerned about safety
3
Certified code
Package the code with certificate [PCC, TAL] Certificate: a machine verifiable proof of safety
Typically, proof that code is well-typed in a safe type system
Developer ConsumerCode
Certificate
Is code safe ?
Knowledge Code is safe!
4
Type System? Is that safe? Old Answer: Fix a type system, trust peer-review
New Answer: Give developers flexibility of using their own type systems Need to check this is safe Known as Foundational Certified Code
Developer Consumer
Machine details
Type SystemType System
Code
Certificate
5
Roadmap Our system Metalogics Safety Policy A Safety Proof Related and future work
6
Our System
Developer
Certificate
Code Consumer
Safety PolicySafety Condition
Does Code satisfy the
Safety Policy?
Code satisfies my Safety Condition
Why is your safety condition
any good?
I can prove it to you!
Safety Proof
7
Metalogic : meta theorems We use LF to express logics
e.g., operational semantics producer’s safety conditions
We care about meta theorems: If some input derivation exists, then an output
derivation exists e.g., Safety Theorem
8
How to check meta theorems? Choice 1: reflect metalogical reasoning in
the framework Choice 2: use a logic designed for
metalogical reasoning e.g. Twelf [Schurmann]
9
Programming in Meta logics We write logic programs relating derivations
limited to -1 reasoning, authors plan stronger system
Need to do induction on structure of derivation
System can check these logic programs are total (user annotations required)
10
Roadmap Our system Metalogics Safety policy A safety proof Related and future work
11
Safety policy - Preliminaries Formalize operational semantics of the
IA32 architecture Formalize machine states: memory,
register files, stack, instruction pointer Formalize transitions from state to state Remove transitions deemed unsafe
12
Example: transition for addition addl $5,(%eax)
load 4 bytes from (%eax), load immediate operand 5, add them, store result back in (%eax), update EFLAGS and advance EIP
This can go wrong, e.g. if eax points to protected memory
Solution: The formal load and store relations do not apply in such cases
13
Safety Policy Define initial state on loading program P We never get to a state where the (formal)
machine does not have a transition Another way of stating: the formal machine
is never stuck Halt state treated specially
14
Why is this safe? Real machine’s transitions according to
formal machine’s transitions: real machine is performing safe operations
To perform unsafe operations, real machine takes a transition not in formal machine
This does not happen in a safe machine
15
Roadmap Our system Metalogics Safety policy A safety proof Related and future work
16
Example Safety Proof A particular safety proof Our safety proof is for TALT [Crary]
Type system for an assembly language Fairly low-level, but still abstract
Our foundational safety proof is syntactic [Hamid et al.]
17
Safety Our conditions will isolate a set of safe
states Safe states cannot transition to stuck states
Safe State M1 State M2
18
Key Lemmas Progress
Preservation
Safe State M1 State M2
Safe
Safe State M1 State M2
19
Putting it together – Safety Theorem
Transitions from a safe state cannot go to a stuck state
Safe State M1 State M2
Safe
20
Idea of proof Safe machine
Three parts of the proof Abstract Type Safety (previous work) Simulation Determinism
Safe State M
Typed abstract M’
implements
21
TALT safety proof [Crary] This has two top level lemmas: Progress: A well typed abstract machine
makes a transition Preservation: If a well typed abstract
machine makes a transition, the resulting (abstract) machine is well typed
22
Concrete Machine Lemmas Simulation
Determinism
Abstract M2
Concrete M2’Concrete M1’
Abstract M1
Concrete M1
Concrete M2
Concrete M2’
23
Progress
Safe State M1 State M2
Abstract, typed M1’ Abstract M2’
implements
progress
implements
State M2
24
Preservation
Safe State M1 State M2Safe
implementsimplements
Typed abstract M1’ Typed Abstract M2’progress
M2+
implements
Safe
25
Implementation Statistics Safety Policy : 2,081 lines of code Safety Proof : 44,827 lines of code Time to check : 75 sec Number of lemmas : 1,466 Man years : 1 and 1/2
26
Related work Foundational PCC - Appel et al FTAL - Hamid et al Temporal Logic PCC - Bernard and Lee
27
Future Work Develop a compiler from Standard ML to
TALT Expand the target language to include
many more IA32 instructions Specify and prove other properties, e.g.
Running time bounds
28
29
Indeterminism The data may be indeterminate, due to e.g.
input Safety demands that any instance be safe We have an oracle that the semantics
consults to determine what to do Oracle is quantified in safety theorem