Driver Verifier Advancements In Windows 7

2. Driver Verifier Advancements In Windows 7 Daniel Mihai Principal Software Design Engineer Windows Engineering Tools

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

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

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

6. 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)

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

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

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

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

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

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

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

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

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

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

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

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

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

20. Related Sessions