Device Driver Reliability - Advanced Operating Systems and Kernel Applications - page 20

drivers). Every driver in Nooks executes within its
own lightweight kernel protection domain . This
domain is an execution context with the same
processor privilege as the kernel but with write
access to a limited portion of the kernel's address
space. The major task of the isolation mechanism
is protection-domain management. This involves
the creation, manipulation, and maintenance of
lightweight protection domains.

that passes between the driver and kernel. Kernel
routines can then avoid scrutinizing parameters,
executing checks only when called from unreli-
able drivers.

Recovery

Nooks' recovery functions detect and recover from
a variety of driver errors. Nooks detects a software
fault when an extension invokes a kernel service
improperly (e.g., with invalid arguments) or when
an extension consumes too many resources. In this
case, recovery policy determines whether Nooks
triggers recovery or returns an error code to the
driver, which can already handle the failure of
a kernel function. Triggering recovery prevents
further corruption, but may degrade performance
by recovering more frequently. Nooks detects
a hardware fault when the processor raises an
exception during driver execution, e.g., when a
driver attempts to read unmapped memory or to
write memory outside of its protection domain.
Unmodified drivers are unable to handle their own
hardware faults, so in such cases Nooks always
triggers a higher-level recovery.
Nooks relies on shadow drivers to recover
from the failure of a driver. Shadow drivers are a
recovery service that leverage the shared properties
of a class of drivers for recovery. The architecture
consists of three components: shadow drivers,
taps, and a shadow recovery manager.
A shadow driver is a kernel agent that facilitates
recovery for an entire class of device drivers. A
shadow driver instance is a running shadow driver
that recovers for a single, specific driver. The
shadow instance compensates for and recovers
from a driver that has failed. When a driver fails,
its shadow restores the driver to its pre-failure state.
This allows, for example, the recovered driver to
complete requests made before the failure.

Communication

The Nooks communication mechanisms enable
procedure calls between lightweight protection
domains. Unlike system calls, which are always
initiated by an application, the kernel frequently
calls into drivers. These calls may generate call-
backs into the kernel, which may then generate
a call into the driver, and so on. This complex
communication style is handled by a new kernel
service, called the Extension Procedure Call
(XPC) - a control transfer mechanism specifically
tailored to isolating driver within the kernel. An
XPC combines both a protection domain change
and a procedure call. This mechanism resembles
a system call, in that parameters must be verified
on entry to the kernel. However, XPC also occurs
from the kernel into the driver as well.

Object Tracking

Nooks object-tracking functions oversee all kernel
resources used by drivers. In particular, object-
tracking code: (1) maintains a list of kernel data
structures that are manipulated by a driver, (2)
controls all modifications to those structures, and
(3) provides object information for cleanup when
a driver fails. Protection domains prevent drivers
from directly modifying kernel data structures.
Therefore, object-tracking code must copy kernel
objects into a driver domain so they can be modi-
fied and copy them back after changes have been
applied. When possible, object-tracking code veri-
fies the type and accessibility of each parameter