Re: Download User Mode Driver Framework 1.9
Renzo Hayami
UMDF drivers abstract hardware functionality, run in the user-mode environment, and can access various services. UMDF drivers operate as part of a stack of drivers that manage a device. File system drivers, display drivers (for full display devices, not display-only display devices), and print drivers cannot be UMDF drivers.
The driver host process loads vendor-supplied UMDF drivers and framework DLLs, provides an execution environment for user-mode drivers, and routes messages between drivers in a user-mode stack. For more information, see UMDF Driver Host Process.
The reflector is a kernel-mode driver that permits an application and a driver host process (and user-mode device stacks) to communicate. The reflector creates a separate device object for each device instance and handles Plug and Play (PnP) and power I/O requests associated with each device instance. All communication between the application and the driver host process happens through the reflector. For more information, see Architecture of UMDF.
Windows Driver Frameworks (WDF) is a set of libraries that you can use to write device drivers that run on the Windows operating system. WDF defines a single driver model that is supported by two frameworks: Kernel-Mode Driver Framework (KMDF) and User-Mode Driver Framework (UMDF). This topic provides answers to frequently asked questions about UMDF.
A driver written in UMDF version 2 is written in the C programming language. This same driver can then be easily compiled for KMDF. Additionally, a UMDF version 1 driver must be written according to the COM programming model.
Yes. Even if your driver requires access to some kernel-mode resources or features, you might be able to split your driver into two parts. This approach enables you to benefit from some of the advantages of developing and running drivers in user mode.
UMDF drivers run in a driver host process, which runs in the security credentials of a LocalService account, although the host process itself is not a Windows service. Thus, user-mode drivers are as secure as any other user-mode service. When a UMDF driver issues I/O requests, it can optionally impersonate its client process. Impersonation enables the driver thread to run in the security context of the client so that the system performs access checks against the client's identity rather than that of the driver host process.
A user-mode driver is started by the Driver Manager and runs in a driver host process. A single instance of the driver can service simultaneous requests from multiple applications. To communicate with the driver, applications issue I/O requests to the driver's device through the Win32 API. The primary entry point in a user-mode driver is the IDriverEntry interface (UMDF 1.11 and earlier) or the DriverEntry routine (starting in UMDF 2.0), rather than a main() function.
Standard device drivers can be difficult to write because they must handle a very wide range of system and device states, particularly in a multithreaded software environment. Badly written device drivers can cause severe damage to a system (e.g., BSoD or data corruption) since all standard drivers have high privileges when accessing the kernel directly. The User-Mode Driver Framework insulates the kernel from the problems of direct driver access, instead providing a new class of driver with a dedicated application programming interface at the user level of interrupts and memory management. If an error occurs, the new framework allows for an immediate driver restart without impacting the system. This is particularly useful for devices that are intermittently connected to the system or support hot swapping via a bus technology such as USB or FireWire.
The driver object is an instance of the framework-provided IWDFDriver interface. The driver provides a set of callbacks via the IDriverEntry COM interface, which is the main entry point for driver customization.
Windows Driver Frameworks (WDF) contains UMDF, a framework for the creation of user-mode drivers. Like Kernel-Mode Driver Framework (KMDF), UMDF provides an abstraction layer from WDM, handling much of the Plug and Play (PnP) and power management functionality, and allowing the driver to opt in for specific functionality and event handling.
Writing a driver using UMDF version 1 requires using the COM programming model to write C++ code. While UMDF version 2 is based on the same conceptual driver programming model as KMDF, UMDF 1 implements the model with different components, device driver interfaces (DDIs), and data structures. All new UMDF drivers should be written using UMDF 2. No new features are being added to UMDF 1 and there is limited support for UMDF 1 on newer versions of Windows 10 and Windows 11.
In contrast, starting in UMDF version 2, you can write a UMDF driver in the C programming language that calls many of the methods that are available to KMDF drivers. All of the interfaces that are shared between UMDF version 2 and KMDF have the same names, parameters, and structure definitions. If your driver uses only shared functionality, or uses conditional macros around calls that are only supported in one framework, you can write a single driver that you can compile with either UMDF or KMDF. For more information, see How to generate a UMDF driver from a KMDF driver.
This article introduces an update that installs User-Mode Driver Framework (UMDF) version 1.11 on Windows operating systems.
UMDF supports user-mode drivers that are written specifically to use it. UMDF driver packages that are built by using Windows Driver Kit for Windows 8 can automatically redistribute and install version 1.11 of the files. During driver package installation, the package checks the computer to determine what version of UMDF is currently installed, and then the package updates the files to 1.11 if they are an older version.
Improves support for Supporting Idle Power-Down in UMDF-based drivers. The framework can now put the device in the D3cold power state when the idle time-out period expires. The framework can also cause the device to return to its working (D0) state when the system returns to its working (S0) state.
This article introduces an update that installs Kernel-Mode Driver Framework (KMDF) version 1.11 on Windows operating systems.
KMDF supports kernel-mode drivers that are written specifically to use it. KMDF driver packages that are built by using Windows Driver Kit for Windows 8 can automatically redistribute and install version 1.11 of the files. During driver package installation, the package checks the computer to determine what version of KMDF is currently installed, and then the package updates the files to 1.11 if they are an older version.
Unlike KMDF drivers, which run as driver objects representing a .sys image file, UMDF drivers run in a driver host process, similar to a service-hosting process. The host process contains the driver itself (which is implemented as an in-process COM component), the user-mode driver framework (implemented as a DLL containing COM-like components for each UMDF object), and a run-time environment (responsible for I/O dispatching, driver loading, device-stack management, communication with the kernel, and a thread pool).
Kernel-mode drivers If specific kernel support for a device that is managed by a UMDF driver is needed, it is also possible to write a companion kernel-mode driver that fills that role. In this way, it is possible for a device to be managed both by a UMDF and a KMDF (or WDM) driver.
If a driver runs in kernel mode it obviously can manipulate everything (well everything in ring 0), so manipulating the file system or devices is a possibility. Potentially devices can be destroyed, for example by manipulating acpi, stopping the ventilators, ....
The main question is: If I have a malicious driver in user mode what can I expect to happen and what won't happen? Everything under the assumption, that the security mechanisms of Windows work as intended.
User-mode drivers "plug into" a kernel interface for interacting with hardware, so in theory they can do approximately anything that a kernel-mode driver can do, aside from things that the driver framework doesn't support. For example, if the hardware maps its I/O to specific physical memory addresses, the kernel can map those addresses to the user-mode process; true DMA is not available from user-mode, but a user-mode driver can request that the kernel map arbitrary memory ranges into its address space.
User-mode drivers also usually run with very high privileges, including the ability to install kernel-mode drivers if so desired. The point of user-mode drivers is to make them easier to develop and debug, and less likely to trigger a kernel panic if they fail (though note that e.g. two WDDM user-mode video driver crashes in rapid succession will still cause a panic, or would last time I tested extremely beta NVidia drivers). It is not a matter of protecting the machine, either its data or its hardware, from malicious code. Don't load untrustworthy drivers, kernel or otherwise!
As far as I know, there's nothing stopping a driver from being loaded for the wrong device in a category, and I'm not sure if it's even limited by category. It's possible from the built-in Device Manager to load entirely the wrong driver for any device (you have to click a lot of buttons that almost nobody has needed in the past decade or two, and you'll get a warning that Windows can't be sure the driver will work, but it won't actually stop you from trying). Given the privileges of user-mode drivers, they could call the same APIs as Device Manager. Alternatively, drivers (at least, in the kernel, and I believe user-mode too) are polled for compatibility with new hardware (this is how plug-and-play works) and a malicious one could just announce itself as working for every device.
aa06259810