1 / 20

Driver Verifier Advancements In Windows 7 - PowerPoint PPT Presentation

  • Updated On :

Driver Verifier Advancements In Windows 7. Daniel Mihai Principal Software Design Engineer Windows Engineering Tools. Preliminary Information. All the information included in this presentation is preliminary for Windows 7 Beta versions, and is subject to change. Driver Verifier Options.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Driver Verifier Advancements In Windows 7' - tamah

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Driver verifier advancements in windows 7 l.jpg
Driver Verifier Advancements In Windows 7

Daniel Mihai

Principal Software Design Engineer

Windows Engineering Tools

Preliminary information l.jpg
Preliminary Information

  • All the information included in this presentation is preliminary for Windows 7 Beta versions, and is subject to change

Driver verifier options l.jpg
Driver Verifier Options

  • Special Pool

  • Pool Tracking

  • Force IRQL Checking

  • I/O Verification

  • Enhanced I/O Verification

  • Deadlock Detection

  • DMA Checking

  • Security Checks

  • Miscellaneous Checks

  • Force Pending I/O Requests

  • Low Resources Simulation

Agenda l.jpg

  • Windows 7 Advancements:

    • User handles referenced as KernelMode

    • I/O Verification improvements

    • Additional Special Pool and Pool Tracking support

    • Detect miscellaneous other bugs

    • Force Pending I/O Requests improvements

    • Easier to debug

    • X64 enhancements

    • Performance improvements

User handles vs kernel handles l.jpg
User Handles Vs. Kernel Handles

  • Each process has its own handle table

  • Handle value – conceptually an index in an array of handles

  • Handle table entry – contains the address of the object and the granted access rights

  • Kernel handle – handle inside the System process (PID 4), either:

    • Created from a system worker thread

    • Created from another process by using the OBJ_KERNEL_HANDLE flag

  • User handle – handle in some other process

  • See “Object Handles” in MSDN (

Referencing user handles l.jpg
Referencing User Handles

  • Creating or referencing handles incorrectly can result in reliability and security problems

  • User handles are usually created by the application – CreateEvent, CreateThread, etc.

  • An application can close, re-open, reference user handles (but not kernel handles)—even if the user handle was created by a kernel driver!

  • If a kernel driver has to reference a user handle, it should always reference it as UserMode and with the appropriate value for the DesiredAccess parameter

Referencing user handles as kernelmode is incorrect l.jpg
Referencing User Handles as KernelMode Is Incorrect

  • Examples of API calls:

    • ObReferenceObjectByHandle (KernelMode)

    • All Zw APIs, such as ZwWriteFile or ZwSetEvent

  • KernelMode references ignore the DesiredAccess, so ZwWriteFile for a read-only file handle will succeed!

  • The application can close the user handle and open the same handle value but for a different object

  • The application could ask the driver to reference a kernel handle— that will succeed if driver uses KernelMode reference!

  • Driver Verifier Security Checks detect some of these incorrect references

Guidelines for referencing handles from kernel drivers l.jpg
Guidelines For Referencing Handles From Kernel Drivers

  • If an application provided the handle value, always reference it as UserMode

  • If a driver creates the handle and shares its value with an application:

    • Create a user handle

    • If needed to reference that handle, reference it as UserMode

  • If a driver creates the handle and doesn’t share it with an application:

    • Create a kernel handle

    • If needed to reference that handle, reference it as KernelMode

  • Use pointer to object instead of handle to object when possible

I o verification improvements l.jpg
I/O Verification Improvements

  • Now includes the old Enhanced I/O Verification checks too

    • Detects ~50 classes of driver bugs

    • Part of the Standard Settings (verifier.exe /standard)

    • Enhanced I/O Verification doesn’t exist anymore

  • Detect attempts to reinitialize Remove Locks

    • Should be allocated inside device object extension and deleted when the device object gets deleted

    • Reinitializing while the device object still exists might mean that another thread is still using the lock

Additional special pool and pool tracking support l.jpg
Additional Special Pool and Pool Tracking Support

  • Memory allocated internally by OS kernel APIs

    • Examples: IoAllocateMdl, RtlAnsiStringToUnicodeString and other String APIs, IoAllocateIrp and similar APIs, IoSetCompletionRoutineEx

  • Added detection of buffer overruns, use-after-free, and leaks of these allocations

  • Successful IoSetCompletionRoutineEx call that is not followed by IoCallDriver results in a memory leak

Detect miscellaneous other bugs 1 3 l.jpg
Detect Miscellaneous Other Bugs (1/3)

  • UserMode Wait for synchronization object allocated on the kernel stack

    • Process is eligible to be swapped out

    • Kernel stack is swapped out, too

    • A thread trying to signal the synchronization object will crash

  • Synchronization objects allocated in session nonpaged pool memory

    • The kernel can reference these objects from other sessions

  • Using KeEnterCriticalRegion or KeLeaveCriticalRegion at DISPATCH_LEVEL or above

Detect miscellaneous other bugs 2 3 l.jpg
Detect Miscellaneous Other Bugs (2/3)

  • ObReferenceObjectByPointer from reference count 0 to 1

    • When reference count becomes 0, the object can be freed, therefore referencing back to 1 is incorrect

  • Break when drivers are trying to reference an incorrect kernel handle—already closed or completely bogus

  • Added checks for InStackQueuedSpinlocks

    • Similar verification to the “regular” spinlocks

      • Sanity checks for the IRQL value

      • Deadlock detection/prediction

Detect miscellaneous other bugs 3 3 l.jpg
Detect Miscellaneous Other Bugs (3/3)

  • Detect ExAllocatePoolWithQuota calls from DPC routines

    • The process context can vary for DPCs so the driver is charging quota to random processes

    • DPCs often run in the context of the Idle process. Trying to charge quota to the Idle process results in system crashes or memory corruption

  • Breakpoint when system shutdown didn’t finish in a long time

    • 20 minutes after shutdown started

    • !analyze displays the status of the thread responsible for shutdown

Force pending i o requests improvements l.jpg
Force Pending I/O Requests Improvements

  • More IRPs are eligible to be forced pending -> better test code coverage

  • Ability to force pending and delay completion at any level of the device stack

    • Behavior of driver1 will not limit the ability to test thoroughly driver2 on the same device stack

  • More detailed Force Pending log—!verifier 40

    • Stack trace when the verified driver called IoCallDriver

    • Stack trace when IoCompleteRequest was called for the forced pending IRP

Easier to debug l.jpg
Easier to Debug

  • Log with stack traces for KeEnterCriticalRegion and KeLeaveCriticalRegion calls from verified drivers

    • Helps understand who forgot to leave a critical region, or who is trying to leave critical region more times than it entered

    • Displayed by !verifier 200

  • !analyze works to automatically triage Enhanced I/O Verifier breaks

  • More IRQL transition stack traces available—!verifier 8

X64 improvements l.jpg
X64 Improvements

  • If IRQL Checking is disabled, Verifier can collect stack traces at DISPATCH_LEVEL

  • Improved IRQL Checking

    • Trimming working set more often

    • Catching more cases of referencing pageable memory at elevated IRQL

Call to action l.jpg
Call To Action

  • If you are not testing your drivers with Driver Verifier enabled, please start as soon as possible. Many driver defects will be easier to expose, to debug and fix.

  • Test your drivers with Driver Verifier enabled on Windows 7. Driver Verifier is more effective than ever in Windows 7.

  • Fix any issues exposed by Verifier in your drivers!

  • Check Online Crash Analysis (OCA) for possible customer reports of crashes in your driver.

    • String “_VRFOCA_” included in the OCA bucket name means that Driver Verifier was enabled on that system – usually easier to debug.

  • Send any feedback about Driver Verifier to [email protected]

Resources l.jpg

  • WHDC Web Site:

    • Driver Verifier on the WHDC Web Site:

    • WinHEC 2007 Presentation—Driver Verifier: Advances And Best Practices

  • Send feedback to [email protected]

  • Experiment with new Windows 7 Driver Verifier features at DDC 2008 Lab: Debugging Bugs Exposed by Driver Verifier

  • Discuss in depth Driver Verifier at DDC 2008 Chalk-talk: Driver Verifier Internals