Operating system verification—An overview

Operating system verification—An overview 57
constantly creating new threads. EROS solves this problem by viewing kernel memory as a
cache of the system state (Shapiro et al 1999). This solution makes it hard to predict worstcase
execution times and is therefore not well suited for embedded and real-time applications.
Separation kernels solve the problem by giving each separation domain a fixed quota
of kernel memory. This solution is not flexible enough for a full microkernel design. The
seL4 design on the other hand provides a solution well suited for embedded and real-time
systems.
Capabilities in seL4 are not hardware-enforced like in PSOS. Instead they are softwareimplemented
on a standard processor architecture and are kernel-enforced. They provide fully
dynamic, flexible mechanisms for hierarchically delegatable authority.
An important factor in the success of the seL4 kernel design was the tight integration of
the two teams: While the design was mainly driven by the NICTA OS group in the seL4
project, the concurrent verification effort in L4.verified provided continuous, early feedback
that was taken into account by the design group. This way, a good balance between external
performance requirements and verification constraints was maintained. The tight integration
kept the focus on performance and realistic architecture decisions instead of trading off more
ease-of-verification for slower kernel implementation as in Verisoft. The verification influence
kept the design to a small, manageable size instead of the greater complexity of a system such
as PSOS. The seL4 and L4.verified projects jointly developed a methodology that facilitated
this tight integration between formalisation and kernel prototyping. Figure 9 gives a summary
of the idea.
The most important activities in designing a microkernel are discussions between the developers,
e.g. on a whiteboard. To validate the design decisions, in the traditional OS approach
a prototype kernel is implemented in C or similar. This exposes performance and data structure
layout problems and allows direct testing of applications on top of the kernel. However,
this prototyping has a long overhead time between new design ideas and new prototype versions
(on the order of weeks and months). Additionally, initial case studies in the L4.verified
project (Tuch et al 2005) and the experience in VFiasco showed that starting the verification
directly from the C source without any higher-level specification should be expected to be
Design
Design Cycle
Hardware
Simulator
+
Haskell Prototype
Formal Low-Level Design
Manual
Implementation
Proof
User Programs
High-Performance C Implementation
Figure 9.
The seL4 design and rapid prototyping method.