Operating system verification—An overview

32 Gerwin Klein
siveness like Zermelo–Fraenkel Set Theory or Higher-Order Logic (HOL) make it easier to
express properties and specifications precisely and more importantly in a readable way, but
they require human creativity and expertise in performing the proof. There are many steps in
between these two extremes with model checking and automated first-order theorem proving
as two intermediate examples. As we shall see in later sections, all of these have their use in
the analysis of operating systems. It is currently mainly the interactive methods that provide
sufficient expressivity to handle the formal statement of full functional correctness of an OS
microkernel, although there are efforts to shift these proofs towards more automation where
possible.
It is illustrative to view the traditional methods of code inspection and testing in terms
of figure 2. Code inspection means looking at the code, following its logic, and manually
comparing it to the intended behaviour. Testing means implementing the program, running it
on input data, and comparing the results to the expected outcome. Code inspection attempts
to make a direct connection between the ideal model of requirements and design that exists
in the head of the inspector and the arguably physical artefact of source code. To accomplish
this, the code inspector does at least need to construct a mental model of the physical system
behaviour which in spirit, but not in form, is usually very close to what a formal system model
might be. One might say that code inspection requires a mental model of system behaviour,
but not an additional model of the requirements. Testing similarly bypasses formal models, but
again not always entirely. Depending on the particular testing methodology, models of system
behaviour, expected output, code coverage and more may be used. These correspond to the
high-level system specification (coverage) and requirements (test sets). Here, one might say
that testing does not require a physical execution model because it runs the physical system,
but it does require some kind of model of correct system behaviour.
2.2 The promise
The basic promise of formal verification is the following.
Make sure software works.
Convince others that it does.
The first part of this promise concerns software correctness. As we will see in the next
section, we need to be more precise at this point. Correct software can still be useless. The
common meaning of works is that the software fulfils the user’s or customer’s requirements
and expectations. The more specialised meaning often employed in the context of verifying
software (formally or otherwise), is that the implementation fulfils its specification.
There are a number of techniques that can be used to achieve this kind of correctness.
Current industry best practice comes down to code inspection and testing. The alternative
is formal verification. Formal verification is used in industry, but not nearly as widely as
testing and inspection. We will analyse specific advantages and disadvantages of these three
approaches further below.
The second part of the promise is possibly even more interesting than the first. It is not
enough to build a piece of software and be confident that it works as intended. One needs to
be able to demonstrate that it does work and convince others of the fact. If you are building a
new model of airplane that will transport millions of people during its product cycle lifetime,
you need to be able to convince the relevant authority such as the FAA that the plane and
its software are safe. If you are building a storage device for secret information, you need to
convince software certification bodies like the NSA that the secret cannot be leaked.