A Cost-Effective Foundational Certified Code System

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