Safe to the last instruction

Abstract

Typed assembly language (TAL) and Hoare logic can verify the absence of many kinds of errors in low-level code. We use TAL and Hoare logic to achieve highly automated, static verification of the safety of a new operating system called Verve. Our techniques and tools mechanically verify the safety of every assembly language instruction in the operating system, run-time system, drivers, and applications (in fact, every part of the system software except the boot loader). Verve consists of a "Nucleus" that provides primitive access to hardware and memory, a kernel that builds services on top of 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 TAL checker verifies the safety of the kernel and applications. A Hoare-style verifier with an automated theorem prover verifies both the safety and correctness of the Nucleus. Verve is, to the best of our knowledge, the first operating system mechanically verified to guarantee both type and memory safety. More generally, Verve's approach demonstrates a practical way to mix high-level typed code with low-level untyped code in a verifiably safe manner.

The HACMS program: using formal methods to eliminate exploitable bugs

“…Appropriate candidates include separation kernels, hypervisors, real-time operating systems (RTOSes), compilers, file systems, web broswers, sandboxes, cryptographic algorithms and garbage collectors. Perhaps surprisingly, the literature already includes artefacts that have been verified in all of these categories, albeit with somewhat limited functionality: the seL4 microkernel [ 33 ], the mCertiKOS hypervisor [ 35 ], the eChronos and ORIENTIAS RTOSes [ 27 , 36 ], the CompCert C Compiler [ 37 ], the FSCQ and BilbyFS file systems [ 38 , 39 ], the Quark web broswer [ 40 ], the RockSalt browser sandbox [ 41 ], various crytographic algorithms [ 42 , 43 ] and the Nucleus garbage collector [ 44 ]. The existence of two of these artefacts were crucial to DARPA’s decision to fund the HACMS program, serving as a basis of confidence that the program had some chance of succeeding: the seL4 microkernel and the CompCert verifying C compiler.…”

“…time performance seL4 [ 33 ] 10K LoC, 480K LoP 13 PY 206 versus 227 cycles CompCert [ 46 ] 42K LoC+P 3 PY 2× speed of 7% slower than 12% slower than FSCQ File System [ 38 ] 24K LoC+P <5 PY 80% of xv6 file system certiKOS Hypervisor [ 35 ] 2K LoC, 18.5K LoP 1 PY <2× slowdown on most benchmarks SHA-256/HMAC [ 43 ] 407 LoC, 14.4K LoP n.a. equivalent to OpenSSL 0.9.1c Rocksalt Sandbox [ 41 ] 100 LoC, 10K LoP <2 PY 1M instructions per second faster than Google’s checker Nucleus GC [ 44 ] 6K LoC+P 0.75 PY ‘competitive’ Quark Web Browser [ 40 ] 5.5K LoC+P 0.5 PY 24% overhead w.r.t. WebKit baseline on 10 Alexa Websites …”

Towards End-to-End Verified TEEs via Verified Interface Conformance and Certified Compilers

“…We could swap out the certified compiler in our tool chain by a compiler validation step [49], [50], as long as the bi-simulation relation automatically extracted during the compiler validation process could also bring the properties that we care about down to the compiled code. Many fully-verified kernels directly model and reason about assembly [15], [51]- [55], cutting out the need for a trusted compiler, which we discuss later in this section.…”

“…Assembly analysis and verification One common approach for projects that verify properties of mixtures of C and assembly or prove the assembly code correct is to rely on a formal model of the assembly. The assembly model is either encoded in a theorem prover [52], [54], or in a hoare-style verification framework like Bedrock [57], BoogiePL [51] or Vale [58], [59], where verification conditions are discharged automatically by an SMT solver like Z3 [60]. Our tool chain allows developers to directly interact with the C-level analysis tools, not assembly-level or another high-level language like F*, C#, or Dafny [61].…”

Implicit relations and their derivatives for symbolic state space generation

“…Independently developed by Clarke and Emerson [27] and by Queille and Sifakis [54] in early 1980s, the technique of model checking gained traction in numerous theoretical topics [63] and found its application in verification of many real world systems, including, but not limited to, the genre of operating systems [65], sequential circuit designs [39,15], communication protocols [35],…”