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)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.comverifier@microsoft.com

19. Resources WHDC Web Site: Driver Verifier on the WHDC Web Site: http://www.microsoft.com/whdc/DevTools/tools/DrvVerifier.mspx 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 http://download.microsoft.com/download/a/f/d/afdfd50d-6eb9-425e- 84e1-b4085a80e34e/DVR-T407_WH07.pptx Send feedback to verifier@microsoft.comverifier@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 SessionDay / Time Debugging Bugs Exposed by Driver Verifier (Lab)Weds. 8:30-9:30 Driver Verifier Advancements in Windows 7Mon. 5:15-6:15 and Wed. 1:30-2:30 Driver Verifier Internals (Chalk talk)Tues. 8:30-9:30