CE6: User and Kernel Mode Drivers

There have been quite an umpteen number of changes to the architecture of CE in version 6.0. One of the changes, not one having stole the limelight, is a new model for loading device drivers said to provide for increased security, robustness or performance.

Prior to CE6, device drivers primarily resided in the device.exe process. Device.exe was a process like any other application, subject to the same memory limitations and performance issues resulting from interprocess calls back and forth between the application, driver, filesystem and kernel.

In addition, since all drivers were located in the same process space a corrupt driver could potentially fault the entire process, shutting down all drivers.

The new kernel architecture provides more flexibility by providing two different driver models. The old device.exe functionality has been moved into the kernel, and a new user device process (udevice.exe) has been introduced. This change results in two different driver models, kernel mode drivers and user mode drivers

Kernel Mode drivers

Kernel mode drivers are loaded by device.dll inside of the kernel. The big win here is performance – the expensive interprocess calls have been eliminated and there is no need for the user mode process initiating a driver access to be switched out, because the user mode process coexists with the kernel. The kernel includes the file system and device drivers so everything is resident in memory at the same time.

However, this performance benefit comes at a price. Kernel mode drivers are now a part of the kernel, and they have full privileges for the entire kernel address space. A driver failure that results in memory corruption could easily bring down the kernel and with it the entire system. Therefore it’s critical that kernel mode drivers be robust.

This looks very much CE5 behaviour... lets just stop and see the user mode drivers before going forward.

User Mode Drivers

CE6 provides a new mechanism to load drivers into user mode processes (called udevice.exe) instead of into the kernel.

A driver that loads in this fashion is called a user mode driver, which gives up a level of performance in return for increased system robustness and security.

In addition, user mode drivers are restricted in their use of certain APIs such as VirtualCopy, which restricts them from arbitrarily accessing any hardware resource in the system.

Microsoft has designed the user mode driver model to have a very high level of compatibility with kernel mode drivers so musch so that a driver written for user mode can be loaded into kernel mode with no changes.

A new kernel component called the user mode driver reflector handles the interface between user mode applications and the user mode driver.It’s a simple matter to load a driver into user mode, through new bit defined in the Flags registry key which when set tells kernel to load the corresponding driver into user mode. That’s it!

The user mode driver will run in its own process isolated from the kernel and the rest of the system. If the driver fails for some reason only its copy of udevice.exe is affected, the rest of the system should remain intact.

Coming back, Yes, a flaw in a kernel driver can bring down the entire kernel!While this failure mode sounds bad (and is) the end result isn’t really any different from the old model. The analog in CE5 is to bring down the device.exe process and with it all the remaining device drivers.

This failure is likely to have the same overall effect on most platforms!!

However BSP developers now have the option of choosing between a high performance kernel mode driver and a more protected user mode driver. Untrusted third party drivers can be loaded into user mode to increase system security and robustness. Unstable or otherwise questionable drivers can start life in user mode and then be moved to kernel mode as they become proven...