Driver Verifier Advancements In Windows 7

Daniel MihaiPrincipal Software Design EngineerWindows 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

• 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

• 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

• 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 (

http://msdn.microsoft.com/en-us/library/aa489524.aspx)

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

• 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

• 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

• 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

• 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)

• 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)

• 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)

• 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

• 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

• 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

• 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

• 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 verifier@microsoft.com

Resources

• WHDC Web Site:• Driver Verifier on the WHDC Web Site:

http://www.microsoft.com/whdc/DevTools/tools/DrvVerifier.mspx

• WinHEC 2007 Presentation—Driver Verifier: Advances And Best Practices http://download.microsoft.com/download/a/f/d/afdfd50d-6eb9-425e-84e1-b4085a80e34e/DVR-T407_WH07.pptx

• Send feedback to verifier@microsoft.com• 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

Related Sessions

Session Day / Time

Debugging Bugs Exposed by Driver Verifier (Lab) Weds. 8:30-9:30

Driver Verifier Advancements in Windows 7 Mon. 5:15-6:15 andWed. 1:30-2:30

Driver Verifier Internals (Chalk talk) Tues. 8:30-9:30