Download slides, ppt - Susmit Sarkar

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