Operating system verification—An overview

60 Gerwin Klein
into separate functions, which are verified separately against their specification. This specification
is then used in the rest of the C program. The C program state may be enriched with
hardware state that is only accessible to these assembly functions. The technique is similar
to Verisoft’s XCalls (Leinenbach & Petrova 2008).
One salient feature of the L4.verified C model is that it is formalised at a very detailed level
to support reasoning about unsafe language constructs. For example, it uses a formalisation of
fixed-size machine words (Dawson 2009) such as 32-bit or 64-bit words, instead of assuming
general natural numbers. At the same time, the formalisation provides proof techniques and
abstractions that allow efficient, abstract verification of program parts that do not use unsafe C
features (Tuch & Klein 2005, Tuch et al 2007, Tuch 2008b). Tuch’s (2008a) work proves two
high-level reasoning techniques correct and integrates them into the C verification framework:
separation logic (Reynolds 2002) and multiple typed heaps (Bornat 2000; Burstall 1972). The
first is a logic for pointer-based programs that is currently gaining popularity in the verification
community. The second allows the program heap to be cut into separate, non-interfering parts
by type to simplify verification.
The C code is parsed directly and automatically into the theorem prover. The technology
has been tested in a complex case study of the L4 kernel memory allocator functions (Tuch
et al 2007). As part of the project, (Kolanski 2008) has developed an adaptation of separation
logic that allows reasoning about the virtual memory layout of the machine. This logic can
be used to justify a simpler memory model for the majority of the code, and to reason directly
about MMU manipulations.
The total effort spent on all tool, library, logic, and C model development in the project so
far was an estimated 10 person years.
Coming back to the already completed, large-scale proof between high-level and low-level
design, the formal implementation correctness statement required the project to show a large
number of internal consistency invariants on both models. These invariant proofs made the
strongest direct contribution to the seL4 design process. One of the simplest of these invariants
states that all references in the kernel, including all capabilities, always point to valid objects
of the right type (i.e. thread capabilities always point to thread control blocks). This is easy to
establish for most kernel operations, but becomes interesting in the case of the retype operation
which allows processes to re-use memory, destroying old kernel data structures and initialising
new ones in their place. The kernel implements a number of complex bookkeeping data
structures and enforces restrictions on the retyping operation. These elaborate data structures
and restrictions are collectively designed to make sure that the internal consistency cannot
be broken by cleverly misusing the operation alone or in combination with any other kernel
operation.
The invariant proof shows that this design and interplay between bookkeeping and API
restrictions indeed works: No user will be able to create unsafe pointers inside the kernel, spoof
capability derivations, or gain elevated access to kernel resources through obscure corner
conditions or wrong parameter encodings. The project has established these consistency
invariants for all kernel operations, for all possible inputs, and for all possible sequences of
kernel invocations. Cock et al (2008) describe some of them in more detail. Even without
C-level implementation verification yet, this proof constitutes a strong validation of the seL4
design and the mechanisms it provides.