Developing Drivers with the Windows Driver Foundation (Pro Developer)

2017-07-07 02:10:07

Your choice of which framework to use for your device-UMDF or KMDF-depends primarily on the type of device. This section is a general discussion of which types of devices the two frameworks support and the issues you should consider when choosing the appropriate framework.

Info See "FAQ: Questions from Driver Developers about Windows Driver Foundation" on the WHDC Web site for a complete list of the devices that UMDF and KMDF support-online at http://go.microsoft.com/fwlink/?LinkId=81576.

Devices Supported by UMDF

UMDF UMDF supports the development of drivers for protocol-based or serial bus-based devices, such as USB devices. UMDF can be used to implement drivers for 32-bit and 64-bit devices to run on x86 or x64 versions of Windows, respectively. Some examples include the following:

Portable devices, such as PDAs, cell phones, and media players.

USB devices, except for isochronous devices.

Auxiliary display and video devices.

The device can be directly connected, connected over a network, or connected through a wireless technology such as Bluetooth. UMDF can also be used to implement software-only drivers.

32-bit and 64-bit UMDF Drivers

We're frequently asked if UMDF will allow a developer to run a 32-bit driver on a 64-bit system. This isn't allowed for WDM or KMDF drivers because you can't run 32-bit code in the 64-bit kernel. But because you can run a 32-bit application on a 64-bit system, the question always seems to come up.

It isn't possible. Although UMDF could run the 32-bit driver code, it has no way of knowing how to handle requests from a 64-bit application. Just as 64-bit kernel-mode drivers often need special code to handle I/O controls from 32-bit applications, a 32-bit driver on a 64-bit machine would need to be able to special-case calls from 64-bit applications. UMDF cannot just let the requests go through because it could cause a buffer overflow or other security bug.

In my opinion, it's not a big loss. The driver already has to be rewritten to run in user mode anyway, so why not compile it for 64-bit while you're rewriting? And because 32-bit and 64-bit applications have some subtle behavior differences, you'd still want to test your driver on a 64-bit system. So at that point, why not just build and test a 64-bit driver?-Peter Wieland, Windows Driver Foundation Team, Microsoft

Advantages of UMDF Drivers

UMDF drivers have numerous advantages over kernel-mode drivers.

Driver Environment

UMDF drivers operate in an environment that is much simpler than the environment in which kernel-mode drivers operate. For example, kernel-mode drivers must be coded to avoid problems related to IRQL, page faults, and thread context. In user mode, however, these issues do not exist. UMDF drivers can always take page faults. In addition, UMDF drivers always run in an address space that is separate from that of the requesting process.

Improved System Stability

Unlike kernel-mode drivers, the environment in which UMDF drivers run is isolated from the rest of the system. In particular, each UMDF driver runs in its own address space, which another driver cannot overwrite or corrupt. A corrupted or buggy UMDF driver might render the device inoperable, but a UMDF driver is much less likely to cause system-wide problems than a kernel-mode driver. In particular, UMDF drivers cannot cause bug checks, because they cannot access the kernel address space and cannot call the kernel-mode functions that are required to manipulate important system data structures.

Reduced Security Risks

UMDF drivers usually run in the LocalService account, which provides only limited privileges. The fact that UMDF drivers usually run with low privileges makes UMDF drivers relatively unattractive targets for security exploits, because a compromised UMDF driver has only limited access to system resources. If an attacker does compromise a UMDF driver, the only user data that is at risk is the data that flows through the driver. In addition, UMDF drivers are much less likely to cause a denial-of-service attack by hanging or crashing the system. At worst, the driver process itself could become corrupted, but it can be terminated without affecting other processes.

Important

UMDF drivers can support impersonation, but the driver must register for this capability when it is installed and be granted permission to impersonate the user by the application that makes the request. Although these factors limit the risk, UMDF drivers that support impersonation must still be careful. If the driver is compromised, the injected code could wait until the driver receives a request from an administrator that allows impersonation. At that point, the driver can impersonate an administrator and attack the system.

Windows API

Most applications programmers are familiar with the Windows API. UMDF drivers cannot call kernel functions, but they can call much of the Windows API, which provides access to services such as cryptography that are not available in kernel mode. However, UMDF driver processes run in a session that does not permit user interaction, so the driver cannot use those parts of the Windows API that support user interfaces.

Because the Windows API is a user-mode component, Windows performs additional security and verification checks before making changes that a user-mode caller requests. You must still be careful when calling external processes or components. For example, if you load a compromised COM object into your driver as an in-process component, you have just created a security hole. The Windows API also might not be suitable for use within an asynchronous I/O model. For example, a long running synchronous operation that cannot be canceled could force a driver to handle its requests synchronously, limiting the performance of the driver.

Drivers and User Interfaces

Don't try to have your driver put up a UI. Just because the driver is running in user mode doesn't mean that you can use it to display UI elements. UMDF drivers run in "session 0" along with other system services and do not have a desktop. Not only does this mean that the user cannot see any UI elements you put up, it also means that you can hang your driver if any of that UI blocks while waiting for user input, because the user can't provide any.

If you want to provide UI, then you should build a separate interface component that communicates with your driver through the standard Windows I/O calls.-Peter Wieland, Windows Driver Foundation Team, Microsoft

User-Mode Debugging

UMDF drivers can be debugged by using a user-mode debugger instead of a kernel-mode debugger. Debugging and driver development in user mode can be faster because an error affects only the current process, not the entire system. This reduces the time that is spent rebooting after a system crash caused by bugs in a kernel-mode driver. In addition, UMDF debugging requires only a single computer, whereas kernel-mode debugging usually requires two computers: a host machine for the debugger and a target machine for the driver.

Programming in C++ or C

UMDF is based on COM, so drivers can be readily implemented by using C++. It is also possible to implement UMDF drivers in C, although this is not often done.

Comparable Performance to Kernel Mode

For the types of devices that UMDF drivers can support, the rate-limiting factor is usually I/O bandwidth, not internal driver performance. For such devices, UMDF driver performance is comparable to equivalent KMDF drivers.

Limitations of UMDF drivers

Although running in user mode has many advantages, being unable to access the kernel-mode address space imposes certain limitations. Some drivers simply cannot run in user mode and cannot be implemented as UMDF drivers. Drivers must be written as kernel-mode drivers if they require any of the following features and resources:

Direct access to hardware, including the ability to handle interrupts.

Uninterrupted timing loops.

Access to kernel data structures or kernel memory.

In addition, a UMDF driver cannot be a client of the Windows kernel or of a kernel-mode driver.

Devices Supported by KMDF

KMDF KMDF was designed to replace WDM, so it can be used to develop drivers for the same devices and device classes as WDM. The exceptions are device classes that are supported by some miniport models, such as Storport drivers.

In general, a driver that conforms to WDM, supplies entry points for the major I/O dispatch routines, and handles IRPs can also be implemented as a KMDF driver. For some device types, device class drivers and port drivers supply driver dispatch functions and call back to a miniport driver-which is essentially a device-specific callback library-to handle specific I/O details. The version of the framework included with the Windows Server "Longhorn" version of the WDK does not support most miniport drivers or device types that use the Windows Image Acquisition (WIA) architecture.

Info See "WDM to KMDF Porting Guide" on the WHDC Web site for a discussion of how to port existing WDM drivers to KMDF-online at http://go.microsoft.com/fwlink/?LinkId=82319.

KMDF and WDM

The fact that the framework appears as a WDM device object with WDM interfaces above and below is what allows KMDF to be a general solution that can work with a variety of device stacks. This is the real power of KMDF in terms of compatibility and its applicability to multiple device classes.

On the other hand, this capability is also one of the largest burdens on the KMDF development and test teams. The abstractions and objects that the framework implements must be compatible with multiple device classes that have already shipped and cannot change to match the new framework behavior. A tremendous amount of testing and design went into the externally facing interfaces-like the power-related callbacks-to ensure compatibility across the board.-Doron Holan, Windows Driver Foundation Team, Microsoft

Choosing the Right Framework

Although choosing a framework might seem like a major decision, it's actually simple. If you can write a UMDF driver for your device, do so. You'll save time in development and debugging, and your driver will be more secure and stable. Write kernel-mode drivers only when necessary. For most device types, the decision is straightforward. For example:

An MP3 player can have a UMDF driver because the player uses the Windows Portable Devices model.

A typical network adapter handles interrupts and performs DMA, so it must use a KMDF driver.

A few device types-most importantly, USB devices-are supported by both frameworks. Most USB devices can be supported by UMDF drivers. However, if the driver must use services that are available only with KMDF, you must implement a KMDF driver.

Note Neither KMDF nor UMDF supports the development of file system drivers or file system filter drivers. To develop a file system driver, you must use the installable file system kit, which is provided with the WDK.