PSS ID Number: 101503
Article Last Modified on 11/20/2003
The information in this article applies to:
- Microsoft Windows NT Server 3.1
- Microsoft Windows NT Workstation 3.1
- Microsoft Windows NT Advanced Server 3.1
This article was previously published under Q101503
SUMMARY
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.
Additional query words: prodnt
Keywords: kbother KB101503
Technology: kbWinNT310Search kbWinNTAdvSerSearch kbWinNTAdvServ310 kbWinNTS310 kbWinNTS310search kbWinNTsearch kbWinNTSsearch kbWinNTW310 kbWinNTW310Search kbWinNTWsearch
