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

In other cases, Nooks avoids copying entirely by
changing the protection on the page containing
an object. A “page tracker” mechanism within the
object tracker remembers the state of these mapped
pages and grants and revokes driver access to the
pages. Nooks uses this mechanism to avoid copy-
ing network packets and disk blocks.
Writing a wrapper requires knowing how
drivers use a parameter: whether it is live across
multiple calls to the drivers, whether it can be
passed to other threads or back to the kernel, and
which fields of the parameter can be modified.
This analysis can be manual or performed by static
analysis tools that determine these properties by
analyzing an existing set of drivers.

domain-local page table explicitly by reloading
the hardware page table base register.
Furthermore, Nooks currently does not protect
the kernel from Direct MemoryAccess (DMA) by
a device into the kernel address space. Isolation
is provided through virtual memory page tables,
but devices use DMA to directly access physical
memory. Preventing a rogue DMA requires an IO
memory management unit (IOMMU), which is not
common on PC-class x86 computers. However,
Nooks tracks the set of pages writable by a driver
and could use this information to restrict DMA on
a machine with the suitable hardware support.

Communication

Isolation Nooks uses the extension procedure call (XPC)

mechanism to transfer control between driver and
kernel domains. The wrapper mechanism makes
the XPC mechanism invisible to both the kernel
and drivers, which continue to interact through
their original procedural interfaces.
Two functions internal to Nooks manage XPC
control transfer: one to transfer from the kernel
into a driver, and one to transfer from drivers into
the kernel. These functions take a function pointer,
an argument list, and a protection domain. They
execute the function with its arguments in the
specified domain. The transfer routines save the
caller's context on the stack, find a stack for the
calling domain (which may be newly allocated or
reused when calls are nested), change page tables
to the target domain, and then call the function.
XPC performs the reverse operations when the
call returns.
Changing protection domains requires a change
of page tables. The Intel x86 architecture flushes
the TLB on such a change, and hence there is a
substantial cost to entering a lightweight protection
domain, both from the flush and from subsequent
TLB misses. This cost could be mitigated in a
processor architecture with a tagged TLB, such as
the MIPS or Alpha, or with single-address-space
protection support, such as the IA-64 or PA-RISC.

The isolation component of Nooks provides
memory management to implement lightweight
kernel protection domains with virtual memory
protection.
Figure 4 shows the Linux kernel with two
lightweight kernel protection domains, each con-
taining a single driver. All components exist in the
kernel's address space. However, memory access
rights differ for each component: e.g., the kernel
has read-write access to the entire address space,
while each driver is restricted to read-only kernel
access and read-write access to its local domain.
To provide drivers with read access to the ker-
nel, Nooks' memory management code maintains a
synchronized copy of the kernel page table for each
domain. Each lightweight protection domain has
private structures, including a domain-local heap,
a pool of stacks for use by the driver, memory-
mapped physical I/O regions, and kernel memory
buffers, such as socket buffers or I/O blocks, that
are currently in use by the driver.
Nooks protects against bugs but not against
malicious code. Lightweight protection domains
reflect this design. For example, Nooks prevents
a driver from writing kernel memory, but it does
not prevent a malicious driver from replacing the