Certified Typechecking in Foundational Certified Code Systems Susmit

Certified Typechecking in Foundational Certified Code Systems Susmit Sarkar Carnegie Mellon University

Motivation : Certified Code Producer different untrustedfrom by Code Consumer Because I can prove it is safe! Producer n Certificate Code Why should I trust the code? Consumer Solution : Package certificate with code

Certificate is machine-checkable proof of safety n Key questions: n n What is “safety” ? How to produce the certificate ? How to check the certificate ?

Safety Policy Consumer’s definition of safety n We check compliance with safety policy n n n Any complying program assumed safe Trusted Component

What is the Safety Policy? Old answer : trusted type system n Checking compliance is easy n Published (usually) proof of soundness of the system n n Any well-typed program is safe to execute

Problems n Stuck with one type system n n And stuck with its limitations Robustness issues n n Is type safety proof valid? Is the typechecker correct?

Foundational Certified Code Safety Policy : concrete machine safety n No trusted type system n Prove code is safe on machine n

Engineering Safety Proof n Use type technology in proof Specific Code Generic Type Is safe to Type execute on. Type Checking Safety System Machine

Type Safety Previous work [CADE ’ 03] n We use syntactic method (based on operational semantics) n n n Semantic methods also possible [Appel et al] We formalize our proofs in Twelf metalogics n Other choices possible [Appel et al, Shao et al]

Approaches to Program-Specific Proof Typing derivations n Typechecking n Typed Logic Programs n Functional typecheckers n

Typing Derivations Send typing derivations n Check these are well-formed n Problem : derivations are huge in size! n

Typechecking in Fixed Type System Specify a trusted type checker n Usually informal soundness argument n In our system n n n 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 n LF is designed for representing logics n n 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. Type. : of (app E 1 E 2) T 12 <- of E 1 (arrow T 11 T 12) <- of E 2 T 2 <- tp_eq T 11 T 2. : of (lam T 1 E) (arrow T 1 T 2) <- ({x: term} of x T 1 -> of (E x) T 2).

Type Checking : Logic Programming n An LF signature can be given an operational interpretation n n 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. Type. : of (app E 1 E 2) T 12 <- of E 1 (arrow T 11 T 12) <- of E 2 T 2 <- tp_eq T 11 T 2. : of (lam T 1 E) (arrow T 1 T 2) <- ({x: term} of x T 1 -> of (E x) T 2). %solve DERIV : of (lam unit. Type ([x: tm] unit)) TP.

Certified Type Checking LF is strongly typed and dependently typed n Partial Correctness [cf Appel & Felty] is ensured n Dependent Types allow stating (and verifying) such constraints n The logic program is a certified type checker n

Problems with Logic Programming n Typechecker has to run on consumer side n Once per program Requirement: minimize time overhead n Problem : Logic programming is slow n n n Higher-order Twelf adds more problems Not tuned for particular problem

Solution : Functional Typechecker n We want a functional typechecker n In a language similar to SML Can be tuned to application n Can be efficient and fast (we expect) n

Language desiderata Close to ML (mostly functional, datatypes, module language) n Dependent Types n Expresses LF types n Static typechecking n

Indexed Types (DML) DML types [Xi ] over index domain n Our index domain : LF terms n Recall: user is code producer in our application n 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 ‘t 1 ‘t 2) (App t 1 t 2) = let val <‘ty 1, 'd 1, TY 1> = typecheck ctx ‘t 1 val <‘ty 2, 'd 2, TY 2> = typecheck ctx ‘t 2 in case TY 1 of Ty. Arrow (‘ty 11, ‘ty 12, TY 11, TY 12) => let val <‘d 3, ()> = (eq. Type ‘ty 11 ‘ty 2 TY 11 TY 2) in <`ty 12, (of_app ‘d 1 ‘d 2 `d 3), TY 12> end | _ => error end |. . .

Problem: Open Terms What about terms that add binding? Consider the usual rule for abstraction: . . . | typecheck ctx (Lam ty 1 e 2) = let val ctx’ = addbinding ctx ty 1 val ty 2 = typecheck ctx’ e 2 in Ty. Arrow (ty 1, ty 2) end

Open Terms … contd. n Higher-order abstract syntax will use the LF context n Inefficient solution : Express everything in firstorder We need a handle on the context n Solution: Make LF contexts a separate index domain n

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 (lam ‘ty 1 ‘e 2) (Lam ty 1 e 2) = let val <‘ctx 1, ctx 1> = addbinding ‘ctx ‘ty 1 val <‘ty 2, ‘d, ty 2> = typecheck ‘ctx 1 ‘e 2 in <tyarrow(‘ty 1, ‘ty 2), (of_lam ‘d), Ty. Arrow (ty 1, ty 2)> end

Related Work n Foundational Certified Code Systems n FPCC : Appel et al. n n LF based typechecking Convert to Prolog for speed FTAL : Shao et al Partial Correctness of Theorem Provers [Appel & Felty]

Related Work (contd. . . ) n Dependent Types in ML [Xi et al, Dunfield] n n Simpler Index domains EML [Sinnella & Tarlecki] n Boolean tests for assertions