Operating system verification—An overview

Operating system verification—An overview 31
The bottom layer of figure 2 shows the physical artefacts. Strictly speaking, the physical
artefacts are the microchips, the transistors, their electrical charges, and the environment the
machine operates in. Describing these precisely is the realm of physics, and if pursued to
the end, the question of whether we can even describe and predict reality in full detail is a
matter of philosophy. Fetzer (1988) uses this observation in a well-cited and much discussed,
but ultimately pointless article to reject the whole idea of formal program verification as
impossible. Following this view, we might just as well give up on any science that uses
mathematics to model and predict reality. Pragmatically, the choice for this bottom layer still
is a matter of lively discussion, together with the question of what a good formal model should
therefore correspond to. The verification projects surveyed in the second part of this article
start from different levels of abstraction with different aims and choices. Some examples for
what is considered the physical artefact are C source code, assembly source code, assembly
binary code including memory contents, or a VHDL description of the machine. Program
source code could be viewed as a physical artefact, and it is usually the lowest level a software
development project deals with. Nevertheless, if one aims to eliminate all possible sources
of error in an implementation, there is a large gap between the source code and the physical
memory state of a computer—it involves at least the compiler, the linker, the operating system,
and input devices. Even a gate level description of the microprocessor might still not be
precise enough to capture reality fully. Where one makes the cut-off depends on what level
of assurance one is interested in and where a point of diminishing returns is reached.
Although often confused with formal artefacts, all of the above-mentioned concepts (program
source code, assembly code, gate level description) are not formal yet. They may be
very close to formal artefacts, and in an ideal world they even might be, but currently they
are merely inputs for tools or machines that we use in development. We still cannot reason
about them directly. For that to be possible, we again need a translation into formal logic,
preferably in the same formal framework that we use for specification and requirements. For
example, in this context, even a VHDL description itself would not be a formal artefact,
whereas its translation into the formalism of the theorem prover would be. The distinction
becomes clearer for higher-level programming languages. An example of this would be a
formal semantics of the C programming language that assigns logical meaning to each of the
syntactic constructs of the language, for instance describing how each statement changes the
machine state. Although Norrish (1998) comes close, there currently exists no such semantics
for the full C language. Currently, programs as such are clearly not formal artefacts.
It is only at this point, with the translations from ideal concepts and from the physical world
into formal logic, that we can use the tool of formal proof. In an ideal setting, at this point we
are able to make formal correctness guarantees with an absolute degree of assurance. Even
in the less than perfect real world, with machine-checked proof we can achieve a level of
assurance about our formal statements that surpasses our confidence in mathematical theorems
which we base all of physics and engineering on. Not trusting these makes as much sense as
not trusting the theorem of Pythagoras.
There exist several different kinds of formal methods that may be used to prove the connections
between properties, specification, and model. They range from fully automatic methods
that may even construct the system model automatically from source code to interactive methods
that require human guidance. The trade-off is between the expressiveness of the logic and
the degree of automation. Logics with little expressiveness, e.g. propositional logic, make it
hard to write down the three required logical artefacts and hard to understand the resulting
formalisations, but they offer a high degree of automation in return. So-called SAT (satisfiability)
solvers are such successful, automated tools. Logics with a high degree of expres-