1 / 39

A Cost-Effective Foundational Certified Code System

A Cost-Effective Foundational Certified Code System. Susmit Sarkar Thesis Proposal. Motivation: Grid Computing. Idle computing cycles over the network [e.g. SETI] Code Consumers download and execute code from Code Producers Code Producers not trusted, or known. Solution : Certified Code.

rhona
Télécharger la présentation

A Cost-Effective Foundational Certified Code System

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A Cost-Effective Foundational Certified Code System Susmit Sarkar Thesis Proposal Susmit Sarkar

  2. Motivation: Grid Computing • Idle computing cycles over the network [e.g. SETI] • Code Consumers download and execute code from Code Producers • Code Producers not trusted, or known Susmit Sarkar

  3. Solution : Certified Code • Solution : Package certificate with code [Necula] Because I can prove it is safe! Why should I trust the code? Certificate Producer Code Consumer Susmit Sarkar

  4. Safety Policy • Certify compliance with Safety Policy • Define what is “safe” • Trusted Component of system Susmit Sarkar

  5. Traditional Certified Code : Architecture • Safety Policy = Trusted Type System Annotations Concrete Machine Type System Producer Code Consumer Susmit Sarkar

  6. Problems with Traditional Approach • Flexibility : One Type System (and its limitations) • Safety : Proof of Type Safety not verified (usually) • Safety : Soundness of Type Checker not verified Susmit Sarkar

  7. Foundational Certified Code • Safety Policy = Formalized Concrete Machine [Appel & Felty] Certificate Concrete Machine Producer Code Consumer Susmit Sarkar

  8. Important Issue : Proof Size • We want small proofs • Transport over network • We want fast checking • Consumer side overhead • Previous Iterations of our system : problems on both accounts Susmit Sarkar

  9. Important Issue : Intellectual Effort • We want Reasonable Intellectual Effort • Proof Engineering task • FPCC Project has taken considerable man-years Susmit Sarkar

  10. Thesis Statement • A practical certified code system, with machine-checkable proofs of safety of code relative to a concrete machine architecture, can be built in a cost-effective manner, with proofs which are small enough to be packaged with code, fast to check, and with the proof infrastructure built with reasonable intellectual effort. Susmit Sarkar

  11. Proof Strategy : basic approach class Generic Proof Obligation Concrete Machine Here is a formalization! Prove your code is safe. Specific Proof Obligation Here is a class of programs Here is some code! Code Code Consumer Code Producer Susmit Sarkar

  12. Generic Proof [CADE ‘03] • Define Safety Policy • Subset of x86 Architecture • Define Generic System • TALT [Crary] • Prove Safety of Generic System w.r.t. Safety Policy Susmit Sarkar

  13. Representing Type Systems • A Type System is a particular logic • So is the Safety Policy • LF is designed for representing logics • A dependently typed language • Uses higher-order abstract syntax • Mature Implementation : Twelf Susmit Sarkar

  14. 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 the Twelf metalogic [Schürmann] • Other choices possible [Appel et al, Shao et al] Susmit Sarkar

  15. Approaches to Program-Specific Proof • Typing Derivations • (Typed) Logic Programs • Functional typecheckers Susmit Sarkar

  16. Approach : send direct proof • Problem : Proofs are huge! class How do I know your code belongs to this class ? proof checker Here is a proof proof Code Code Producer Code Consumer Susmit Sarkar

  17. Approach : Certified Type Checker • Need : Certified Type Checkers class Does the checker correctly implement the class ? How do I know your code belongs to this class ? Here is a checker for the class. Run it and see! checker Code Code Producer Code Consumer Susmit Sarkar

  18. Type Checking : Logic Programming • An LF signature can be given an operational interpretation • This gives us a (typed, higher-order) logic programming language [Appel & Felty] • Idea : Use this as a type checker Susmit Sarkar

  19. Example : Simply Typed Lambda of : term -> tp -> type. of_unit : of unitTerm unitType. of_app : of (app E1 E2) T12 <- of E1 (arrow T2 T12) <- of E2 T2. of_lam : of (lam T1 E) (arrow T1 T2) <- ({x:term} of x T1 -> of (E x) T2). Susmit Sarkar

  20. Example : Simply Typed Lambda of : term -> tp -> type. of_unit : of unitTerm 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). tp_eq : tp -> tp -> type. Susmit Sarkar

  21. A Type Checker of : term -> tp -> type. of_unit : of unitTerm 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:term] unit)) TP. Susmit Sarkar

  22. Certified Type Checking • LF : strongly typed and dependently typed • Partial Correctness [cf Appel & Felty] ensured • Dependent Types allow stating (and verifying) such constraints • Logic program = certified type checker Susmit Sarkar

  23. Problems with Logic Programming • Typechecker has to run on consumer side • Once per program • Requirement: minimize time overhead • Problem : Logic programming is slow • Control limited to depth first search • Higher-order Twelf adds more problems • Not tuned for particular problem Susmit Sarkar

  24. Solution : Functional Typechecker • We want a functional typechecker • Can be tuned to application • Can be efficient and fast (we expect) • We also want Certified Typecheckers Susmit Sarkar

  25. System Architecture Type Safety proof Type system is safe Type system Type checker correctly implements type system checker Code belongs to Type System Code Code Producer Code Consumer Susmit Sarkar

  26. Problem Statement • Design a Functional Language to write Certified Type Checkers in • Close to ML (mostly functional, datatypes) • Dependent Types • Manipulate LF types • Static typechecking • Full Type Inference not a goal Susmit Sarkar

  27. Indexed Types (DML) • Dependent types [Xi ] over index domain • Our index domain : LF terms • Recall: programmer in this system is code producer • explicit annotations are okay • Make typechecking as easy as possible Susmit Sarkar

  28. Example : Simply Typed Lambda • Index ML Types with LF terms • ML terms : dynamic representation of LF terms typecheck : Context  tm:ptermq. -> Term [tm] t:ptpq. ->  d:pof tm tq. Tp [tp] Susmit Sarkar

  29. Type Checker (application) fun typecheck ctx [_] (App [e1, e2] (e1, e2)) = let val <ty1,d1,TY1> = typecheck ctx [e1] e1 val <ty2,d2,TY2> = typecheck ctx [e2] e2 in case TY1 of Arrow [ty11, ty12] (TY11,TY12)) => let val <d3,()> = eqType [ty11, ty2] (TY11, TY2) in <ty12,(of_app d3 d2 d1),TY12> end | _ => error end | ... fun typecheck ctx (App (e1, e2)) = let val <TY1> = typecheck ctx e1 val <TY2> = typecheck ctx e2 in case TY1 of Arrow (TY11,TY12)) => let val < ()> = eqType (TY11, TY2) in <TY12> end | _ => error end | ... of_app : of (app E1 E2) TY12 <- of E1 (arrow TY11 TY12) <- of E2 TY2 <- tp_eq TY11 TY2. Susmit Sarkar

  30. Problem: Open Terms What about terms that add binding? Consider the usual rule for abstraction: ... | typecheck ctx (Lam ty1 e2) = let val ctx’ = ContextCons (ctx, ty1) val ty2 = typecheck ctx’ e2 in Arrow (ty1, ty2) end Susmit Sarkar

  31. Open Terms … contd. • Higher-order abstract syntax will use the LF context • of_lam : of (lam T1 E) (arrow T1 T2) <- ({x:term} of x T1 -> of (E x) T2). • Inefficient solution : Express everything in first-order • We need a handle on the context Susmit Sarkar

  32. Solution: Abstract over context • Abstract dependencies over context • Like Closure Conversion • Represent contexts as products • Requires adding -types in LF • Similar to typical implementation [Twelf] Susmit Sarkar

  33. Amended Definitions • datatype Context :: ptypeq -> TYPE • and Exp :: (c:ptypeq. pc -> termq )-> TYPE typecheck :  ctx:ptypeq.  tm:pctx->termq. Context [ctx] -> Term [(ctx,tm)] ->  tp:ptpq.  d:p  c:ctx. of (tm c) tpq. Tp [tp] Susmit Sarkar

  34. Type Checking Abstraction ... | typecheck [ctx, _] ctx (Lam [_, ty1, e2] (ty1, e2)) = let val <ctx1,ctx1> = <pctx £ (e1:term. of e1 ty1)q Cons [ctx, ty1] (ctx, ty1)> val e2’ = :². e2 (1, 1(2) ) val <ty2,d,ty2> = typecheck [ctx1,e2’] (ctx1, e2) vald’ = c:[ctx]. of_lam (e:term. d1:of e ty1. d (c, e, d1) ) in <parrow ty1 ty2q, d’, Arrow [ty1,ty2] (ty1, ty2)> end ... | typecheck ctx (Lam (ty1, e2)) = let val < ctx1> = < Cons (ctx, ty1)> val < ty2> = typecheck (ctx1, e2) in < Arrow (ty1, ty2)> end e2 : ctx -> (term -> term) of_lam : of (lam TY1 E2) (arrow TY1 TY2) <- ({e1:term} of e1 TY1 -> of (E2 e1) TY2). Susmit Sarkar

  35. 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] Susmit Sarkar

  36. Related Work (contd...) • Dependent Types in ML [Xi et al, Dunfield] • Simpler Index domains • Delphin [Schürmann et al] • Operational Model close to Logic Programming (backtracking, unification) Susmit Sarkar

  37. Related Work (contd…) • Tactics in Theorem Provers • Types : Proof produced is valid [LCF] • Dependent Types : proof of particular theorem • NuPRL: Integrate proof representation and programming language • Guaranteed Tactics [Knoblock] • Uses Reflection [Constable] Susmit Sarkar

  38. Work Plan • Meta Theory of LF,1 ~1 mth • Writing Type Checker for ML(LF) ~4 mths. • Translator to ML ~3 mths. • TALT Type Checker ~3 mths. • Dissertation Writing ~4 mths. • Total ~15 mths. Susmit Sarkar

  39. Thank You! Susmit Sarkar

More Related