Certified Typechecking in Foundational Certified Code Systems Susmit Sarkar Carnegie Mellon University Motivation : Certified Code Code Producer different untrustedfrom by Code Consumer Because I can prove it is safe! Certificate Producer Code Why.
Download
Report
Transcript Certified Typechecking in Foundational Certified Code Systems Susmit Sarkar Carnegie Mellon University Motivation : Certified Code Code Producer different untrustedfrom by Code Consumer Because I can prove it is safe! Certificate Producer Code Why.
Certified
Typechecking in
Foundational Certified
Code Systems
Susmit Sarkar
Carnegie Mellon University
Motivation : Certified Code
Code Producer different
untrustedfrom
by Code Consumer
Because I can
prove it is safe!
Certificate
Producer
Code
Why should I
trust the code?
Consumer
Solution : Package certificate with code
Certificate
Certificate is machine-checkable proof of
safety
Key questions:
What is “safety” ?
How to produce the certificate ?
How to check the certificate ?
Safety Policy
Consumer’s definition of safety
We check compliance with safety policy
Any complying program assumed safe
Trusted Component
What is the Safety Policy?
Old answer : trusted type system
Checking compliance is easy
Published (usually) proof of soundness of
the system
Any well-typed program is safe to execute
Problems
Stuck with one type system
And stuck with its limitations
Robustness issues
Is type safety proof valid?
Is the typechecker correct?
Foundational Certified Code
Safety Policy : concrete machine safety
No trusted type system
Prove code is safe on machine
Engineering Safety Proof
Use type technology in proof
Specific
Code
Generic
Type Is safe to
Type
execute onType
Checking
Safety
System
Machine
Type Safety
Previous work [CADE ’03]
We use syntactic method (based on
operational semantics)
Semantic methods also possible [Appel et al]
We formalize our proofs in Twelf metalogics
Other choices possible [Appel et al, Shao et al]
Approaches to Program-Specific Proof
Typing derivations
Typechecking
Typed Logic Programs
Functional typecheckers
Typing Derivations
Send typing derivations
Check these are well-formed
Problem : derivations are huge in size!
Typechecking in Fixed Type System
Specify a trusted type checker
Usually informal soundness argument
In our system
Do not have a single trusted type system
Type system may be sound, but not the type
checker
Representing Type Systems
A Type System is a particular logic
LF is designed for representing logics
A dependently typed language
Uses higher-order abstract syntax
Types of LF correspond to judgments of logic
Example : Simply Typed Lambda
of : term -> tp -> type.
of_unit
of_app
of_lam
: of unit unitType.
: of (app E1 E2) T12
<- of E1 (arrow T11 T12)
<- of E2 T2
<- tp_eq T11 T2.
: of (lam T1 E) (arrow T1 T2)
<- ({x:term} of x T1 -> of (E x) T2).
Type Checking : Logic Programming
An LF signature can be given an
operational interpretation
This gives us a (typed, higher-order) logic
programming language
Idea : Use this as a type checker
Example : Simply Typed Lambda
of : term -> tp -> type.
of_unit
of_app
of_lam
: of unit unitType.
: of (app E1 E2) T12
<- of E1 (arrow T11 T12)
<- of E2 T2
<- tp_eq T11 T2.
: of (lam T1 E) (arrow T1 T2)
<- ({x:term} of x T1 -> of (E x) T2).
%solve DERIV : of (lam unitType ([x:tm] unit)) TP.
Certified Type Checking
LF is strongly typed and dependently typed
Partial Correctness [cf Appel & Felty] is
ensured
Dependent Types allow stating (and
verifying) such constraints
The logic program is a certified type
checker
Problems with Logic Programming
Typechecker has to run on consumer side
Once per program
Requirement: minimize time overhead
Problem : Logic programming is slow
Higher-order Twelf adds more problems
Not tuned for particular problem
Solution : Functional Typechecker
We want a functional typechecker
In a language similar to SML
Can be tuned to application
Can be efficient and fast (we expect)
Language desiderata
Close to ML (mostly functional, datatypes,
module language)
Dependent Types
Expresses LF types
Static typechecking
Indexed Types (DML)
DML types [Xi ] over index domain
Our index domain : LF terms
Recall: user is code producer in our
application
explicit annotations are okay
Make typechecking as easy as possible
Example: Simply Typed Lambda
typecheck : Context
-> Pi ‘tm:LF(term). Term (‘tm)
-> Sigma ‘tp:LF(tp). Sigma ‘d:LF(of ‘tm ‘tp).
Tp (‘tp)
fun typecheck ctx (app ‘t1 ‘t2) (App t1 t2) =
let
val <‘ty1,'d1,TY1> = typecheck ctx ‘t1 t1
val <‘ty2,'d2,TY2> = typecheck ctx ‘t2 t2
in
case TY1 of
TyArrow (‘ty11, ‘ty12, TY11,TY12) =>
let
val <‘d3,()> = (eqType ‘ty11 ‘ty2 TY11 TY2)
in <`ty12,(of_app ‘d1 ‘d2 `d3),TY12> end
| _ => error
end
| ...
Problem: Open Terms
What about terms that add binding?
Consider the usual rule for abstraction:
...
| typecheck ctx (Lam ty1 e2) =
let
val ctx’ = addbinding ctx ty1
val ty2 = typecheck ctx’ e2
in
TyArrow (ty1, ty2)
end
Open Terms … contd.
Higher-order abstract syntax will use the LF
context
Inefficient solution : Express everything in firstorder
We need a handle on the context
Solution: Make LF contexts a separate
index domain
Example … contd.
typecheck : Pi ‘ctx:LF(context). Context
-> Pi ‘tm:LF(‘ctx ` term). Term (‘tm)
-> Sigma ‘tp:LF(‘ctx ` tp).
Sigma ‘d:LF(‘ctx ` of ‘tm ‘tp). Tp (‘tp)
...
| typecheck ‘ctx ctx (lam ‘ty1 ‘e2) (Lam ty1 e2) =
let
val <‘ctx1,ctx1> = addbinding ‘ctx ctx ‘ty1 ty1
val <‘ty2,‘d,ty2> = typecheck ‘ctx1 ctx1 ‘e2 e2
in
<tyarrow(‘ty1,‘ty2),(of_lam ‘d), TyArrow (ty1,
ty2)>
end
Related Work
Foundational Certified Code Systems
FPCC : Appel et al.
LF based typechecking
Convert to Prolog for speed
FTAL : Shao et al
Partial Correctness of Theorem Provers
[Appel & Felty]
Related Work (contd...)
Dependent Types in ML [Xi et al, Dunfield]
Simpler Index domains
EML [Sinnella & Tarlecki]
Boolean tests for assertions