March 4, 2005Susmit Sarkar 1 A Cost-Effective Foundational Certified Code System Susmit Sarkar Thesis Proposal

March 4, 2005Susmit Sarkar2 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

March 4, 2005Susmit Sarkar3 Solution : Certified Code Solution : Package certificate with code [Necula] ProducerConsumer Code Certificate Why should I trust the code? Because I can prove it is safe!

March 4, 2005Susmit Sarkar4 Safety Policy Certify compliance with Safety Policy Define what is “safe” Trusted Component of system

March 4, 2005Susmit Sarkar5 Traditional Certified Code : Architecture Safety Policy = Trusted Type System Producer Consumer Code Annotations Type System Concrete Machine

March 4, 2005Susmit Sarkar6 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

March 4, 2005Susmit Sarkar7 Foundational Certified Code Safety Policy = Formalized Concrete Machine [Appel & Felty] ProducerConsumer Code Certificate Concrete Machine

March 4, 2005Susmit Sarkar8 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

March 4, 2005Susmit Sarkar9 Important Issue : Intellectual Effort We want Reasonable Intellectual Effort Proof Engineering task FPCC Project has taken considerable man- years

March 4, 2005Susmit Sarkar10 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.

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

March 4, 2005Susmit Sarkar12 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

March 4, 2005Susmit Sarkar13 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

March 4, 2005Susmit Sarkar14 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]

March 4, 2005Susmit Sarkar15 Approaches to Program-Specific Proof Typing Derivations (Typed) Logic Programs Functional typecheckers

March 4, 2005Susmit Sarkar16 Approach : send direct proof Problem : Proofs are huge! Code Producer Code Consumer Code class How do I know your code belongs to this class ? Here is a proof proof proof checker

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

March 4, 2005Susmit Sarkar18 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

March 4, 2005Susmit Sarkar19 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) of (E x) T2).

March 4, 2005Susmit Sarkar20 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) of (E x) T2). tp_eq : tp -> tp -> type.

March 4, 2005Susmit Sarkar21 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) of (E x) T2). %solve DERIV : of (lam unitType ([x:term] unit)) TP.

March 4, 2005Susmit Sarkar22 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

March 4, 2005Susmit Sarkar23 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

March 4, 2005Susmit Sarkar24 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

March 4, 2005Susmit Sarkar25 System Architecture Code ProducerCode Consumer Code Type system checker Type Safety proof Type system is safe Type checker correctly implements type system Code belongs to Type System

March 4, 2005Susmit Sarkar26 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

March 4, 2005Susmit Sarkar27 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

March 4, 2005Susmit Sarkar28 Example : Simply Typed Lambda Index ML Types with LF terms ML terms : dynamic representation of LF terms typecheck : Context  tm: p term q. Term  t: p tp q.  d: p of tm t q. Tp [tm] [tp] ->

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

March 4, 2005Susmit Sarkar30 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

March 4, 2005Susmit Sarkar31 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

March 4, 2005Susmit Sarkar32 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]

March 4, 2005Susmit Sarkar33 Amended Definitions datatype Context :: p type q -> TYPE and Exp :: (  c: p type q. p c -> term q )-> TYPE typecheck :  ctx: p type q.  tm: p ctx->term q. Context [ctx] -> Term [(ctx,tm)] ->  tp: p tp q.  d: p  c:ctx. of (tm c) tp q. Tp [tp]

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

March 4, 2005Susmit Sarkar35 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]

March 4, 2005Susmit Sarkar36 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)

March 4, 2005Susmit Sarkar37 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]

March 4, 2005Susmit Sarkar38 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.

March 4, 2005Susmit Sarkar39 Thank You!