Best Practices Steve Maillet Chief Software Architect EmbeddedFusion ECE401 Best Practices For Driver Development

Overview Why Does Any of this Matter? System Architecture Accessing Hardware Handling Interrupts Exchanging Data with Applications Security Portability User Mode Drivers Differences between Windows CE 5.0 and Windows Embedded CE 6.0 …besides the name change Page 3

Why Does Any of this Matter? Security and system stability Data integrity and system security are significant issues Maximize re-usability of a driver Decrease development time for next use Increase sales opportunities Page 4

System Architecture (Windows CE 5.0) Page 5

System Architecture (CE 6.0) Page 6

Accessing Hardware Mapping memory and I/O windows BusTransBusAddressToVirtual Converts a bus-relative address to a virtual address accessible by the calling process BusTransBusAddressToStatic Converts a bus-relative address to a virtual address Page 7

Accessing Hardware Read memory and I/O Windows from registry Use DDKReg_GetWindowInfo Account for memory or I/O window stride 8-bit devices are often mapped to 32-bit buses by offsetting each register in the address space If your driver hard-codes assuming an 8-bit bus, then it’s useless in a system with a 16- or 32-bit bus Separate pointer for each register, don’t use a “C” struct Page 8

Handling Interrupts Read Interrupt info from registry Use DDKReg_GetIsrInfo() Use I/O Resource Manager Use ResourceRquestEx/ResourceRelease Request access to the IRQ Request/Release SYSINTR if not provided by bus driver IOCTL_HAL_REQUEST_SYSINTR/IOCTL_HAL_RELEASE_SY SINTR Load IISR if provided Don’t assume only IISR is GIISR! GIISR is generic for PCI buses but not always suitable for many SoC systems Page 9

Exchanging Data with Applications Performing security checks Pointer mapping Embedded pointers Thread permissions/marshalling Page 10

Performing Security Checks Pointer mapping Access checking Thread permissions Caller trust Page 11

Pointer Mapping Application provides pointers to data to the driver Driver runs in separate context from applications Kernel in Windows CE 6.0 Device.exe/Gwes.exe in CE 5.0 Kernel automatically maps application pointers passed directly as parameters into space available to the driver Driver must handle pointers embedded in data passed to the driver Page 12

Access Checking Malicious apps can pass a buffer to the driver that contains an embedded pointer to kernel space and ask driver to access it—thereby modifying the kernel! Proper access checking in driver will prevent this dangerous scenario. Page 13

Embedded Pointers Kernel performs basic access checks and mapping on all pointer parameters to driver entry points. Embedded pointers require special care as the OS cannot perform any checks as it has no way to know what to check. Page 14

Example Embedded Pointer Application writes text to specified location of simple text-based display Pointer to TextData passed to driver OS checks access to the buffer (TextData) Driver MUST check access to embedded pText member using Length member as the size struct TextData { int row; int Col; const TCHAR* pText; size_t Len;} Page 15

Access Checks and Pointer Mapping CE 5.0 MapCallerPointer Performs address space mapping and access rights checking CE 6.0 CeOpenCallerBuffer / CeCloseCallerBuffer Portability tip In CE 5.0, create lib with CeOpenCallerBuffer that calls MapCallerPointer() Or hide pointer mapping in a custom portability lib Page 16

Data Buffers and Threads Secondary worker threads need special access to buffers CE 5.0: use Get/SetProcPermissions GetPermissions in the calling thread and SetProcPermissions on the secondary thread CE 6.0: use CeAllocAsynchronousBuffer/CeFreeAsynchronousBuffer Page 17

Security Caller Buffer data integrity Driver’s don’t know if caller is buggy or malicious Protection is the same for both Page 18

Invalid Pointers Can cause serious crashes Exceptions can cause hard to track memory leaks if not handled correctly Invalid data lengths are related to invalid pointers e.g., Caller says buffer is 1 MB but it’s really only 1 K Page 19

Exception Handling __try/__except Surround all buffer accesses with exception handling Protects against invalid pointers and lengths Allows clean up of resources in __except Page 20

Malicious Callers Never implicitly trust the caller! Caller can modify the buffer while driver is still using it! Secondary application thread that manipulates the buffer while another thread is in a driver call Cause crashes Get access to memory it shouldn’t by manipulating embedded pointers Just because you can access a buffer doesn’t mean it is always safe to do so. Page 21

Embedded Pointers Revisited! Avoid them if you can! Avoid embedded pointers Use offsets and Lengths or variable length structures Security issues Works in User Mode drivers Page 22

Embedded Pointers Revisited Always copy embedded pointers to a local variable Easily accomplished as part of mapping and access checks Never store the mapped/checked pointer back to the buffer Never use the pointer in the buffer directly after it’s mapped and checked Always use Driver’s local checked and mapped copy so you know the pointer is valid. Page 23

Embedded Lengths Revisited Same basic issues as pointers Always copy the length from the buffer before performing access checks and mapping Never use the length directly in the buffer after copying it Caller can still alter the data and cause problems from overruns if length is altered “on the fly” Page 24

Portability Data access and mapping Biggest difference for drivers in CE 6.0 is in how drivers access embedded pointers Simple library can hide the differences between the 2 operating systems Page 25

User Mode Drivers In CE 5.0 drivers were always “user mode” Major difference from “kernel mode” is permissions to access memory above 0x7FFFFFFF In CE 6.0 drivers are in Kernel mode by default Kernel mode drivers run in the kernel address space. For security and stability reasons CE 6.0 adds user mode drivers Goal is 100% compatibility between kernel mode driver and user mode driver Switch from one to the other at build time Embedded pointers prevent 100% compatibility Page 26

User Mode Driver Model Page 27

Installable ISRs for User Mode Drivers Installable ISRs are loaded into kernel address space Security risk for User Mode Dlls Only GIISRDLL is allowed as that is a known item that doesn’t pose a risk If your system needs an IISR and can’t use GIISR then the driver must run kernel mode Page 28

Summary Drivers can leverage common patterns to simplify development and make drivers more robust Driver developers must consider security implications of every call into the driver With a little care and discipline drivers can operate on multiple platforms and bus configurations Page 29

While You're Here Fill out your session evaluation Enter to win a Windows Mobile ® phone or Zune™ The Battle Begins Stay tuned for the Sumo Robotics competition at the Tao attendee party Meet the geeks The Expert Cabana is packed with MEDC speakers and MVPs

© 2007 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.