Abstract
Tradition demands that any book about writing device drivers starts out by answering the question, “What is a driver?” Unfortunately, asking this question in Windows NT is a little like asking “What color is plaid?” because there are at least a dozen different software components that can rightfully be called drivers. This chapter takes a roundabout look at the different kinds of drivers supported by Windows NT, and along the way, presents some of the design philosophy that makes this operating system such an intriguing beast.
OVERALL SYSTEM ARCHITECTURE
Windows NT drivers don’t live in isolation, of course. Rather, they are just one part of a large and complex operating system. This section takes you on a quick tour of the Windows NT architecture and points out those features that will be of most interest to driver writers.
Design Goals for Windows NT
Like every other commercial operating system, Windows NT is the result of a complex interaction between idealized goals and market-driven realities. The Windows NT design team set their sights on the following:
- Compatibility — The operating system should support a wide range of existing software and legacy hardware.
- Robustness and reliability — The operating system has to resist the attacks of naive or malicious users, and individual applications should be as isolated from one another as possible.
- Portability — The operating system should be able to run on a wide variety of current and future hardware platforms.
- Extendibility — It should be possible to add new features and support new I/O devices without perturbing the existing code base.
- Performance — The operating system should be able to give reasonable performance on commonly available hardware. It should also be able to take advantage of features like multiprocessing hardware.
Trying to balance all these goals with a reasonable time to market was a complex process. The rest of this section describes the solution that the system designers came up with — beginning with a look at the protection mechanisms that keep the operating system safe.
Hardware Privilege Levels in Windows NT
There are any number of things that application programs shouldn’t be allowed to do in a multitasking environment. Fooling with the memory management hardware or halting the processor are just two examples of actions that would cause serious problems. Rather than depending on the kindness of strange applications, Windows NT takes advantage of hardware-enforced privilege-checking mechanisms to guarantee system integrity.
To avoid hardware dependencies, Windows NT uses a simplified model to describe hardware privileges. This model then maps onto whatever privilege-checking mechanisms are available on a given CPU. A CPU must be able to operate in two modes if it’s going to support the Windows NT hardware privilege model:
- Kernel mode — Anything goes when the CPU runs in kernel mode. A task can execute privileged instructions, and it has complete access to any I/O devices. It can also touch any virtual address and fiddle with the virtual memory hardware. This mode corresponds to Ring 0 on an Intel 80x86.
- User mode — In this mode, the hardware prevents execution of privileged instructions and performs access checks on references to memory and I/O space. This allows the operating system to restrict a task’s access to various I/O operations, and trap any other behavior that might violate system integrity. Code running in user mode can’t get itself into kernel mode without going through some kind of gate mechanism in the operating system. On an Intel 80x86 processor, this mode corresponds to Ring 3.
Base Operating System Components
The base components of Windows NT implement a general operating system platform on which to build more complex environments. As you can see from Figure 1.1, these base components consist of three major blocks of kernel-mode code.
Hardware Abstraction Layer (HAL) — The HAL is a thin layer of software that presents the rest of the system with an abstract model of any hardware that’s not part of the CPU itself. The HAL exposes a well-defined set of functions that manage such items as:
- Off-chip caches
- Timers
- I/O buses
- Device registers
- Interrupt controllers
- DMA controllers
Various system components use these HAL functions to interact with off-CPU hardware. This essentially hides platform-specific details from the rest of the system and removes the need to have different versions of the operating system for platforms from different system vendors. In particular, the use of HAL routines makes the Kernel and device drivers binary-compatible across platforms with the same CPU architecture.
Kernel — Where the HAL is an abstraction of the platform, the Kernel presents an idealized view of the CPU itself. Among other things, the Kernel provides mechanisms for
- Interrupt and exception dispatching
- Thread scheduling and synchronization
- Multiprocessor synchronization
- Time keeping
By using these Kernel services, upper layers of the operating system can (for the most part) ignore the architecture of the underlying CPU. This makes it possible for drivers and higher-level operating system components to be source-code portable across different CPU architectures.
An interesting feature of the Kernel is that it presents an object-based interface to its clients. When other parts of the operating system need help from the Kernel, they request its services by calling functions that create and manipulate various kinds of objects. These Kernel objects fall into two main categories:
- Dispatcher objects — These are used primarily for managing and synchronizing threads.
- Control objects — These objects affect the behavior of the operating system itself in some way.
Device drivers don’t have much use for dispatcher objects. Those that do are described in Chapter 14. Control objects are another matter, however. In particular, device drivers make frequent use of Deferred Procedure Call objects and Interrupt objects (described in Chapters 3 and 4 respectively).
Executive — The Executive is by far the largest and most complex kernel-mode component in Windows NT. Its job is to implement many of the basic functions normally associated with an operating system. Like the Kernel, the Executive uses the HAL to interact with any off-CPU hardware and so becomes binary compatible across platforms from different system vendors. By relying on Kernel objects, the Executive gains the additional advantage of being source-code portable across different CPU architectures. Because it’s such a key part of Windows NT, it’s worth exploring the Executive a little more.
What’s in the Executive
As you can see from Figure 1.2, the Executive actually consists of several distinct software components that offer their services both to user-mode processes and to one another. These Executive components are completely independent and communicate only through well-defined interfaces. This modularity makes it possible to replace an existing Executive component without perturbing any other parts of the operating system. As long as the replacement exposes the same interface, the change will be transparent. The remainder of this subsection gives cursory descriptions of the various Executive modules.
System service interface — All operating systems have to give user-mode processes a limited ability to execute kernel-mode code. In particular, there must be a controlled path from user to kernel mode that applications can follow when they call system services. In Windows NT, the system service dispatcher uses a technique based on the CPU’s hardware exception mechanism to give user-mode code access to Executive services.
Object Manager — The Executive offers its services to user-mode processes through an object-based interface. These Executive objects represent things such as files, processes, threads, and shared memory segments. This use of objects provides a unified mechanism for tracking resources and enforcing security.
The Object Manager does all the grunt work of managing these Executive objects. This includes creating and deleting objects, maintaining the global object namespace, and keeping track of how many outstanding references there are to any given object.
Configuration Manager — From a driver writer’s perspective, the main job of the Configuration Manager is to maintain a model of all the hardware and software installed on the machine. It does this using a database called the Registry. As you read through the rest of this book, you’ll see that drivers are linked to the Registry through an intricate web of connections. Among other things, drivers use the Registry to
- Identify themselves as trusted system components
- Find and allocate peripheral hardware
- Set up error-logging message files
- Enable driver-performance measurement
Process Manager — A process is the unit of resource-tracking and security access checking in Windows NT. Along with any resources it might be holding, each process has its own virtual address space and security identity. A process also contains one or more executable entities called threads. It is the thread (and not the process) that receives ownership of a CPU and does actual work.
The Process Manager is the Executive component that handles the creation, management, and deletion of processes and threads. It also provides a standard set of services for synchronizing the activities of threads. Most of the features exposed by the Process Manager are just fancy versions of mechanisms implemented by the Kernel.
Security Reference Monitor — This Executive component enforces the system’s security policies. The Security Reference Monitor doesn’t actually define security policy; that job belongs to the Local Security Authority subsystem (described later in this chapter). Rather, the Security Reference Monitor simply provides a set of primitives that both kernel- and user-mode components can call to validate access to objects, check for user privileges, and generate audit messages. For the most part, device drivers don’t concern themselves with security issues.
Device drivers normally don’t do much with the Security Reference Monitor. The I/O Manager handles those kinds of details before it calls any routines in your driver.
Virtual Memory Manager — Under Windows NT, each process has a flat 4-gigabyte virtual address space. The lower half of this space contains process-private code and data along with the process’s stack and heap space. It also holds any File Mapping objects and DLLs the process is using. The upper half of every process’s address space contains nothing but kernel-mode code. One of the jobs of the Executive’s Virtual Memory Manager is to maintain this illusion of a huge address space using demand-paged virtual memory management techniques.
From a driver writer’s point of view, the Virtual Memory Manager is more important as a memory allocator because it maintains the system heap areas. The Virtual Memory Manager also builds and manipulates various buffer descriptors that are crucial to the operation of DMA drivers. Both these topics are covered in more detail later.
Local Procedure Call facility — The Local Procedure Call (LPC) facility is a message-passing mechanism used for communication between processes on the same machine. LPCs are used primarily by protected subsystems (described later) and their clients. Device drivers have no access to the LPC facility.
I/O Manager — This Executive component converts I/O requests from user- and kernel-mode threads into properly sequenced calls to various driver routines. Through the use of a well-defined formal interface, the I/O Manager is able to communicate with all drivers the same way. This makes it unnecessary for the I/O Manager to know anything about the underlying hardware managed by a given driver. The rest of this book describes the operation of the I/O Manager in gory detail.
|
Page: 1, 2, 3, 4 |
next page  |
|
|
|
|
Windows IT Pro
Register
