Presentation on theme: "Certified Typechecking in Foundational Certified Code Systems Susmit Sarkar Carnegie Mellon University."— Presentation transcript:
Certified Typechecking in Foundational Certified Code Systems Susmit Sarkar Carnegie Mellon University
Motivation : Certified Code Solution : Package certificate with code ProducerConsumer Code Certificate Code Producer Code Consumer different 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 Machine Is safe to execute on Type System Type Checking Type Safety SpecificGeneric
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]
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) 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) 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 = typecheck ctx ‘t1 t1 val = typecheck ctx ‘t2 t2 in case TY1 of TyArrow (‘ty11, ‘ty12, TY11,TY12) => let val = (eqType ‘ty11 ‘ty2 TY11 TY2) in 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 = addbinding ‘ctx ctx ‘ty1 ty1 val = typecheck ‘ctx1 ctx1 ‘e2 e2 in 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
Your consent to our cookies if you continue to use this website.