Check out the new USENIX Web site. next up previous
Next: The TCP Model Up: The Model Checking Framework Previous: Why the Conventional Approach

Running the Entire Linux Kernel

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 up previous
Next: The TCP Model Up: The Model Checking Framework Previous: Why the Conventional Approach
Madanlal Musuvathi 2004-03-03