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

March 4, 2005 Susmit Sarkar 1

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

Solution : Package certificate with code [Necula]

Producer ConsumerCode

Certificate

Why should I trust the code?

Because I can prove it is safe!


Safety Policy Certify compliance with Safety Policy Define what is “safe” Trusted Component of system


Traditional Certified Code : Architecture

Safety Policy = Trusted Type System


Annotations Type SystemConcrete Machine


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


Foundational Certified Code

Safety Policy = Formalized Concrete Machine [Appel & Felty]


Certificate Concrete Machine


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


Important Issue : Intellectual Effort We want Reasonable Intellectual Effort Proof Engineering task

FPCC Project has taken considerable man-years


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.


Proof Strategy : basic approach

Code Producer Code ConsumerCode

ConcreteMachine

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


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


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


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]


Approaches to Program-Specific Proof

Typing Derivations (Typed) Logic Programs Functional typecheckers


Approach : send direct proof

Problem : Proofs are huge!


class How do I know your code belongs to

this class ?Here is a proofproof

proof checker


Approach : Certified Type Checker

Need : Certified Type Checkers


classHow 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 ?


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


Example : Simply Typed Lambdaof : 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).


Example : Simply Typed Lambdaof : 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.


A Type Checkerof : 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.


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


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


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


System Architecture


Type system

checker

Type Safety

proofType system is safe

Type checker correctly

implements type system

Code belongs to

Type System


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


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


Example : Simply Typed Lambda Index ML Types with LF terms ML terms : dynamic representation of LF

termstypecheck : Context

tm:ptermq.

Term

t:p tp q.

d:pof tm tq.

Tp

[tm]

[tp]

->

->


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 | ...

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 < 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 | ...


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


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


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]


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]


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) val d’ = 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 of_lam : of (lam TY1 E2) (arrow TY1 TY2)

<- ({e1:term} of e1 TY1

-> of (E2 e1) TY2).

e2 : ctx -> (term -> term)


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

Delphin [Schürmann et al] Operational Model close to Logic Programming

(backtracking, unification)


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]


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.


Thank You!

Documents

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