Static Analysis And Verification Of Drivers Donn Terry Software Development Engr. Microsoft Corporation Vlad Levin Software Development Engr. Microsoft Corporation

Session Outline Static analysis tools What they are The benefits of using them PREfast for Drivers (PFD) Static Driver Verifier (SDV) Summary Getting started/lab

What Is Static Analysis? Compile-time analysis of the source program Like code inspection, but performed by a tool Compile-time type-checking is a predecessor Looks for violations of well-defined constraints Procedure contracts or API contracts Examples of bugs to be found by Static Analysis: p = NULL; … f(p); f() requires p to be non-NULL Completing the same Irp twice: IoCompleteRequest (Irp); IoCompleteRequest (Irp); IoCompleteRequest (Irp); IoCompleteRequest (Irp);

Why Static Analysis? Rule of thumb A defect that costs $1 to fix on the programmer’s desktop costs $100 to fix once it is incorporated into a complete program and many thousands of dollars if it is identified only after the software has been deployed in the field Building a Better Bug Trap – The Economist June 2003

Static Analysis Tools For Drivers Two technologies provided PFD: Look inside every procedure for possible violations SDV: Look along paths, cross inter-procedural boundaries Each is better in some situations ReadFoo ( PIRP Irp ) { PIRP p = NULL;... if (status) { Irp = p; } ReadFoo ( PIRP Irp ) {... status = Bar (Irp); if (status) { IoCompleteRequest(Irp); } Bar ( PIRP Irp ) {... IoCompleteRequest(Irp); return STATUS_SUCCESS; }XX XX

Static Analysis Tools For Drivers PREfast for Drivers (PFD) Looks at one procedure at a time For several hundred constraints Best for quick checks and early development Static Driver Verifier (SDV) A “compile-time version” of Driver Verifier. Looks along every path, crossing inter-procedural boundaries For a few hundred WDM constraints More under development Best for deep analysis of full driver

We Can Make It Better Use static analysis tools for drivers Push-button technology 100% path coverage At no cost (let a computer do it) At little time (hours versus weeks) Defects are discovered early Even before device hardware is available Before designing test cases Often while still coding Defect reports are easy to use A direct reference to the defective path (or point) in the source code reduces cost of debugging

How You Debug And Test Today XX I/O Mgr DLL Driver ?? ?? ?? ?? The driver causes a crash – How? Under what scenario? On which path? It takes time to find out … Is this DLL involved?

XX I/O Mgr DLL Driver IoCompleteRequest(…) DriverIoCtl ( Irp ) ?? Now, you know the type of the bug – Yet, the path is cloudy Debug, debug, debug … ?? Driver Verifier And A Lucky Test ClassIoCtl ( Irp ) ?? ?? IoCompleteRequest(…)

Static Analysis Does Two Things Finds a defect Reveals the path Without testing Without debugging DriverIoCtl ( Irp ) ClassIoCtl ( Irp ) if (status != …) { IoCompleteRequest( Irp ); } IoCompleteRequest( Irp ); } switch ( … ) { DLL Driver I/O MgrXX

How About Path Coverage? One test case covers only one path in the driver The path remains unrevealed if no defect found 100 test cases cover < 100 paths? More test cases -> more duplication XX I/O Mgr

XX XX XX weeks Path Coverage: Testing In Progress

XX XX XX weeks Failure paths Corner cases “Impossible” paths Path Coverage: Far From Complete

Path Coverage: Incomplete, Unknown XX XX XX weeks How many paths remain untested? 50% ? More? Corner cases Failure paths “Impossible” paths Just omissions

Path Coverage: Time To Market XX XX XX weeks Corner cases Failure paths “Impossible” paths Just omissions When are you done? How long would it take to test all of them? Longer than you can afford!

XX XX XX XX XX XX In minutes or hours, not weeks or months Employing Computer, not a Test Engineer Targeting a large set of potential violations Static Analysis: 100% Coverage

Static Analysis – How Does It Work? The tool builds an abstract model of a driver and exhaustively inspects execution along all paths The abstract model is simpler: it’s reduced... It’s so much simpler that it’s possible to have it inspected (“simulated”) exhaustively Over-approximation of the driver The control part remains the same All paths are preserved and treated equally The data state is over-approximated if argument x is not constrained, assume any value if (x>0) guards the point of interest, keep track of boolean (x>0), but not integer value of x: boolean is simpler than integer if (x > 0) { IoCompleteRequest (Irp); }

Static Analysis Not a silver bullet Does not replace functional testing Targets violations of a given set of well-defined constraints Principal limitation It doesn’t know about every possible error Algorithms are based on source code abstraction and heuristics Which results in both false positives and false negatives It is not a silver bullet… It is a useful tool

Our Static Tools For Drivers PREfast For Drivers (PFD) Lightweight and fast (runs in minutes) Easy to use early in development – start early Use on any code that compiles Limited to a procedure scope Works on any code, C and C++ Finds many local violations Static Driver Verifier (SDV) Extremely deep analysis (runs in hours) More useful in the later stages of development Requires complete driver Works over the whole driver Limited to WDM and to C (more planned) Finds deep bugs

A problem has been detected and Windows has been shut down to prevent Damage to your. Damage to your computer.DRIVER_IRQL_NOT_LESS_OR_EQUAL If this is the first time you've seen this Stop error screen, restart your computer. If this screen appears again, follow these steps: Check to make sure any new hardware or software is properly installed. If this is a new installation, ask your hardware or software Manufacturer for any Windows updates you might need. If problems continue, disable or remove any newly installed hardware or software. Disable BIOS memory options such as caching or shadowing. If you need to use Safe Mode to remove or disable components, restart your computer, press F8 to select Advanced Startup Options, and then select Safe Mode Technical information: *** STOP: 0x (0x , ,0x ,0x ) Driver Tools Relationship Easy Reproducibility Hard Easy Reproducibility Hard Depth Driver Verifier Static Driver Verifier PREfast for drivers Hard Ease Of Use Complex

PFD: PREfast For Drivers Fast (2-5x compile time, usually) Finds a lot of “inadvertent” errors and some “hard” ones Works on code that compiles; doesn’t need to run Some things it can find Null pointer, uninitialized variable (along an unusual path) Local leaks (memory, resource) Mismatched parameters Forgot to check result Format/list mismatch Misuse of IRQLs (some) Various special cases that are easily missed (Cancel IRQL, e.g.) Proper use of callback/function pointers

PFD: Driver Specific Resource Leak void LeakSample(BOOLEAN Option1) { NTSTATUS Status; KIRQL OldIrql; BufInfo *pBufInfo; KeAcquireSpinLock(MyLock,&OldIrql); //... if (Option1) { pBufInfo = ExAllocatePoolWithTag(NonPagedPool, sizeof(BufInfo), 'fuB_'); if (NULL==pBufInfo) { return STATUS_NO_MEMORY; } //... KeReleaseSpinLock(MyLock, OldIrql); return STATUS_SUCCESS; } //...

void LeakSample(BOOLEAN Option1) { NTSTATUS Status; KIRQL OldIrql; BufInfo *pBufInfo; KeAcquireSpinLock(MyLock,&OldIrql); //... if (Option1) { pBufInfo = ExAllocatePoolWithTag(NonPagedPool, sizeof(BufInfo), 'fuB_'); if (NULL==pBufInfo) { return STATUS_NO_MEMORY; } //... KeReleaseSpinLock(MyLock, OldIrql); return STATUS_SUCCESS; } //... PFD: Driver Specific Resource Leak warning 8103: Leaking the resource stored in 'SpinLock:MyLock'.

void LeakSample(BOOLEAN Option1) { NTSTATUS Status; KIRQL OldIrql; BufInfo *pBufInfo; KeAcquireSpinLock(MyLock,&OldIrql); //... if (Option1) { pBufInfo = ExAllocatePoolWithTag(NonPagedPool, sizeof(BufInfo), 'fuB_'); if (NULL==pBufInfo) { KeReleaseSpinLock(MyLock, OldIrql); KeReleaseSpinLock(MyLock, OldIrql); return STATUS_NO_MEMORY; } //... KeReleaseSpinLock(MyLock, OldIrql); return STATUS_SUCCESS; } //... PFD: Driver Specific Resource Leak

PFD: Annotations Tells PFD things it could not infer Enhance/enforce the “contract” between calling and called function Too much to cover here; there’s a paper with the details

PFD: Annotations – Example wchar_t * wmemset( s __out_ecount(s) wchar_t *p, __in wchar_t v, s __in size_t s); __in: the parameter is input to the function __out: the parameter is output from the function __out_ecount(s): the parameter is a buffer with s elements If the parameter p doesn’t contain at least s elements, PFD will yield a warning

Static Analysis Tools For Drivers Static Driver Verifier SDV

SDV: Session Outline IntroductionExampleConceptsRules DDI Model Verification Engine Experience

SDV: Introduction A “compile-time version” of Driver Verifier Inspects driver source code Looking for violations of DDI constraints Supports WDM drivers SDV 1.4 in Windows Vista WDK KMDF drivers Planned for Windows Server code-named “Longhorn” Preview in static analysis tools lab tomorrow

SDV: Quality Comprehensive path coverage Checks all possible paths in a driver Checks cross procedure calls Checks a driver together with libraries Finds deep defects that are hard to repro SDV is not perfect Only one driver (not the entire driver stack) DDI implementation code is abstracted away Might run out of time

SDV: Example Device Driver Interface IoCompleteRequest Driver Dispatch routine I/O System Irp Irp

SDV: Example XX Device Driver Interface IoCompleteRequest Driver Dispatch routine I/O System Irp IrpIrp

ParPort: A Double Completion Bug From Windows Server 2003 DDK (build 3677 or earlier) PptDispatchClose ( Irp ) P4CompleteRequest ( Irp ) IoCompleteRequest( Irp ); X X PptFdoClose( Irp ) P4CompleteRequestReleaseRemLoc ( Irp ) IO Mngr

SDV: Example Sample driver in the old DDK 3677

SDV: Example One defect foundXX

First Completion Double Completion

SDV: Concepts XX Rules Verificatio n Engine OS Model OS Model library.c more_code. c driver.c SDV

SDV: DDI Rules XX Rules Verificatio n Engine OS Model OS Model library.c more_code. c driver.c SDV DDI Model Verification Engine DDI Rules

SDV: DDI Rules XX Rules Verificatio n Engine OS Model library.c more_code. c driver.c SDV DDI Model Verification Engine DDI Rules

SDV: DDI Rules SDV comes with 66 WDM rules KMDF rules – planned for Windows Server code-named “Longhorn” A rule captures constraints imposed by DDI requirements A rule is a Finite State Machine (FSM) States Abort points trap violations Other states are interim points Events Associated with calls into DDI

SDV: WDK Tells DDI Constraints KeAcquire SpinLock KeRelease SpinLock Driver Entry Point I/O System Driver Development Interface

SDV: A DDI Constraint Is – A Rule Rule 1

SDV: One More Rule Rule 2

SDV: And Yet Another Rule Rule 3

SDV: Rule 1 KeAcquire SpinLock KeRelease SpinLock Driver Entry Point I/O System Abort Acquire Release Driver called Driver returns Unlocked Acquire Driver returns Locked Release KeAcquireSpinLock and KeReleaseSpinLock can only be called in alternate order Driver Development Interface

SDV: DDI Model XX Rules Verificatio n Engine OS Model OS Model library.c more_code. c driver.c SDV DDI Rules DDI Model Verificatio n Engine

SDV: DDI Model Wraps The Driver Main Calls DriverEntry Calls Dispatch Routines (WDM) or Driver Callbacks (KMDF) Aspects of the OS state Interrupt Request Level (IRQL) Stubs for hundreds of DDI functions IoCreateDevice, … Device Driver Interface I/O Systemmain IoCreateDeviceIoCompleteRequest Driver DriverEntry IRQL

SDV: DDI Model – Summary Captures aspects of Plug-n-Play life cycle of a driver The OS state DDI implementation Covers corner case scenarios DDI model must be balanced A more accurate model is bigger A bigger model brings more computational complexity for the engine to cope with

SDV: Verification Engine XX Rules Verificatio n Engine OS Model OS Model library.c more_code. c driver.c SDV DDI Rules DDI Model Verification Engine

SDV: Verification Engine Symbolic model checking of a C program Symbolically executes Your driver in the context of the DDI model While looking for rule violations Each and every path of the driver is checked How does it cope with computational complexity?

SDV: Abstract-Refine Loop Abstraction – throw away irrelevant details Model-checking on the reduced code Bug validation on the original code Refine the abstraction if the bug doesn’t show in the original code bug ? rule validate abstract refine model– check C code Driver DDI model X Reduced code

SDV: Our Practical Experience Finds deep bugs not found by testing 1 bug on average for a sample driver in Windows Server 2003 DDK-3677 Well tested drivers are often clean A dozen true bugs in a fresh driver Low Noise level Less than 1 false bug reported per driver 2 real bugs for 1 false bug on DDK-3677 samples Performance Runs in a few hours But may need to run overnight

Static Analysis Tools For Drivers Summary PREfast for Drivers Static Driver Verifier Availability Available now WDM rules are available KMDF rules are planned for LH Server – preview in Static Analysis Tools Lab Applicability C and C++ C only, up to 50K LOC Issues found Local defects Easy to fix High volume Global defects Harder to fix Low volume Development Cycle Apply early – “When the driver compiles” Run often Apply later – “When the basic structure of the driver is in place” Run ad hoc or overnight

Static Analysis Can The business case Reduce risk of expensive after-deployment bugs Reduce time to market Reduce cost of code review and testing Improve code quality Achieve higher test coverage The development case Find/prevent bugs earlier more directly and obviously Find/prevent “hard to test” bugs Make you more efficient

Use Static Analysis Wisely It doesn’t know about all possible errors It doesn’t make testing unnecessary Both false positives and false negatives can be misleading Static analysis tools complement testing It’s wise to use them as a major part of your quality strategy

Call To Action Use these static tools on your drivers Learn more about static analysis tools Read the “PREfast Step-by-Step” paper Read the “Introducing Static Driver Verifier” paper Read the Annotations paper Try the tools on your drivers or WDK samples at the lab tomorrow The lab requires a signed DPA Send us questions Give us feedback

Current Status Of SDV And PFD Use PFD included in the latest WDK available to you There are four versions of PREfast “out there” Latest one in WDK and previous versions in older DDKs Use PFD version 8.0.xxxxx Type “prefast” in a WDK build environment to view the PFD version Use SDV included in the latest WDK available to you There are two versions of SDV “out there” Latest one in WDK prereleases Use SDV version or later Type “staticdv” in a WDK build environment to view the SDV version

Additional Resources Whitepapers on WHDC web site PREfast step-by-step English: Links to Chinese and Japanese translations are also available on this page PREfast annotations Static Driver Verifier: finding bugs in device drivers at compile-time Introducing Static Driver Verifier Static Driver Verifier experience at Microsoft (PREfast for Drivers) (PREfast for Drivers) (Static Driver Verifier) (Static Driver Verifier) Related sessions Static Analysis Tools Lab microsoft.com microsoft.com

Questions?

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