1. /191 Typed Compilation of Objects Andrew McCreight and Zhong Shao FLINT Project Yale University

2. /192 Background Modern OO systems like ROTOR are big Error in runtime can be safety problem Safety problem can be security problem Want to minimize Trusted Computing Base (TCB) Can we avoid trusting, say, the compiler? What about the type tests? GC?

3. /193 Outline Typed compilation Lightweight object types OO in machine level Hoare Logic

4. /194 Standard managed runtime bytecode +types checker binaryruntime compiler CPU TRUSTEDUNTRUSTED

5. /195 PCC/TAL bytecode +types checker binary +types runtime compiler CPU TRUSTED UNTRUSTED

6. /196 Typed Compilation Have to get compiler to emit types Types for machine level objects Don’t want to change compiler a lot Don’t want to learn fancy type theory Solution: a lightweight type system

7. /197 Lightweight type system Must be sound  Passes type check: memory safe (no crashes) Minimize number of type annotations  Complicates optimizations Match abstraction level of program  Objects, vtables, methods

8. /198 Lightweight types for objects Explicit self application is dangerous  Must track source of each VMT Object types: C, classOf(x) VMT types: vmt(C), vmt(classOf(x)) Method types: (classOf(x), C, D)  E

9. /199 Example (untyped) // Assume class C has method m // where m takes one argument of type D Object example(C a, C b, D c) { y := a.vmt; z := y.m; return (z(a, c)); } Must only let a be used for self argument

10. /1910 Example (explicitly typed) // Assume class C has method m // where m takes one argument of type D Object example(C a, C b, D c) { y : vmt(classOf(a)) := a.vmt; z : (classOf(a), D)  Object := y.m; return (z(a, c)); } b does not have type classOf(a)

11. /1911 Example (typed) // We can easily reconstruct local var types. Object example(C a, C b, D c) { y := a.vmt; z := y.m; return (z(a, c)); } Method body is same as in untyped version!

12. /1912 Lightweight types We have a sound type system for objects  Formal system, soundness proof in TR At the machine level Without annotations in method bodies

13. /1913 Limitations Not very expressive How to reason about optimizations? How to reason about runtime?  Chen and Tarditi’s type system Can reason about downcast implementation While retaining lightweight types (though not as lightweight as ours)  But what about, say, GC?  We take another approach

14. /1914 FPCC bytecode checker binary +types runtime +proof compiler CPU TRUSTED UNTRUSTED

15. /1915 Hoare logic for objects Don’t extend type system for downcast implementation How to reason about, say, Cheney GC with types? It gets messy. Don’t want to pollute our compiler Give up on types for checking runtime Use Hoare logic: very expressive Can interface types with HL

16. /1916 Turn types into propositions “there’s an object of type C at address h if h contains the VTB of C, and h+1,…,h+k contain values having the same types as the k fields of C” Object layout laid bare Allows flexible reasoning Have verified impl. of dynamic type check Target for Spec#?

17. /1917 Future work Close gap between simple OO type system and HL OO type system Make OO type system expressive enough to handle results of optimizations Support more of CIL Verify type safety of a GC Typed compilation of Spec#?

18. /1918 Conclusion Less trust = more reliable Sound typing for low level objects No annotations or type machinery needed in method body in our type system Use Hoare logic to reason about runtime services Gives us strengths of both approaches

19. /1919 Questions?