Next: The TCP Model
Up: The Model Checking Framework
Previous: Why the Conventional Approach
The hard learned lesson from our previous approach is that instead of
choosing a narrow interface, the model should
involve well-defined interfaces.
For the Linux kernel, there are only two such
interfaces: the system call interface that defines the interface
between the kernel and the user processes; and the ``hardware abstraction
layer'' that defines the interface between the kernel and the hardware
architecture. Though Linux does not explicitly define a hardware
abstraction interface, such an interface is implicitly defined for
most kernels to simplify the task of porting the kernel to different
architectures.
Defining the TCP model along these two interfaces requires that the
entire kernel is run in user space as a CMC process. While this might
look like a daunting task, we heavily reused the user space
implementation of the Linux kernel from [38]. This still
requires CMC to deal with the entire kernel state which is
orders of magnitude larger than the TCP relevant state
alone. Section 4 describes techniques by which CMC in
effect automatically extracts the TCP relevant state from the kernel
state.
Using the system call interface and the hardware abstraction interface
has another advantage. These interfaces change very rarely during
future revisions. Thus, the effort required in building a TCP model
can be reused across multiple versions of the kernel.
Next: The TCP Model
Up: The Model Checking Framework
Previous: Why the Conventional Approach
Madanlal Musuvathi
2004-03-03