Reasons Windows NT Device Drivers Contain "Trusted" Code

• Microsoft Windows NT operating system, version 3.1
• Microsoft Windows NT Advanced Server, version 3.1

In the process of designing an operating system I/O subsystem, there are many different methods to combine device drivers and file systems. Each design possibility has its own advantages and disadvantages, including those that affect ease of debugging, system robustness, and performance.

The Windows NT I/O system was designed such that it forces the system to trust device drivers. There are three primary reasons for this restriction, as follows:

Drivers Run In Kernel Mode

Any kernel-mode code can perform any operation in the system. For example, a driver can load a pointer with the base address of the System Virtual Address space and go into a loop, writing zeros over the executive system, the nonpaged memory pool, or anywhere else in memory.

The alternative to running drivers in kernel mode involves running drivers in user mode. A bug in a user-mode driver affects only the driver which can ease the process of debugging the driver. These advantages are countered by the disadvantage that a user-mode driver requires its own virtual address space and must be its own process. Because the time required to switch contexts into a user-mode driver seriously degrades performance, kernel mode was chosen instead.

No Argument Checking

Because a driver runs in kernel mode and have unfettered access to the system, the design of the system assumes that a driver does not perform any unintended operations. In other words, they, like the executive system, have been thoroughly debugged and are virtually bug free. If this is true, then it follows that they do not specify incorrect parameters in calls to executive functions. For example, a driver is assumed not to attempt to free an MDL that has a NULL address. Because the system does not check each argument for driver-level function calls as the system does for applications, it runs faster and has better response time.

Driver Directory Protection

In a fully-secure system, the system administrator configures the system so all disk partitions run the Windows NT file system (NTFS). This allows the administrator to place an access control list (ACL) on the directory from which the system loads drivers to prevent unauthorized access to the directory. Doing so eliminates the possibility that a user can load a "Trojan Horse" driver. Of course, a secure system uses the same mechanism to protect the portion of the Registry that lists the drivers to load and their locations.

As the text above indicates, the primary reasons to make drivers trusted involve performance. Drivers run in kernel mode, in the caller's context or in the context of an interrupt or DPC, which eliminates the large overhead a context switch requires. The system does not check the arguments they pass to executive functions for performance reasons as well. Finally, if you configure your system correctly, it is protected from loading a bad driver.