Certified Typechecking in Foundational Certified Code Systems

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

2. Motivation : Certified Code • Solution : Package certificate with code Code Producer untrusted by different from Code Consumer Because I can prove it is safe! Why should I trust the code? Certificate Code Producer Consumer

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

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

5. 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

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

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

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

9. 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]

10. Approaches to Program-Specific Proof • Typing derivations • Typechecking • Typed Logic Programs • Functional typecheckers

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

12. 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

13. 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

14. Example : Simply Typed Lambda of : 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).

15. 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

16. Example : Simply Typed Lambda of : 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.

17. 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

18. 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

19. 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)

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

21. 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

22. 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 | ...

23. 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

24. 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

25. 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

26. 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]

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