A CostEffective Foundational Certified Code System

1
A Cost-Effective Foundational Certified Code
System

• Susmit Sarkar
• Thesis Proposal

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

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
Consumer
Code
4
Safety Policy

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

5
Traditional Certified Code Architecture

• Safety Policy Trusted Type System

Annotations
Concrete Machine
Type System
Producer
Code
Consumer
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

7
Foundational Certified Code

• Safety Policy Formalized Concrete Machine
  Appel Felty

Certificate
Concrete Machine
Producer
Consumer
Code
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

9
Important Issue Intellectual Effort

• We want Reasonable Intellectual Effort
• Proof Engineering task
• FPCC Project has taken considerable man-years

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.

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

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

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

15
Approaches to Program-Specific Proof

• Typing Derivations
• (Typed) Logic Programs
• Functional typecheckers

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

19
Example Simply Typed Lambda

• of term -gt tp -gt type.
• of_unit of unitTerm unitType.
• of_app of (app E1 E2) T12
• lt- of E1 (arrow T2 T12)
• lt- of E2 T2.
• of_lam of (lam T1 E) (arrow T1 T2)
• lt- (xterm of x T1 -gt of (E x)
  T2).

20
Example Simply Typed Lambda

• of term -gt tp -gt type.
• of_unit of unitTerm unitType.
• of_app of (app E1 E2) T12
• lt- of E1 (arrow T11 T12)
• lt- of E2 T2
• lt- tp_eq T11 T2.
• of_lam of (lam T1 E) (arrow T1 T2)
• lt- (xterm of x T1 -gt of (E x)
  T2).
• tp_eq tp -gt tp -gt type.

21
A Type Checker

• of term -gt tp -gt type.
• of_unit of unitTerm unitType.
• of_app of (app E1 E2) T12
• lt- of E1 (arrow T11 T12)
• lt- of E2 T2
• lt- tp_eq T11 T2.
• of_lam of (lam T1 E) (arrow T1 T2)
• lt- (xterm of x T1 -gt of (E x)
  T2).
• solve DERIV of (lam unitType (xterm unit))
  TP.

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

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

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

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

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

28
Example Simply Typed Lambda

• Index ML Types with LF terms
• ML terms dynamic representation of LF terms

typecheck Context
? tmptermq.
-gt
Term
tm
? tp tp q.
-gt
? dpof tm tq.
Tp
tp
29
Type Checker (application)

• fun typecheck ctx _ (App e1, e2 (e1, e2))
• let
• val ltty1,d1,TY1gt typecheck ctx e1 e1
• val ltty2,d2,TY2gt typecheck ctx e2 e2
• in
• case TY1 of
• Arrow ty11, ty12 (TY11,TY12)) gt
• let
• val ltd3,()gt eqType ty11,
  ty2
• 
  (TY11, TY2)
• in
• ltty12,(of_app d3 d2 d1),TY12gt
• end
• _ gt error
• end
• ...

• fun typecheck ctx (App (e1, e2))
• let
• val lt TY1gt typecheck ctx e1
• val lt TY2gt typecheck ctx e2
• in
• case TY1 of
• Arrow (TY11,TY12)) gt
• let
• val lt ()gt eqType
• 
  (TY11, TY2)
• in
• lt TY12gt
• end
• _ gt error
• end
• ...

of_app of (app E1 E2) TY12 lt- of
E1 (arrow TY11 TY12) lt- of E2 TY2
lt- tp_eq TY11 TY2.
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

31
Open Terms contd.

• Higher-order abstract syntax will use the LF
  context
• of_lam of (lam T1 E) (arrow T1 T2)
• lt- (xterm of x T1
• -gt of (E x) T2).
• Inefficient solution Express everything in
  first-order
• We need a handle on the context

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

33
Amended Definitions

• datatype Context ptypeq -gt TYPE
• and Exp (?cptypeq. pc -gt termq )-gt TYPE
• typecheck ? ctxptypeq.
• ? tmpctx-gttermq.
• Context ctx
• -gt Term (ctx,tm)
• -gt ? tpptpq.
• ? dp ? cctx. of (tm c) tpq.
• Tp tp

34
Type Checking Abstraction

• ...
• typecheck ctx, _ ctx (Lam _, ty1, e2 (ty1,
  e2))
• let
• val ltctx1,ctx1gt ltpctx (?e1term. of e1
  ty1)q
• Cons ctx, ty1 (ctx,
  ty1)gt
• val e2 ??². e2 (?1 ?, ?1(?2?) )
• val ltty2,d,ty2gt typecheck ctx1,e2
• (ctx1, e2)
• val d ?cctx.
• of_lam (?eterm. ?d1of e
  ty1.
• d (c,
  e, d1) )
• in
• ltparrow ty1 ty2q, d,
• Arrow ty1,ty2 (ty1,
  ty2)gt
• end

... typecheck ctx (Lam
(ty1, e2)) let val lt ctx1gt
lt Cons
(ctx, ty1)gt val lt ty2gt typecheck
(ctx1, e2)
in lt Arrow
(ty1, ty2)gt end
e2 ctx -gt (term -gt term)
of_lam of (lam TY1 E2) (arrow TY1 TY2)
lt- (e1term of e1 TY1
-gt of (E2 e1) TY2).
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

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)

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

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.

39
Thank You!