Certified Typechecking in

Foundational Certified Code Systems

Susmit Sarkar

Carnegie Mellon University

Motivation : Certified Code

Solution : Package certificate with code

Producer ConsumerCode

Certificate

Code Producer Code Consumerdifferent from untrusted by

Why should I trust the code?

Because I can prove it is safe!

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

Code MachineIs safe to execute onType System

Type Checking

Type Safety

Specific Generic

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 Lambdaof : term -> tp -> type.

of_unit : of unit unitType.of_app : of (app E1 E2) T12 <- of E1 (arrow T11 T12) <- of E2 T2 <- tp_eq T11 T2.of_lam : 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 Lambdaof : term -> tp -> type.

of_unit : of unit unitType.of_app : of (app E1 E2) T12 <- of E1 (arrow T11 T12) <- of E2 T2 <- tp_eq T11 T2.of_lam : 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 Lambdatypecheck : 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 first-

order

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