Future Directions For The Windows CE Device Driver

Future Directions For The Windows CE Device Driver Architecture Juggs Ravalia Program Manager Windows Devices Core OS Microsoft Corporation

Agenda The Windows CE 6. 0 Beta Driver Architecture Windows CE User Mode Driver Framework Desktop versus Windows CE Drivers Comparison Porting Drivers from ← Windows CE 5. 0 New Kernel Memory Model Porting Aspects PQD/Secure Coping Quick Reference Guide Porting Code Snippet

Drivers Architecture Drivers will be split into kernel mode and user mode Kernel Mode Performance critical Fully trusted with full access to kernel memory User Mode Less critical and lower privilege Still need to be trusted OEM can choose where to load its driver (in kernel or in user mode) Drivers that access k-mode address directly need to be in kernel Except for some block drivers used by FS and NDIS based Networking drivers The overall structure of the drivers remain the same Main changes are in how the drivers access client memory

Kernel Mode Drivers Will be loaded in the kernel space by device. dll/gwes. dll Will have full access to the kernel’s data structures and memory APIs do not change, will use the same APIs as user mode drivers Link to a kernel version of coredll. dll called kcoredll. dll Thin layer for API compatibility Directly links the services together without thunk layer

Device Driver Architecture Stream Interface Device Driver Model Device Manager Stream Interface Monolithic Stream Interface Driver Stream Interface (DDI) NDIS Wrapper MDD NDIS Layered Driver Card&Socket Services Device Driver Service Provider Interface (DDSI) PDD NDIS Miniport NDIS Wrapper Card and Socket Services

Device Driver Architecture Native Device Driver Model Graphics, Windowing, and Events Subsystem (GWES) Device Driver Interface (DDI) Monolithic Native Driver The DDI Interface of Native Drivers is defined by Microsoft for each device class Device Driver Interface (DDI) MDD Layered Native Driver Device Driver Service Provider Interface (DDSI) PDD

User Mode Drivers Also managed by Device Manager Hosted in udevice. exe Mostly the same APIs as Kernel Mode UM Drivers lose Kernel privileges No access to kernel structures or memory Cannot call certain kernel only APIs like Virtual. Copy. Ex Kernel will marshal first level parameters during system calls Must be trusted – signed Examples Expansion buses like USB and SDIO

Why Use UMDF? Nostability “Blue-Screens” Improved User-Mode Drivers are isolated from other drivers Correct Privileges Kernel is isolated from user-mode drivers Increased security Recoverability Driver Isolation Compromised driver does not crash the system Lower privileges restrain a compromised driver Recoverability Increased System can recover after a driver crash – Security no “blue-screens” (Device-Hangs in CE) Improved The driver can be restarted without rebooting Stability

User Mode Driver Loading User Mode Driver Host Process User Application XXX_Init(…) User Mode Driver Activate. Device(Ex) HANDLE Returned User Mode Kernel Mode 1 10 Provided by: Microsoft IHV udevice. exe Create. Process(, , Volume Name) XXX_Init forwarded to UM Driver Host 3 Device Manager 1 8 6 2 5 9 4 7 9 Reflector Service 10 HANDLE Returned Parent Bus Driver Device Context

Registry For User Mode Driver Host process is launched and managed by certain registry settings Example of the registry keys for Group ID 2 [HKEY_LOCAL_MACHINEDriversProc. Group_0002] "Proc. Name” = "udevice. exe“; Dummy for Service. exe now "Proc. Vol. Prefix” = "$services“ "Privilege” = dword: xxxxxx ; Processor Privilege Bit Setting [HKEY_LOCAL_MACHINEDriversBuilt. InSerial] "Sys. Intr” = dword: 13 "Io. Base” = dword: 02 F 8 "Io. Len” = dword: 8 "Flags” = dword: 10 (DEVFLAGS_LOAD_AS_USERPROC - 0 x 10) "Proc. Group” = dword: 2 "Isr. Dll” = “isr 16550. dll" "Isr. Handler“ = "ISRHandler"

Reflector Service Nucleus of UMDF One Reflector Object for each UM Driver Launches and manages UMD Host process Forwards device request to UM Driver housed in the UM Driver Host Maps first level pointers from caller to UM Driver process space Serves UMDs on kernel-privilege actions Hero that makes UMDs act as KMDs from the User Application’s perspective

User Mode Driver Host Framework Supports Multiple UMD Host Processes One UMD Host can supports Multiple UMDs UMD Host can be extended for special need like Services. exe The Privileges of a UMD are determined by the UMD Host Process UMD Host mounts a Volume Service API, used by the Kernel Reflector for communication Parses the Reflectors’ requests and performs the required action

User Mode Driver I/O Data Flow Entry UD_Dev. Device. Io. Control(…) DEVFS_Io. Control(…) hit User Application User Mode Driver Host Process 5 Unpacks FNIOCTL_PARAM Calls Driver’s XXX_IOControl User Mode Driver Device. IOControl( HANDLE, dw. IOCTL, pln. Ptr, dwln. Len, NULL, 0, NULL) 4 1 User Mode Kernel Mode 3 6 8 Reflector Service DM_Dev. Device. IOControl(…) Entry Hit 2 Device Manager Reflector_Control( dw. Context, dw. IOCTR, p. In. Ptr, dw. In. Len, …) Virtual. Alloc. Copy. Ex(Get. Caller. Process(), h. UMHost, p. In. Ptr, dw. In. Len, PAGE_READWRITE) Packages FNIOCTL_PARAM Struct 7 Ce. Fs. Io. Control (user. Proc. Volume, Device. IOControl ( Ce. Duplicate. Handle, IOCTL_USERDRIVER_IOCTL, ptr. Fn. Io. Ctl. Param sizeof(FNIOCTL_PARAM), …);

User Mode Driver Data Flow Summary User Mode Driver Host Process User Application 4 User Mode Driver 1 udevice. exe 6 User Mode Kernel Mode Device Manager Provided by: Microsoft IHV 5 3 2 Reflector Service 1 Parent Bus Driver

Windows XP/CE Driver Architectures Similarities Support Kernel Drivers Offer UMDF to host User Mode Drivers File Handle based APIs to User Apps Differences Device Manager Power Manager Asynchronous versus Synchronous Support Interrupt Model – DPCs versus ISTs

Porting Drivers To CE 6. 0 Drivers will mostly run in the kernel Driver writers must focus on security and stability more then ever before Maximum backwards-compatibility is maintained, but some driver modifications are required Deprecated APIs Asynchronous buffer access will require driver modifications User Interface Handling

Windows CE 5. 0 Memory Model 2 GB Kernel Space Kernel Shared Memory Single 2 GB VM for all Processes Slot 34 Slot 33 Slot 32 Slot 31 : : Slot 6 Slot 5 – Services. exe Slot 4 – GWES. exe Slot 3 – Device. exe Slot 2 – Filesys. exe Slot 1 – ROM DLLs Slot 0 – Execution 32 Slots for Processes Execution Slot and Shared DLL Slot

New CE Memory Model User VM Memory Mapped files 2 GB per Process User DLLs Process Code User VM . . . Kernel Filesystem GWES Drivers . . . 2 GB Kernel Space 32 K Process

Driver Migration Summary Key porting topics: Access checking Marshalling Thread permissions Secure copy User interface User mode drivers Quick reference guide Porting sample code snippet

Access Checking In <=CE 5. 0, Map. Caller. Ptr was used to validate memory pointed to by either Pointer parameters or Embedded pointers With CE 6. 0 Beta, the kernel performs full access check on pointer parameters Thus, drivers only need to access check embedded pointers Use kernel access-check APIs Ce. Open. Caller. Buffer/Ce. Close. Caller. Buffer to verify embedded pointers

Access Check Diagram 2 GB Kernel Space Kernel NK. EXE Driver. dll Kernel Checks this Buffer Embedded Ptr 2 GB per Process Hello. exe Driver Calls Ce. Open. Caller. Buffer to check this Buffer

Access Checks struct My. Struct { UCHAR *p. Embedded; DWORD dw. Size; }; Windows CE 5. 0 and prior versions // In XXX_IOControl. . . g_p. Mapped. Embedded = Map. Caller. Ptr(p->p. Embedded); Map. Caller. Ptr // Fail if g_p. Mapped. Embedded == NULL. . . // Now in the New OS Version // In XXX_IOControl. . . hr = Ce. Open. Caller. Ptr( Ce. Open. Caller. Ptr (PVOID*) &g_p. Mapped. Embedded, p. Input->p. Embedded, p. Input->dw. Size, ARG_I_PTR, FALSE); // Fail if FAILED(hr) == true // When done with pointer. . . hr = Ce. Close. Caller. Ptr((PVOID) g_p. Mapped. Embedded, Ce. Close. Caller. Ptr p. Input->p. Embedded, p. Input->dw. Size, ARG_I_PTR );

Marshalling <= Windows CE 5. 0, the Map. Caller. Ptr API also handled pointer marshalling for both Pointer parameters as well as Embedded pointers With the next Windows CE version, Marshalling depends on whether the pointers are used Synchronously or Asynchronously Important! Synchronous here means accessing the caller’s buffer on the caller’s thread context

Marshalling When pointers are used synchronously The caller’s address space is accessible for the lifetime of the call Eliminates any marshalling needs for both embedded and pointer parameters Employs Direct Access Marshalling If used asynchronously It’s critical that the caller buffer is accessible when the caller’s address space is unavailable Use the new OS marshalling helper APIs Ce. Alloc. Asynchronous. Buffer/ Ce. Free. Asynchronous. Buffer

Synchronous Access Diagram Test. exe App. exe Kernel NK. EXE Hello. exe Driver. dll App. exe Test. exe Hello. exe

Asynchronous Access Diagram Hello. exe App. exe NK. EXE Driver Thread in NK. EXE Drv. dll Ce. Alloc. Asynchronous. Buffer 1111111 000000 App. exe 1111111 000000 Ce. Free. Asynchronous. Buffer Hello. exe

Marshalling // Windows CE 5. 0 and prior versions // In XXX_IOControl. . . g_p. Mapped. Embedded = Map. Caller. Ptr( p->p. Embedded ); // Fail if g_p. Mapped. Embedded == NULL. . . // Now in the New OS Version // In XXX_IOControl after Ce. Open. Caller. Ptr generates // g_p. Mapped. Embedded. . . hr = Ce. Alloc. Asynchronous. Buffer( Ce. Alloc. Asynchronous. Buffer (PVOID*) &g_p. Marshalled, g_p. Mapped. Embedded, p. Input->dw. Size, ARG_I_PTR); // Fail if FAILED(hr) == true // When done with pointer. . . hr = Ce. Free. Asynchronous. Buffer( Ce. Free. Asynchronous. Buffer (PVOID) g_p. Marshalled, g_p. Mapped. Embedded, p. Input->dw. Size, ARG_I_PTR); // Now call Ce. Close. Caller. Buffer as usual. . .

Thread Permissions <= Windows CE 5. 0, PSLs had access to caller buffers as execution took place in the caller’s thread context Other threads like ISTs did not have access to the caller’s buffer Such threads thus called Set. Proc. Permissions API With Windows CE 6. 0 Beta, Set. Proc. Permissions API is now deprecated The Ce. Alloc. Asynchronous. Buffer API marshals the caller’s buffer into the kernel’s VM Thereby eliminating the need to change thread’s permission in any manner

Secure Copy/PQD To Secure Copy Use Ce. Alloc. Duplicate. Buffer / Ce. Free. Duplicate. Buffer APIs Copies caller’s buffer to prevent from asynchronous modifications Points to note Scenario Helper APIs Effect Driver accesses caller’s buffer asynchronously Driver inherently uses Ce. Alloc. Asynchronous. Buffer / Ce. Free. Asynchronous. Buffer for marshalling Driver inherently employs Ce. Open. Caller. Buffer for access checking To Secure-Copy call the API with the Force. Duplicate parameter set to TRUE Could simply map the user’s VM buffer using Virtual. Copy. User buffer is not copied Handling Embedded Pointers By default – does not copy caller’s buffer Set Force. Duplicate =TRUE This local buffer copy is freed upon calling Ce. Close. Caller. Buffer

User Interface <= Windows CE 5. 0 drivers ran in user mode Hence, could display UI without any restrictions With Windows CE 6. 0 Beta, most drivers run in kernel Comm. Ctrl. dll is not loaded in the kernel Kernel drivers need to forward the UI request to a User Mode DLL Code up User Mode DLL and export a function that implements the required UI displaying Pass the DLL and function name to Ce. Call. User. Proc Helper API, with in/out buffers to display desired driver UI Restriction on embedded pointers Need to flatten the structure Handle the embedded pointers as offsets in your User Mode DLL

Porting To User Mode User mode drivers do have a Perf impact The Host/Bus Driver might require changes if the client driver is ported to UM Our goal: Kernel drivers should run in user mode without any modifications Though, some security restrictions apply

Ported User Mode Driver Hello. exe NK. EXE Driver’s Thread in udevice. exe Reflector in Device Manager udevice. exe 1111111 0000000 Drv. dll Hello. exe 0000000111111 0101010 0000000 1111111 Embedded Ptr 0000000111111 0101010 Embedded Ptr 1111111111111 0000000000000 Ce. Open. Caller. Buffer On Embedded Ptr Ce. Close. Caller. Buffer Copies Buffer Data

User Mode Restrictions Embedded Pointers Issue when UM driver is called from kernel Reflector has notion of pointer parameters but not of embedded pointers Flatten the Structure containing the embedded pointer User Mode Driver now has to treat embedded pointers as struct offsets Will investigate to provide Flattening/Unflattening Helper APIs

Embedded Pointer Restriction NK. EXE Hello. exe NK. EXE Embedded Ptr Offset 010101 Reflector 010101 udevice. exe Drv. dll Hello. exe Offset Embedded Ptr 010101 000000

User Mode Driver Restrictions APIs Callable Only in Kernel Mode Heap APIs – Remote. Local. Alloc, Remote. Local. Free VM APIs – Virtual. Copy. Ex, Virtual. Alloc. Copy. Ex File. Sys APIs – Get. FSHeap. Info, Get. Rom. File. Bytes Application Call-backs Call-forwarding and Call-backs from a User Mode server to any process are prohibited Cannot Install IISR directly – Can Install GIISR via Reflector

Driver Migration Summary Drivers move to kernel Isolate to User Mode if suitable Access check embedded pointers Asynchronous access demands marshalling Some drivers are backward compatible Move driver UI to user space Enjoy your porting

Porting Quick Reference Guide Use Case Work Required What the Driver Porting Engineer must do Parameter – used Access checking and synchronously Marshalling Secure-copy Nothing; Kernel checks during trap and uses direct access Use Ce. Alloc. Duplicate. Buffer to make a local copy Parameter – used Access checking and asynchronously Marshalling Employ Ce. Alloc. Asynchronous. Buffer / Employ Ce. Alloc. Asynchronous. Buffer/ Ce. Free. Asynchronous. Buffer – Prepares for async access by creating/mapping caller buffer Use Ce. Alloc. Duplicate. Buffer to make a local copy Secure-copy Embedded pointer – used synchronously Access checking and Marshalling Embedded pointer – used asynchronously Access checking and Marshalling Secure-copy Use Ce. Open. Caller. Buffer/Ce. Close. Caller. Buffer Call Ce. Open. Caller. Buffer with Force. Duplicate parameter Call Ce. Open. Caller. Buffer with set to TRUE or Use Ce. Alloc. Duplicate. Buffer to make a local copy. Secure-copy Call Ce. Alloc. Asynchronous. Buffer after you call Ce. Open. Caller. Buffer. You must call Ce. Free. Asynchronous. Buffer before you call Ce. Close. Caller. Buffer. Call Ce. Open. Caller. Buffer with Force. Duplicate set to TRUE Call Ce. Open. Caller. Buffer with or Call Ce. Alloc. Duplicate. Buffer for a local copy. For All Cases Deprecated APIs Remove Deprecated APIs Go through Deprecated APIs list to remove the Example: Ce. Get. Caller. Trust , Set. KMode and so on Example: Ce. Get. Caller. Trust, For All Cases UI/Dialog boxes UI calls in kernel will always return failure Use Ce. Call. User. Proc Code up user mode dll exporting the function that implements the required UI displaying. Then call Ce. Call. User. Proc API with dll and function name Then call Ce. Call. User. Proc API with as input parameters.

Call To Action Help grow the Mobile and Embedded world Write drivers for Windows CE and sell Chips Join the Windows CE Driver Development Program http: //msdn. microsoft. com/embedded/usewinemb/ce/ drivers/driverdev/default. aspx Port your existing drivers to Windows CE 6. 0 Post your driver on Windows CE’s Supported Drivers web site http: //msdn. microsoft. com/embedded/usewinemb/ce/ drivers/supdrivers/default. aspx

Additional Resources Ce. Drv. Trg @ microsoft. com Web Resources http: //msdn. microsoft. com/embedded/windowsce/default. aspx Related Win. HEC 2006 Sessions Future Directions for the Windows CE Operating System Architecture Future Directions for the Windows CE Test Kit User-Mode Driver Framework: Introduction and Overview

Community Resources Community Sites http: //www. microsoft. com/communities/default. mspx List of Newsgroups http: //communities 2. microsoft. com/communities/newsgroups/ en-us/default. aspx Attend a free chat or webcast http: //www. microsoft. com/communities/chats/default. mspx http: //www. microsoft. com/seminar/events/webcasts/default. mspx

Questions? Q&A Thank you all

© 2006 Microsoft Corporation. All rights reserved. Microsoft, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U. S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.