Operating system verificationâAn overview
Operating system verificationâAn overview
Operating system verificationâAn overview
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
46 Gerwin Klein<br />
Figure 6.<br />
UCLA Secure Unix. Specification layers and consistency proofs.<br />
in 1977 (Popek et al 1977); intermediate reports (Popek & Farber 1978; Popek et al 1979,<br />
Kemmerer, 1979) followed. As in other projects, the proof assumes that the compiler, hardware,<br />
and interactive verification tool work correctly.<br />
Figure 6 shows the verification approach taken by the project. The left hand side shows the<br />
specification layers that were used. At the bottom layer is the Pascal code of the kernel, which<br />
the XIVUS tool used in the project could read. The highest level is the top-level specification.<br />
In between, we have the low-level and abstract-level specifications. Note that this is not a<br />
layered software architecture as in figure 7, § 3·2 where each level is implemented by different<br />
code. Instead, all these specification layers are formalisations of the same code artefact. They<br />
differ only in their level of abstraction. For example, the code provides full detail of everything;<br />
the low-level specification contains all variables that are retained between kernel calls, but<br />
uses more abstract structures for the rest; the abstract-level specification uses only abstract<br />
data structures such as lists and sets, but still describes all visible kernel operations; the toplevel<br />
specification is a capability-based access control model of the kernel that abstracts away<br />
from all detail not important for this aspect. The intent was to show that the kernel provides<br />
a data-separation mechanism in the sense of § 3·2.<br />
All of these specifications in UCLA Secure Unix are formally so-called state machines:<br />
they have a set of possible states, a current state, and a set of possible transitions between them.<br />
The proof then is to show that the specifications are consistent with each other, or formally,<br />
that the state machines simulate each other. This is easier to do in a number of smaller steps<br />
than in one big step, hence the multiple specification layers.<br />
The right hand side of figure 6 shows the consistency proofs between the levels. Each such<br />
proof in the project proceeds by defining a function that maps program states of the concrete<br />
level to program states of the abstract level. For each operation in the concrete <strong>system</strong>, it is<br />
then shown that the corresponding operation in the abstract <strong>system</strong> transforms the mapped<br />
concrete state accordingly.<br />
Although not called by that name at the time, the proof technique used in the project is<br />
formal refinement (Morgan 1990; de Roever & Engelhardt 1998), more specifically, data<br />
refinement. The idea is that a more concrete layer describes the same behaviour as an abstract<br />
layer, but with more detail. The abstract layer may say pick an element of a set, the more<br />
concrete layer may say pick the smallest element of the set, and the code may then implement<br />
the set as a sorted list and efficiently pick the head of the list, knowing that it will be the