Create Presentation
Download Presentation

Download Presentation

Certified Typechecking in Foundational Certified Code Systems

Download Presentation
## Certified Typechecking in Foundational Certified Code Systems

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -

**Certified Typechecking in Foundational Certified Code**Systems Susmit Sarkar Carnegie Mellon University**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**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 Generic Type Checking Type Safety Is safe to execute on Code Type 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 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 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.**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 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