1 / 17

Inferable Object-Oriented Typed Assembly Language

Inferable Object-Oriented Typed Assembly Language. Ross Tate , Juan Chen, Chris Hawblitzel. 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

enid
Download Presentation

Inferable Object-Oriented Typed Assembly Language

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Inferable Object-Oriented Typed Assembly Language 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# Certifying Compiler TAL Trusted Proof Checker 

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

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

  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. Typing C# Assembly

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

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

  9. Broken C# Pseudo-Assembly Inferable TAL Traditional TAL [PLDI ‘08] boolbad(a, b : ∃γ≪List. Ins(γ)) { open a as Ins(α); No pack annotations vt = a.vtable; No open annotations mp = vt.isEmpty; open b as Ins(β); No loop invariants! c = mp(b); c = mp(pack b as ∃γ≪α. Ins(α)); return c; 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 Subsumes using open and pack θ: ∆’ → ∆ τ ≤ τ’[θ] Such that the bodies are subtypes after substitution ∃∆.τ ≤ ∃∆’.τ’ Then the existential types are subtypes 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

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

  12. Evaluation of iTalX

  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 Thank You!

More Related