Operating system verification—An overview

58 Gerwin Klein
a difficult and long process. In contrast to the OS approach, the traditional formal methods
approach would take the design ideas, formalise them into a high-level specification first and
then analyse that specification. This has the advantage of exposing conceptual problems early.
The disadvantages lie in not exercising the design through user applications and not exposing
performance and data structure layout problems.
In the seL4 approach, the prototype is not written in C, but in a high-level, functional
programming language that is efficiently executable and close to the notation of the theorem
prover. In this case, the language chosen by the OS group was Haskell (Jones 2003), a pure,
side-effect free functional language that the kernel implementers felt comfortable with. Given
a hardware simulator for the target platform that transforms hardware kernel trap instructions
into calls to the Haskell prototype, normal user application binaries can still exercise the
design directly. The Haskell prototype can be made sufficiently low-level to expose data layout
problems immediately. Performance is only evaluated in a qualitative way, by observing the
number of system calls necessary to achieve a desired goal and by inspecting the Haskell code
of these calls to judge how well they could be implemented in C. Since Haskell is very close
to Isabelle/HOL, it can be automatically translated into the theorem prover. In this way, we
arrive automatically at a precise, formal low-level design which is the basis of further formal
analysis. Both the formal analysis and the validation against user binaries are able to feed
back rapidly into the design cycle. Changes in the design can be implemented in a manner of
days, sometimes hours (Heiser et al 2007; Elphinstone et al 2007, 2006).
For the purpose of running the Haskell kernel prototype, the two projects jointly developed
a hardware simulator generator that takes an instruction set specification together with a
simple device description and turns it into an efficient instruction-level simulator as well
as an Isabelle/HOL formalisation. This hardware formalisation can then form the basis for
assembly level verification. By running the simulator, the formalisation can be extensively
validated against the real processor. Trust is reduced from a manual formalisation to the
correct operation of the generator.
The total effort spent on designing, implementing and validating the seL4 kernel comes to
6 person years. This includes benchmarking and porting the L4/Linux (Leslie et al 2005) and
Iguana (NICTA 2008) operating systems to the new kernel.
We now turn from the seL4 design to its verification in the L4.verified project. Figure 10
gives an overview of how the design fits into the verification picture. The L4.verified refinement
approach looks similar to that of UCLA Secure Unix. On the bottom layer, we find
the source code implementation of the kernel in C and assembly. To reason about the implementation,
this lowest model also needs to include some detail about the hardware such as a
model of the MMU, exceptions, and interrupts. The next layer up is the low-level design—the
Isabelle/HOL translation of the Haskell prototype mentioned above. It contains implementations
of all important data structures with a high degree of low-level detail like the number
of bits that are used to store capabilities, doubly-linked lists implemented by pointers, etc.
The second highest layer in figure 10 is the high-level design. It contains a description of all
user-visible kernel operations, but leaves out data structures and detail where possible. For
instance, the scheduler on the abstract level is specified simply by saying pick any thread in
the system that is runnable, but in the low-level design, a data structure is provided for tracking
which threads are runnable and which priority they have. The top level of figure 10 is
the access control model of seL4 (Elkaduwe et al 2007). It abstracts strongly from detail and
only specifies how capabilities are distributed in the system. The security property proven in
L4.verified states that the kernel can effectively isolate subsystems and can enforce flexible
global security policies.