Information Technology Reference
In-Depth Information
However, because Nooks' lightweight protection
domains execute on kernel threads that share the
kernel address space, they reduce the costs of
scheduling and data copying on a domain change
when compared to normal cross-address space or
kernel-user RPCs.
To reduce the performance cost of XPC, Nooks
supports deferred calls , which batch many calls
into a single domain crossing. Nooks can defer
function calls that have no visible side effects to
the call. Wrappers queue deferred function calls
for later execution, either at the entry or exit of a
future XPC. Each domain maintains two queues:
a driver-domain queue holds delayed kernel calls,
and a kernel-domain queue holds delayed driver
calls. As an example, Nooks changes the packet-
delivery routine used by the network driver to
batch the transfer of message packets from the
driver to the kernel. When a packet arrives, the
driver calls a wrapper to pass the packet to the
kernel. The wrapper queues a deferred XPC to
deliver the packet after the driver completes
interrupt processing.
object types used by drivers, there is a unique
type identifier and code to release instances of
that type during recovery. Complex types also
have a routine to copy changes between a kernel
and driver instance of the type.
When an object “dies” and is no longer usable
by a driver, the object tracker must remove the
object from its database. Determining when an
object will no longer be used requires a careful
examination of the kernel-driver interface. This
task is possible because the kernel requires the
same information to safely reclaim shared objects.
For example, some objects are accessible to the
driver only during the lifetime of a single XPC
call from the kernel. In this case, Nooks adds
the object to the tracker's database when the call
begins and removes it on return. Other objects
are explicitly allocated and deallocated by the
driver, in which case Nooks knows their lifetimes
exactly. In still other cases, Nooks relies in the
semantics of the object and its use. For example,
drivers allocate a timer data structure to register
for a future callback. Nooks adds this object to
the object tracker when a driver calls the kernel
to add the timer and removes it when the timer
fires, at which point it is no longer used. The
object-tracking code is conservative, in that it
may under-estimate the lifetime of an object and
unnecessarily add and remove the same object
from the database multiple times. It will not,
however, allow a driver to access an object that
the kernel has released.
In addition to tracking objects in use by driv-
ers, the tracker must record the status of locks that
are shared with the kernel. When a driver fails,
Nooks releases all locks acquired by the driver
to prevent the system from hanging. As a result,
calls to lock kernel data structures require an XPC
into the kernel to acquire the lock, synchronize the
kernel and driver versions of the data structure,
and record that the lock was acquired.
Object Tracking
The object tracker facilitates the recovery of kernel
objects following a driver failure. The Nooks ob-
ject tracker performs two independent tasks. First,
it records the addresses of all objects in use by a
driver in a database. As an optimization, objects
used only for the duration of a single XPC call are
recorded on the kernel stack. Objects with long
lifetimes are recorded in a per-protection-domain
hash table. Second, for objects that drivers may
modify, the object tracker creates and manages
a driver version of the object and records an as-
sociation between the kernel and driver versions.
Wrappers rely on this association to map param-
eters between the driver's protection domain and
the kernel's protection domain.
The Nooks implementation supports many
kernel object types, such as tasklets, PCI devices,
inodes, and memory pages. For each of the 52
Search WWH ::




Custom Search