This chapter introduces the concept of hardened drivers and highlights issues involved in writing them.
"Hardened Drivers" explains what hardening is, particularly device driver hardening.
"Overview of the Process" is a brief description of the steps involved when developing hardened device drivers.
"Developer Resonsibilities" outlines the duties of hardened driver developers.
Hardening refers to the process of ensuring that software is resilient to hardware faults. It concerns the requirement for graceful degradation and failure when the hardware is faulty.
A hardened driver is a driver that is resilient to faults in the I/O device it controls, as well as faults originating outside the system core. The driver does not panic, hang, or allow propogation of corrupted data as a result of these types of faults.
When writing hardened drivers you must assume that even when the underlying device hardware is not working properly, the driver must continue to behave reasonably. The driver must respect the DDI protocols under a hardware failure condition.
All ChorusOS device drivers are held in a hierarchical tree, the ChorusOS device driver framework, to aid referencing and maintenance. A hardened driver must be catered for in that framework. For further information regarding the device driver framework refer to Part III. In order to obtain the desired fail-safe behavior of a leaf device driver, the bus/nexus drivers stored in the path from the DKI to that hardened leaf device driver should also be hardened. Moreover, the operating system as a whole, including the microkernel, drivers, POSIX sub-system and other system actors must be hardened for the hardening effort at microkernel driver level to be effective.
A hardened driver obeys all of the rules of a standard ChorusOS device driver as well as some additional rules:
Each piece of hardware should be controlled by a separate instance of the device driver.
Programmed I/O (PIO) must be performed only through the DDI access functions, using the appropriate data access handler.
The device driver must assume that the data it receives from the device could be corrupt. The driver should check the integrity of the data before using it.
The driver must control the effects of any faults it detects. Data supplied by the device may be checked for integrity before it is released to the rest of the system.
The driver must not be an unlimited drain on system resources if the device locks up. It should timeout if a device claims to be continuously busy. The driver should also detect a pathological (stuck) interrupt request and take appropriate action.
The driver must free up resources after a fault. For example, the system must be able to close all minor devices and detach driver instances, even after the hardware fails.
In order to develop hardened device drivers you must take responsibility for:
Correct use of the DDI functions
Handling devices with deviant interrupt logic
Detecting any corruption of device I/O
These responsibilities are elaborated in Chapter 13, Hardened Driver Requirements.