home *** CD-ROM | disk | FTP | other *** search
/ Borland Programmer's Resource / Borland_Programmers_Resource_CD_1995.iso / info / ntkb / ntkb.exe / Q101 / 5 / 03.TXT < prev    next >
Encoding:
Text File  |  1993-11-16  |  4.3 KB  |  94 lines
  1. DOCUMENT:Q101503  04-NOV-1993  [W_NT]
  2. TITLE   :INF: Reasons Windows NT Device Drivers Contain "Trusted" Code
  3. PRODUCT :Windows NT
  4. PROD/VER:3.10
  5. OPER/SYS:WINDOWS
  6. KEYWORDS:
  7.  
  8. --------------------------------------------------------------------
  9. The information in this article applies to:
  10.  
  11.  - Microsoft Windows NT operating system, version 3.1
  12.  - Microsoft Windows NT Advanced Server, version 3.1
  13. --------------------------------------------------------------------
  14.  
  15. In the process of designing an operating system I/O subsystem, there
  16. are many different methods to combine device drivers and file systems.
  17. Each design possibility has its own advantages and disadvantages,
  18. including those that affect ease of debugging, system robustness, and
  19. performance.
  20.  
  21. The Windows NT I/O system was designed such that it forces the system
  22. to trust device drivers. There are three primary reasons for this
  23. restriction, as follows:
  24.  
  25. Drivers Run In Kernel Mode
  26. --------------------------
  27.  
  28. Any kernel-mode code can perform any operation in the system. For
  29. example, a driver can load a pointer with the base address of the
  30. System Virtual Address space and go into a loop, writing zeros over
  31. the executive system, the nonpaged memory pool, or anywhere else in
  32. memory.
  33.  
  34. The alternative to running drivers in kernel mode involves running
  35. drivers in user mode. A bug in a user-mode driver affects only the
  36. driver which can ease the process of debugging the driver. These
  37. advantages are countered by the disadvantage that a user-mode driver
  38. requires its own virtual address space and must be its own process.
  39. Because the time required to switch contexts into a user-mode driver
  40. seriously degrades performance, kernel mode was chosen instead.
  41.  
  42. No Argument Checking
  43. --------------------
  44.  
  45. Because a driver runs in kernel mode and have unfettered access to the
  46. system, the design of the system assumes that a driver does not
  47. perform any unintended operations. In other words, they, like the
  48. executive system, have been thoroughly debugged and are virtually bug
  49. free. If this is true, then it follows that they do not specify
  50. incorrect parameters in calls to executive functions. For example, a
  51. driver is assumed not to attempt to free an MDL that has a NULL
  52. address. Because the system does not check each argument for
  53. driver-level function calls as the system does for applications, it
  54. runs faster and has better response time.
  55.  
  56. Driver Directory Protection
  57. ---------------------------
  58.  
  59. In a fully-secure system, the system administrator configures the
  60. system so all disk partitions run the Windows NT file system (NTFS).
  61. This allows the administrator to place an access control list (ACL) on
  62. the directory from which the system loads drivers to prevent
  63. unauthorized access to the directory. Doing so eliminates the
  64. possibility that a user can load a "Trojan Horse" driver. Of course, a
  65. secure system uses the same mechanism to protect the portion of the
  66. Registry that lists the drivers to load and their locations.
  67.  
  68. As the text above indicates, the primary reasons to make drivers
  69. trusted involve performance. Drivers run in kernel mode, in the
  70. caller's context or in the context of an interrupt or DPC, which
  71. eliminates the large overhead a context switch requires. The system
  72. does not check the arguments they pass to executive functions for
  73. performance reasons as well. Finally, if you configure your system
  74. correctly, it is protected from loading a bad driver.
  75.  
  76. Additional reference words: 3.10
  77. KBCategory:
  78. KBSubcategory: DEVDRVR
  79.  
  80. =============================================================================
  81.  
  82. THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS
  83. PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND.  MICROSOFT DISCLAIMS
  84. ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES
  85. OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  IN NO
  86. EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR
  87. ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL,
  88. CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF
  89. MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE
  90. POSSIBILITY OF SUCH DAMAGES.  SOME STATES DO NOT ALLOW THE EXCLUSION
  91. OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES
  92. SO THE FOREGOING LIMITATION MAY NOT APPLY.
  93.  
  94. Copyright Microsoft Corporation 1993.