Future Directions For The Windows CE Device Driver Architecture

1. Future Directions For The Windows CE Device Driver Architecture Juggs RavaliaProgram ManagerWindows Devices Core OSMicrosoft Corporation

2. 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

3. 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

4. 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

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

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

7. 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 VirtualCopyEx • Kernel will marshal first level parameters during system calls • Must be trusted – signed • Examples • Expansion buses like USB and SDIO

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

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

10. Registry For User Mode Driver • User Mode Driver Host process is launched and managed by certain registry settings • Example of the registry keys for Group ID 2 • [HKEY_LOCAL_MACHINE\Drivers\ProcGroup_0002] • "ProcName” = "udevice.exe“; Dummy for Service.exe now • "ProcVolPrefix” = "$services“ • "Privilege” = dword:xxxxxx ; Processor Privilege Bit Setting • [HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial] • "SysIntr” = dword:13 • "IoBase” = dword:02F8 • "IoLen” = dword:8 • "Flags” = dword:10 (DEVFLAGS_LOAD_AS_USERPROC - 0x10) • "ProcGroup” = dword:2 • "IsrDll” = “isr16550.dll" • "IsrHandler“ = "ISRHandler"

11. 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

12. 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

13. User Mode Driver I/O Data Flow User Mode Driver Host Process Entry DEVFS_IoControl(…) hit Entry UD_DevDeviceIoControl(…) hit User Application 5 DeviceIOControl( HANDLE, dwIOCTL, plnPtr, dwlnLen, NULL, 0, NULL, NULL) Unpacks FNIOCTL_PARAM Calls Driver’s XXX_IOControl User Mode Driver 4 1 6 User Mode 3 Kernel Mode 8 Reflector Service Device Manager DM_DevDeviceIOControl(…) Entry Hit VirtualAllocCopyEx(GetCallerProcess(), hUMHost,pInPtr,dwInLen,PAGE_READWRITE) 2 Packages FNIOCTL_PARAM Struct CeFsIoControl(userProcVolume, IOCTL_USERDRIVER_IOCTL,ptrFnIoCtlParam sizeof(FNIOCTL_PARAM), …); DeviceIOControl( CeDuplicateHandle, IOCTL_USERDRIVER_IOCTL,ptrFnIoCtlParam sizeof(FNIOCTL_PARAM), …); Reflector_Control( dwContext, dwIOCTR, pInPtr, dwInLen, …) 7

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

15. 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

16. 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

17. Windows CE 5.0 Memory Model Kernel 2 GBKernelSpace SharedMemory Single2 GB VMfor allProcesses Slot 34 Slot 33 Slot 32 32 Slots for Processes Slot 31 :: Slot 6 Slot 5 – Services.exe Slot 4 – GWES.exe Slot 3 – Device.exe Execution Slot and Shared DLL Slot Slot 2 – Filesys.exe Slot 1 – ROM DLLs Slot 0 – Execution

18. User VMMemory Mapped files User DLLs Process Code User VM New CE Memory Model KernelFilesystemGWESDrivers 2 GBKernelSpace 2 GBperProcess . . . . . . . . 32 KProcess

19. 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

20. Access Checking • In <=CE 5.0, MapCallerPtr 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 - CeOpenCallerBuffer/CeCloseCallerBuffer to verify embedded pointers

21. Access Check Diagram Kernel NK.EXE 2 GBKernelSpace Driver.dll Kernel Checks this Buffer Hello.exe Embedded Ptr 2 GBperProcess Driver Calls CeOpenCallerBuffer to check this Buffer

22. Access Checks struct MyStruct { UCHAR *pEmbedded; DWORD dwSize; }; Windows CE 5.0 and prior versions // In XXX_IOControl... g_pMappedEmbedded = MapCallerPtr(p->pEmbedded); // Fail if g_pMappedEmbedded == NULL ... // Now in the New OS Version // In XXX_IOControl... hr = CeOpenCallerPtr( (PVOID*) &g_pMappedEmbedded, pInput->pEmbedded, pInput->dwSize, ARG_I_PTR, FALSE); // Fail if FAILED(hr) == true // When done with pointer... hr = CeCloseCallerPtr((PVOID) g_pMappedEmbedded, pInput->pEmbedded, pInput->dwSize, ARG_I_PTR );

23. Marshalling • <= Windows CE 5.0, the MapCallerPtr 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

24. 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 CeAllocAsynchronousBuffer/ CeFreeAsynchronousBuffer

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

26. Asynchronous Access Diagram Hello.exe NK.EXE Driver Thread in NK.EXE App.exe Drv.dll CeAllocAsynchronousBuffer CeFreeAsynchronousBuffer 1111111111111 000000000000 App.exe App.exe Hello.exe Hello.exe 000000000000 1111111111111

27. Marshalling // Windows CE 5.0 and prior versions // In XXX_IOControl... g_pMappedEmbedded = MapCallerPtr( p->pEmbedded ); // Fail if g_pMappedEmbedded == NULL ... // Now in the New OS Version // In XXX_IOControl after CeOpenCallerPtr generates // g_pMappedEmbedded... hr = CeAllocAsynchronousBuffer( (PVOID*) &g_pMarshalled, g_pMappedEmbedded, pInput->dwSize, ARG_I_PTR); // Fail if FAILED(hr) == true // When done with pointer... hr = CeFreeAsynchronousBuffer( (PVOID) g_pMarshalled, g_pMappedEmbedded, pInput->dwSize, ARG_I_PTR); // Now call CeCloseCallerBuffer as usual...

28. 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 SetProcPermissions API • With Windows CE 6.0 Beta, • SetProcPermissions API is now deprecated • The CeAllocAsynchronousBuffer API marshals the caller’s buffer into the kernel’s VM • Thereby eliminating the need to change the thread’s permission in any manner

29. Secure Copy/PQD • To Secure Copy • UseCeAllocDuplicateBuffer / CeFreeDuplicateBuffer APIs • Copies caller’s buffer to prevent from asynchronous modifications • Points to note

30. 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 • CommCtrl.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 CeCallUserProc 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

31. 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

32. Ported User Mode Driver NK.EXE Driver’s Thread in udevice.exe Hello.exe Reflector in Device Manager Hello.exe Hello.exe udevice.exe udevice.exe Drv.dll 1111111111111 0000000000000 0000000111111 Embedded Ptr 0101010101010 Embedded Ptr 0000000000000 CeOpenCallerBuffer On Embedded Ptr 1111111111111 CeCloseCallerBuffer 0101010101010 Embedded Ptr 0000000111111 Embedded Ptr Copies Buffer Data 1111111111111 0000000000000 1111111111111 000000000000

33. 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

34. Embedded Pointer Restriction NK.EXE NK.EXE Hello.exe Embedded Ptr Offset 010101010101 Reflector 010101010101 Hello.exe Hello.exe udevice.exe udevice.exe Drv.dll Offset Embedded Ptr 010101010101 000000000000

35. User Mode Driver Restrictions • APIs Callable Only in Kernel Mode • Heap APIs – RemoteLocalAlloc, RemoteLocalFree • VM APIs – VirtualCopyEx, VirtualAllocCopyEx • FileSys APIs – GetFSHeapInfo, GetRomFileBytes • 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

36. 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 

37. Porting Quick Reference Guide

38. 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

39. Additional Resources • Web Resources http://msdn.microsoft.com/embedded/windowsce/default.aspx • Related WinHEC 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 CeDrvTrg @ microsoft.com

40. Community Resources • Community Sites http://www.microsoft.com/communities/default.mspx • List of Newsgroups http://communities2.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

41. Questions? • Q & A • Thank you all

42. © 2006 Microsoft Corporation. All rights reserved. Microsoft, Windows, 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.