Type safety from the ground up

• Authors: Chris Hawblitzel
• Venue: Proceedings of the 7th ACM SIGPLAN workshop on Types in language design and implementation
• Year: 2011

Type safety is the most common mechanism for securely running untrusted code from the Internet. When the untrusted code is written in a type-safe language like JavaScript, Java, or C#, the language's type system guarantees that the code cannot damage the user's computer (without the user's permission). This guarantee, however, rests on the correct enforcement of type safety, and a typical computer system has many components that must be trusted to enforce type safety. A bug in any one of these components could break security entirely: a buggy compiler could emit unsafe code, a buggy garbage collector could turn integers into unsafe pointers, a buggy operating system could overwrite a thread's context with untyped data, and a buggy device driver could instruct a device to overwrite typed memory with untyped data. This talk will describe work on the Verve operating system [8]{verve:pldi10}, which uses typed assembly language (TAL)[6] and automated theorem proving to ensure type safety across all components of a computer system, including the garbage collector, the operating system, the device drivers, and all compiler-generated assembly language code. Verve consists of about 35,000 lines of safe C# code, compiled to typed assembly language, running on top of 1500 lines of assembly language, verified with the Z3 automated theorem [2]. For example, the operating system's scheduler is C# code compiled to TAL, while the operating system's low-level context switching and interrupt handling is verified assembly language code. Similarly, the Ethernet driver's packet processing is C# compiled to TAL, while the verified assembly language ensures that devices are managed safely (via verified interaction with PCI) and device memory access is safe (via verified programming of an I/O memory management unit). Finally, the run-time system is split into components that the TAL type system can express (including array-store checks and run-time casts), and components that are verified with theorem proving (in particular, the garbage collector). This splitting is similar to other operating systems designed for high assurance [1, 4, 5, 7], but Verve adds a higher degree of static safety verification: every assembly language instruction is statically verified, either with type checking or theorem proving, to preserve type safety. Because Verve relies on two separate static checkers (TAL and Z3), it does not yet achieve the goal of unified, foundational certification as pursued by the FLINT project [3]. This talk will discuss ongoing work to move closer to this goal, by expressing both Verve's low-level state and a TAL type system in a unified language (Coq). Although this work is preliminary, it has already uncovered several bugs in the specification used to verify Verve's 1500 lines of assembly language. (These bugs were too-strong preconditions and too-weak postconditions; luckily, the specification bugs didn't result in bugs in the code itself.) Verve's source code is available at the following URL (in the "verify" directory): http://www.codeplex.com/singularity