Microsoft Technology Licensing, LLC

Chris Hawblitzel

Jacob Rubin Lorch

Jonathan Ryan Howell

Brian Don Zill

Bryan Jeffrey Parno

Galen Clyde Hunt

James R Larus

Manuel Alfred Fahndrich

Shuvendu K Lahiri

Mark Aran Aiken

Juan Chen

Jean Yang

Frances Perry

Bryan Parno

A verified software system may be executable on secure hardware. Prior to being executed, the software system may be verified as conforming to a software specification. First credentials attesting to an identity of the software system may be sent to an external application. Second credentials signed by a provider of the secure hardware may be sent to the external application. The second credentials may attest to an identity of the secure hardware. The external application may securely exchange one or more messages with a software application of the software system. For example, the one or more messages may be decryptable only by the external application and the software application to provide confidentiality for each message. As another example, an attestation may vouch for an identity of a sender of each of the one or more messages to attest to an integrity of each message.

End-to-end security for hardware running verified software

Software code of a software system (e.g., a software stack) may be verified as conforming to a specification. A high-level language implementation of the software system may be compiled using a compiler to create an assembly language implementation. A high-level specification corresponding to the software system may be translated to a low-level specification. A verifier may verify that the assembly language implementation functionally conforms to properties described in the low-level specification. In this way, the software system (e.g., a complete software system that includes an operating system, device driver(s), a software library, and one or more applications) may be verified at a low level (e.g., assembly language level).

Automated verification of a software system

To overcome the difficulties inherent in traditional compiler validating methods, a new technique is herein provided for validating compiler output via program verification. In one embodiment, this technique is implemented as an automated tool that merges both a source program and the compiler-generated target program into a single (intermediate) program. An automated program verifier is then applied to the merged program. Subsequently, the program verifier compares the source and target programs and determines if the programs are semantically equivalent.

Compiler validation via program verification

Systems and methods that add specifications to procedures in a garbage collector for indicating what each procedure does. Such annotations can be added in the source code, to indicate what the source code is to do when it runs&#x2014;hence enabling an automatic verification of the garbage collector by a verification component. The specification can be presented as a logical formula that can be readily processed by a theorem prover, which is associated with the verification component. Such logical formulas can further employ regions to specify correctness of the garbage collector.

Automatic region-based verification of garbage collectors

An 'Automated, Static Safety Verifier' uses typed assembly language (TAL) and Hoare logic to achieve highly automated, static verification of type and memory safety of an operating system (OS). Various techniques and tools mechanically verify the safety of every assembly language instruction in the OS, run-time system, drivers, and applications, except the boot loader (which can be separately verified). The OS includes a 'Nucleus' for accessing hardware and memory, a kernel that builds services running on the Nucleus, and applications that run on top of the kernel. The Nucleus, written in verified assembly language, implements allocation, garbage collection, multiple stacks, interrupt handling, and device access. The kernel, written in C# and compiled to TAL, builds higher-level services, such as preemptive threads, on top of the Nucleus. A Hoare-style verifier with automated theorem prover verifies safety and correctness of the Nucleus. A TAL checker verifies safety of the kernel and applications.

Automated verification of a type-safe operating system

Embodiments that facilitate type checking of assembly language instructions are disclosed. In one embodiment, a method includes receiving a low level language instruction in a memory. The instruction includes a word having a first type. The memory includes either a stack or a heap. Each of the stack or heap includes a plurality of positions. The method also includes labeling the plurality of positions in one of the stack or the heap as one or more specified positions and one or more unspecified positions. The method further includes assigning a second type to the memory, the second type including the first type of the word. The word is stored in a specified position or an unspecified position. The method additionally includes determining whether the instruction is well-typed by applying one or more rules to the instruction and to the second type.

Simple stack types

A first plurality of operating system processes is assigned to a first protection domain, and a second plurality of operating system processes is assigned to a second protection domain. One or more hardware protection mechanisms are used to prevent the first plurality of operating system processes from accessing the memory space of the second plurality of operating system processes, and also to prevent the second plurality of operating system processes from accessing the memory space of the first plurality of operating system processes.

Growing community of inventors

Redmond, WA, United States of America

Chris Hawblitzel