Drivers and Process Address Spaces (Windows CE 5.0)
Windows CE–based device drivers run in one of the system process address spaces. This architecture affects your device driver development whenever you want to share chained data structures between an application and a device driver.
You should run drivers in user mode and use the VirtualAlloc and VirtualCopy functions instead of kernel mode addresses when mapping hardware registers.
In Windows CE, all processes share a single virtual memory address space with the kernel and various other parts of the OS. Each process resides in its own 32 MB slot, and slots are protected from each other and from the kernel. For more information, see Processes.
Threads migrate between process slots during system calls. For example, if a thread calls ExtEscape, the thread's context is switched into Gwes.exe. Then, if the display driver's ExtEscape implementation calls DeviceIoControl, the same thread migrates into Device Manager. When the thread is executing in the driver's IOCTL code, the application is the owner process, Gwes.exe is the caller process, and Device Manager is the current process. For more information, see GetCurrentProcessId, GetCallerProcess, and GetOwnerProcess.
Windows CE defines the 0x80000000 to 0x9FFFFFFF statically mapped virtual address range as cached and the 0xA0000000 to 0xBFFFFFFF statically mapped virtual address range as uncached. These addresses are only valid in kernel mode. Drivers should not use these addresses, and drivers should not allow applications to pass in kernel mode addresses. For more information, see OEMAddressTable.
Use the IsBadReadPtr, IsBadWritePtr, and IsBadCodePtr functions with caution in driver entry points. These functions tell you only if your thread can access a particular address while executing in the context of Device Manager. Because the IOControl entry point executes in kernel mode, kernel mode addresses are valid, as well as addresses in other processes with threads executing code in Device Manager. For example, if another application was blocked waiting on data in the serial port, and a malicious program passed a virtual address into the application's address space, these functions would not catch the security violation. To prevent this, Device Manager implicitly calls MapCallerPtr.
Even if you do not load a driver in kernel mode, and the driver does not directly use kernel mode addresses, the OS executes the driver's entry points in kernel mode because they are an implementation of system calls.
See Also
Accessing Memory from a Driver | GetCurrentProcessId | GetOwnerProcess | Memory Architecture
Send Feedback on this topic to the authors