COGENT: Verifying High-Assurance File System Implementations Sidney Amani, Alex Hixon, Zilin Chen, Christine Rizkallah, Peter Chubb, Liam O’Connor, Joel Beeren, Yutaka Nagashima, Japheth Lim, Thomas Sewell, Joseph Tuong, Gabriele Keller, Toby Murray, Gerwin Klein, Gernot Heiser Data61 (formerly NICTA) and UNSW, Australia fi[email protected] Abstract File systems, which constitute the largest fraction of code We present an approach to writing and formally verify- in Linux after device drivers, have among the highest defect ing high-assurance file-system code in a restricted lan- density of Linux kernel code [38]. Furthermore, new file sys- tems are frequently added for new media types or for new guage called COGENT, supported by a certifying compiler performance and reliability trade-offs. The lack of support that produces C code, high-level specification of COGENT, and translation correctness proofs. The language is strongly for correctly writing new file systems is a standard bottle- typed and guarantees absence of a number of common file neck. system implementation errors. We show how verification ef- Formal verification in the style of seL4 [26] or Ironclad fort is drastically reduced for proving higher-level proper- [15] is the only approach to fully solve this problem. While ties of the file system implementation by reasoning about formal verification for file systems has seen a surge in ac- the generated formal specification rather than its low-level C tivity in recent years [9, 11, 18], it has however not yet code. We use the framework to write two Linux file systems, reached that same level of detail and assurance. In the most and compare their performance with their native C imple- advanced and deepest of these verifications, Chen et al. [8] mentations. formally shows crash-resilience of the FSCQ file system im- plemented in the Coq prover [6]. Even this verification still Categories and Subject Descriptors D.4.5 [Operating relies on generating Haskell code from the Coq implemen- Systems]: Reliability—Verification; D.2.4 [Software Engi- tation, and executing that generated code with a full Haskell neering]: Software / Program Verification—Formal meth- run-time at user level. This proof crosses an important bar- ods; D.3.2 [Programming Languages]: Language Classi- rier for formal verification: it removes human intervention fication—Applicative (functional) languages from the link between the code that runs and the model that is verified. However, the trusted code base is still huge: the Keywords file systems; verification; domain-specific lan- run-time is larger than the file system, the code generation guages; co-generation; Isabelle/HOL step from Coq is unverified, and the semantics of the tar- get language (Haskell) is complex and informal. While cer- 1. Introduction tainly an impressive result, for high-assurance systems on Operating systems (OS) code is critical for the dependability potentially resource-constrained devices, this is not yet good and security of computer systems. In monolithic systems, enough. most OS services are part of the kernel and are included in As motivated in [23], we design a new language called the trusted computing base (TCB) of any application. While COGENT to bridge the gap between verifiable formal model microkernels can help reduce the TCB [10, 17, 29, 47], in and low-level code. In separate work [36], we define the practice we need more, because most applications depend on formal semantics of COGENT, describe the COGENT com- the correct operation of a significant number of OS services. piler in detail which generates C code and an Isabelle/HOL specification, and show how the seven main stages of au- tomatic compiler-produced proof work that connect the C Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed and the Isabelle/HOL specification. In this paper, we show for profit or commercial advantage and that copies bear this notice and the full citation how to reason about COGENT programs, how COGENT is on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or used to implement two Linux file systems, and we analyse republish, to post on servers or to redistribute to lists, requires prior specific permission how COGENT reduces the effort of reasoning about a low- and/or a fee. Request permissions from [email protected]. ASPLOS ’16, April 02 – 06, 2016, Atlanta, GA, USA. level C implementation in order to more productively rea- Copyright is held by the owner/author(s). Publication rights licensed to ACM. son about high-level functional specifications — similar in ACM 978-1-4503-4091-5/16/04. $15.00. http://dx.doi.org/10.1145/10.1145/2872362.2872404 style to Chen et al’s verification. To this end, we verified two high-level functional correctness properties of one of the two 1. We demonstrate the use of COGENT for implementing Linux file systems. These are properties that would form key actual file systems (Section 3). building blocks in, for instance, a proof of crash resilience. 2. We present proofs of high-level correctness properties of COGENT goes further than just bridging the gap from a file system implemented in COGENT and discuss how model to code. It also provides tools for file system program- COGENT facilitates such proofs (Section 4). mers without any formal verification expertise to provably avoid common errors: The language is type safe, i.e. the type 3. We discuss the effort involved in implementing file sys- system is strictly enforced. The compiler and type system in tems with verified properties in COGENT (Section 5). turn enforces basics like memory safety, but also the absence 4. We evaluate the COGENT-implemented file systems of any undefined behaviour on the C level, null pointer deref- against their native C counterparts (Section 5). erences, buffer overflows, memory leaks, and pointer mis- management in error handling. Mismanagement of pointers 2. Overview of Our Approach in error-handling code is a wide-spread problem in Linux file 2.1 COGENT systems specifically [41], and Saha et al. [42] shows that file systems have among the highest density of error-handling COGENT is tailored to writing systems code, with a specific code in Linux. In the verification of seL4, a significant frac- focus on file systems. It is intentionally more restrictive tion of the overall effort went into proving absence of such than general-purpose functional languages, to enable the use errors [25]–COGENT’s linear type system [49] provides this of efficient and powerful reasoning techniques on its high- for free and assists the programmer with memory alloca- level semantics, to avoid the need for an elaborate language tion handling. Memory safety and memory leaks are prob- run-time, and to enable the COGENT compiler to output lems with file systems, but also more generally in systems an automatic proof that the C code it generates correctly code [43]. The infamous Heartbleed bug for instance, was implements the behaviour of the COGENT program [36]. In a buffer overflow [16], the recent “goto-fail” defect in Ap- this paper, we further demonstrate how to prove functional ple’s SSL/TLS implementation was an error-handling prob- correctness of the COGENT program. lem obscured by gotos in an if-cascade [37], and the recent COGENT manages to avoid a garbage collector, unlike memory leak in Android Lollipop also was part of error- most existing high-level languages such as Java, Haskell, handling code [30]. All of these problems are prevented on and OCaml, by implementing a linear type system [49], the language level by COGENT, and are enforced by its certi- which ensures that each linearly typed object is used exactly fying compiler. Few other languages come with type-system once. The type system not only provides memory safety, but guarantees that address problems like memory leaks without also makes memory leaks compile-time errors. Traditional significant overhead or large language run-times (e.g. Rust), pure functional languages, such as Haskell, that disallow and none come with a formal semantics and a machine- side effects, favour frequent copies of dynamically allocated checked proof of their guarantees. data structures and make it hard to reason about the perfor- COGENT compiles to straight C code that can be com- mance of the generated code. COGENT’s linear type sys- piled by gcc or CompCert [27, 28]. The generated C code tem increases performance by allowing the compiled code also falls into the fragment understood by Sewell et al.’s gcc to modify data structures in-place. The type system sup- translation validation tool [46], providing a pathway to ex- ports parametric polymorphism. While doing so might not tend the verification all the way to binary level if needed. be an obvious choice for a language geared towards systems We designed COGENT with the code patterns and common programming, it is particularly important in the context of errors in Linux file systems in mind. As detailed in sepa- COGENT, which relies on external ADTs to implement data rate work [36], its semantics is sequential (allowing asyn- structures that cannot be implemented with linear types. chronous I/O, but not full concurrency), restricted to total COGENT also supports higher-order functions. In contrast functions, and contains no built-in loops or recursion. This to general-purpose functional languages, however, all func- simplifies reasoning, both for the compiler and on top of tions in COGENT have to be defined on the top-level. This the language. Iterators, external abstract functions, and types restriction is necessary to avoid the run-time overhead and that rely on sharing, are implemented in a formally modelled heap allocations necessary to implement closures otherwise.