Presentation is loading. Please wait.

Presentation is loading. Please wait.

Ross Tate, Juan Chen, Chris Hawblitzel. Typed Assembly Languages Compilers are great but they make mistakes and can introduce vulnerabilities Typed assembly.

Similar presentations


Presentation on theme: "Ross Tate, Juan Chen, Chris Hawblitzel. Typed Assembly Languages Compilers are great but they make mistakes and can introduce vulnerabilities Typed assembly."— Presentation transcript:

1 Ross Tate, Juan Chen, Chris Hawblitzel

2 Typed Assembly Languages Compilers are great but they make mistakes and can introduce vulnerabilities Typed assembly language includes a proof of (memory) safety verified by a trusted proof checker no need to trust the compiler Certifying compilers generate typed assembly language traditionally use “type-preservation” C#C# Certifying TA L Compiler Trusted Proof Checker

3 Type-Preserving Compiler Source Program Class/Function Signatures Type/Proof Annotations Intermediate Representation IR1 Optimizations/Conversions IR2 x86 sigs annots sigs annots sigs annots Proof Checker types/proofs Burden to preserve types at each stage Hard to adopt in existing compilers Types/proofs increase size of executable Burden to preserve types at each stage Hard to adopt in existing compilers Types/proofs increase size of executable

4 Traditional Compiler Source Program IR1 Optimizations/Conversions IR2 Proof Checker x86 sigs annots x86sigs Type Inference sigs Requires little change Smaller annotation size Requires little change Smaller annotation size Signature information is already preserved in traditional compilers Signature information is already preserved in traditional compilers Easy to change compiler to write sig info to file Infer proof annotations Can inference be effective enough ?

5 Effectiveness of Type Inference Capable of type checking all C# features except: Exceptions and Delegates matters of implementation, not due to theoretical limitations

6

7 Broken C# Pseudo-Assembly bool bad(a, b : List) { vt = a.vtable; mp = vt.isEmpty; c = mp(b); return c; } Could actually be an ArrayList Could actually be a LinkedList Grabs a’s vtable Grabs a’s implementation of isEmpty Calls a’s isEmpty with b as “this” a’s implementation of isEmpty may fail to work on b a’s implementation of isEmpty may fail to work on b

8 Broken C# Pseudo-Assembly bool bad(a, b : List) { bool bad(a, b : ∃γ≪ List. Ins( γ )) { vt = a.vtable; mp = vt.isEmpty; c = mp(b); return c; } open a as Ins( α ); open b as Ins( β ); c = mp(pack b as ∃γ≪α. Ins( α )); Traditional TAL [PLDI ‘08] Pseudo-instruction for the type checker Pseudo-instruction for the type checker More specific function signature α must be fresh a is given type exactly Ins( α ) where α ≪ List vt is given type VTable( α ) mp is given type ( ∃γ≪α. Ins( γ )) → bool b is given type exactly Ins( β ) where β ≪ List Checks that there is some γ extending α such that b has type Ins( γ ) Checks that there is some γ extending α such that b has type Ins( γ ) Check fails since b has type Ins( β ) and β does not extend α Check fails since b has type Ins( β ) and β does not extend α a and b are each instances of some (possibly different) subclass of List a and b are each instances of some (possibly different) subclass of List β must be fresh Via signature & memory layout information The “this” pointer must belong to α

9 Broken C# Pseudo-Assembly bool bad(a, b : ∃γ≪ List. Ins( γ )) { vt = a.vtable; mp = vt.isEmpty; c = mp(b); return c; } open a as Ins( α ); open b as Ins( β ); c = mp(pack b as ∃γ≪α. Ins( α )); Traditional TAL [PLDI ‘08]Inferable TAL No pack annotations No open annotations No loop invariants! Use type inference instead

10 Inference Strategy Always open existential types as soon as possible Use subtyping in place of pack: Use abstract interpretation over existential types Requires subtyping and join algorithms θ: ∆’ → ∆ τ ≤ τ’[θ] ∃∆.τ ≤ ∃∆’.τ’ Given a valid substitution of variables Such that the bodies are subtypes after substitution Then the existential types are subtypes Subsumes using open and pack Subsumes using open and pack Subtyping alone of bounded existential types is undecidable! Designed a category-theoretic framework for existential types Constructive: includes abstract algorithms for inference Instructive: specifies type design guidelines Designed a category-theoretic framework for existential types Constructive: includes abstract algorithms for inference Instructive: specifies type design guidelines

11 Type Checking with iTalX bool bad(a, b : ∃γ≪ List. Ins( γ )) { vt = a.vtable; mp = vt.isEmpty; c = mp(b); return c; } ∃α, β : α≪ List, β≪ List. a : Ins( α ) b : Ins( β ) vt : VTable( α ) mp : ( ∃γ≪α. Ins( γ )) → bool ∃α, β : α≪ List, β≪ List. a : Ins( α ) b : Ins( β ) vt : VTable( α ) mp : ( ∃γ≪α. Ins( γ )) → bool Inference Strategy Immediately open a and b Inference Strategy Immediately open a and b Signature Information α ≪ List ⇒ Ins( α ) has fields: vtable : VTable( α ) ⋮ Signature Information α ≪ List ⇒ Ins( α ) has fields: vtable : VTable( α ) ⋮ Signature Information α ≪ List ⇒ VTable( α ) has fields: ⋮ isEmpty : ( ⋯ ) → bool ⋮ Signature Information α ≪ List ⇒ VTable( α ) has fields: ⋮ isEmpty : ( ⋯ ) → bool ⋮ Type Check Ins( β ) ≤ ∃γ≪α. Ins( γ ) Type Check Ins( β ) ≤ ∃γ≪α. Ins( γ ) Check Fails β does not extend α Check Fails β does not extend α

12

13 Expressiveness of iTalX iTalX is capable of handling the following features: Classes, interfaces, generics, and multiple inheritance Dynamic dispatch and dynamic casts Covariant arrays as classes, and array-bounds checks By-reference parameters ( ref ), structs, and value types Jump tables and complex stack manipulation iTalX is also robust with respect to many optimizations iTalX should be able to handle the remaining features: Delegates and exceptions In experiments, iTalX currently verifies 97.9% of methods

14 Efficiency of iTalX Inferring Assembly-Level Types is Affordable

15 Type Annotation Size Type annotation size is significantly reduced

16 Implementation Burden of TAL Type Preservation [PLDI ‘08] Assembly-Level Type Inference 19,000 lines of code cut across code base 13,800 lines of code 5,000 lines of code modular addition to code base 15,100 lines of code could be separated to reduce trusted computing base Changes to an Existing Compiler (Bartok)Type Checker + Type Inference

17 Conclusion Type inference at the assembly level is expressive enough to verify C# with optimizations flexible enough to accommodate new language features efficient enough to use regularly during compilation compact enough to include in executable binaries modular enough to retrofit existing compilers with


Download ppt "Ross Tate, Juan Chen, Chris Hawblitzel. Typed Assembly Languages Compilers are great but they make mistakes and can introduce vulnerabilities Typed assembly."

Similar presentations


Ads by Google