best practices steve maillet chief software architect embeddedfusion ece401 best practices for...

Best PracticesSteve MailletChief Software ArchitectEmbeddedFusion

ECE401Best Practices For Driver Development

Overview

Why Does Any of this Matter?System ArchitectureAccessing HardwareHandling InterruptsExchanging Data with ApplicationsSecurityPortabilityUser Mode Drivers

Differences between Windows CE 5.0 and Windows Embedded CE 6.0

…besides the name change

Why Does Any of this Matter?

Security and system stabilityData integrity and system security are significant issues

Maximize re-usability of a driverDecrease development time for next useIncrease sales opportunities

System Architecture (Windows CE 5.0)

Application(s)

COREDLL

NK.EXE

OAL

GWES.EXE FILESYS.EXE

Object Store

Touch Display Keyboard ROM FSStorage Manager

DEVICE.EXE

SERVICES.EXE

FTP HTTPD TELNETD

RAM ROM/

FLASH

Timer INTC

CPU

HARDWARE

SerialUSB

(Function)PCCard ...

DevMgr.Dll

Block Device

Serial Custom

System Architecture (CE 6.0)

OAL.EXE

Application(s)

GWES.DLL FileSys.Dll

Object Store

ROM FSStorage Manager

Device.Dll

HARDWARE

COREDLL

NK.DLL

RAM ROM/

FLASH

Timer INTC

CPU

KITL.DLL

Touch Display KeyboardBlock

DeviceSerial Custom

Accessing Hardware

Mapping memory and I/O windows

BusTransBusAddressToVirtualConverts a bus-relative address to a virtual address accessible by the calling process

BusTransBusAddressToStaticConverts a bus-relative address to a virtual address

Accessing Hardware

Read memory and I/O Windows from registryUse DDKReg_GetWindowInfo

Account for memory or I/O window stride8-bit devices are often mapped to 32-bit buses by offsetting each register in the address spaceIf your driver hard-codes assuming an 8-bit bus, then it’s useless in a system with a 16- or 32-bit busSeparate pointer for each register, don’t use a “C” struct

Handling Interrupts

Read Interrupt info from registryUse DDKReg_GetIsrInfo()

Use I/O Resource ManagerUse ResourceRquestEx/ResourceReleaseRequest access to the IRQ

Request/Release SYSINTR if not provided by bus driverIOCTL_HAL_REQUEST_SYSINTR/IOCTL_HAL_RELEASE_SYSINTR

Load IISR if providedDon’t assume only IISR is GIISR!GIISR is generic for PCI buses but not always suitable for many SoC systems

Exchanging Data with ApplicationsPerforming security checks

Pointer mapping

Embedded pointers

Thread permissions/marshalling

Performing Security Checks

Pointer mapping

Access checking

Thread permissions

Caller trust

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

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.

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.

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;}

Access Checks and Pointer MappingCE 5.0

MapCallerPointerPerforms address space mapping and access rights checking

CE 6.0CeOpenCallerBuffer / CeCloseCallerBuffer

Portability tipIn CE 5.0, create lib with CeOpenCallerBuffer that calls MapCallerPointer()Or hide pointer mapping in a custom portability lib

Data Buffers and Threads

Secondary worker threads need special access to buffers

CE 5.0: use Get/SetProcPermissionsGetPermissions in the calling thread and SetProcPermissions on the secondary thread

CE 6.0: use CeAllocAsynchronousBuffer/CeFreeAsynchronousBuffer

Security

Caller Buffer data integrity

Driver’s don’t know if caller is buggy or malicious

Protection is the same for both

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

Exception Handling

__try/__except

Surround all buffer accesses with exception handling

Protects against invalid pointers and lengths

Allows clean up of resources in __except

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

Embedded Pointers Revisited!

Row

Col

S1Len

S1Offset

S2Len

S2Offset

S1

S2

InBufSize

pInBuf

Avoid them if you can!

Avoid embedded pointers

Use offsets and Lengths or variable length structures

Security issues

Works in User Mode drivers

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.

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”

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

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

User Mode Driver Model

Cor

eDll.

dll

CE

DD

K.d

ll

Driver.DLLDevmgr.dll

UDEVICE.EXER

edire

ctor

OAL.EXE

Installable ISRs for User Mode DriversInstallable 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

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

While You're Here

Fill out your session evaluationEnter to win a Windows Mobile® phone or Zune™

The Battle BeginsStay tuned for the Sumo Robotics competition

at the Tao attendee party

Meet the geeksThe 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.

best practices steve maillet chief software architect embeddedfusion ece401 best practices for...

Documents