Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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