Information Technology Reference
In-Depth Information
different instruction set architectures in wide use today, there are a huge number
of different types of physical I/O devices, manufactured by a large number of
companies. There is diversity in the hardware interfaces to devices as well as
in the hardware chip sets for managing the devices. A recent survey found
that approximately 70% of the code in the Linux kernel was in device-specific
software.
To keep the rest of the operating system kernel portable, we want to decouple
the operating system source code from the specifics of each device. For instance,
suppose a manufacturer creates a new model a printer | what steps are needed
by the operating system manufacturer to accommodate that change?
The key innovation, widely adopted today, is a dynamically loadable device
driver . A dynamically loadable device driver is software to manage a specic
Denition: dynamically
loadable device driver
device or interface or chipset, that is added to the operating system kernel after
the kernel starts running, to handle the devices that are present on a particular
machine. The device driver code is typically written by the device manufacturer,
using a standard interface provided by the kernel. The operating system kernel
calls into the driver whenever it needs to read or write data to the device.
At boot, the operating system starts with a small number of device drivers
{ e.g., for the disk (to read the operating system binary into memory). For
the devices physically attached to the computer, the computer manufacturer
bundles those drivers into a file it stores along with the bootloader. When the
operating system starts up, it queries the I/O bus for which devices are attached
to the computer and then loads those drivers from the file on disk. Finally, for
any network-attached devices, such as a network printer, the operating system
can load those drivers over the Internet.
While dynamically loadable device drivers solve one problem, they pose a
different one. Errors in a device driver can corrupt the operating system kernel
and application data structures; just as with a regular program, errors may
not be caught immediately, so that user may be unaware that their data is
being silently modified. Even worse, a malicious attacker can use device drivers
to introduce a computer virus into the operating system kernel, and thereby
silently gain control over the entire computer. Recent studies have found that
90% of all system crashes were due to bugs in device drivers, rather than in the
operating system itself.
Operating system developers have taken three approaches to dealing with
this issue:
Code inspection. Operating system vendors typically require all device
driver code to be submitted in advance for inspection and testing, before
being allowed into the kernel.
Bug tracking. After every system crash, the operating system can col-
lect information about the system configuration and the current kernel
stack, and sends this information back to a central database for analysis.
