User Mode and Kernel Mode Drivers
My name is Dean Ramsier, and I’m a developer in the Professional
Engineering Services group here at BSQUARE. I came to BSQUARE from
Vibren Technologies and Accelent Systems where I primarily developed
Board Support Packages for Windows CE. I’m currently working
with the Windows CE6 beta.
The development team at Microsoft has made a number of changes to
the architecture of Windows CE in version 6.0. The support for a virtually
unlimited address space and number of processes has gotten much of
the attention, but there are a number of other changes that are significant
as well. One of these is a new model for loading device drivers that
can 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. BSP developers must choose
how each of their drivers will be implemented on a particular platform.
Kernel Mode Drivers
Kernel mode drivers are loaded by device.dll inside of the kernel.
This is the default behavior, and most closely resembles the old device.exe
model. The big win here is performance – the expensive interprocess
calls (thunks) have been eliminated. 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.
This new 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.
A flaw in a driver can bring down the entire kernel? Isn’t this
going backwards? While this failure mode sounds bad (and it 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. That failure is likely to have the
same overall effect on most platforms. However there is another option
in CE6.
User Mode Drivers
CE6 provides a new mechanism to load drivers into individual user
mode processes (called udevice.exe) instead of into the kernel. A
driver that loads in this fashion is called a user mode driver, and
it gives up a level of performance in return for increased system
robustness and security. In addition, since user mode drivers run
inside a user mode process they are restricted in their use of certain
APIs such as VirtualCopy (look for a future blog entry for more details
on these new API restrictions). This security feature restricts drivers
loading in user mode 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. There are very few
differences between the two models, and 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. This means
that applications do not need to be aware of how a particular driver
was loaded.
It’s a simple matter to load a driver into user mode instead
of the default kernel mode. There is a new bit defined in the Flags
registry key that if set tells the kernel to load the corresponding
driver into user mode. That’s it – nothing more to 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.
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. It will be interesting to see how this new driver model
will be used by the CE community.
. . . . . . . . . . . . . . . . . . . . . . .
Dean Ramsier
Senior Software Engineer
Professional Engineering Services
BSQUARE Corporation | Contact Me!
