Static Analysis And Verification Of Drivers Outline Static

Static Analysis And Verification Of Drivers

Outline Static Tools What they are The benefits of using them PREfast Static Driver Verifier

What Is Static Analysis? Analyze what the program will do without actually executing it Flags violations of rules and conventions needed for correct program execution Flow analysis tool builds an abstract model, simulates execution The abstraction allows otherwise very difficult analysis, e. g. “rough idea” of the value of a variable The abstraction is approximate, but complete (all paths are treated equally) An abstraction: more compact and easier to manipulate than the program itself

Why Static Analysis? Static Analysis can reduce defects by up to a factor of six! (Capers Jones, Software Productivity Group) 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 Can… The business case Reduce time to market by cutting testing time due to earlier detection of bugs Significantly reduce review effort by automating a major portion of the process Better chance of finding deep bugs by removing more obvious bugs Improve code quality by directly supporting adherence to programming practices

Static Analysis Can… The development case Find / prevent bugs earlier (before they’re hard to fix) Find / prevent bugs more directly / obviously Find / prevent bugs while developing Find / prevent “hard to test” bugs Make you more efficient

Limitations Any simulation / analysis is imperfect Some false positives (noise) Some false negatives (didn’t find what it should have) Just because the tools say a driver is good, don’t believe it The tools are simply saying they couldn’t find anything more The biggest risk with using static tools is overconfidence The second biggest risk is not using them at all

Microsoft’s Static Tools For Drivers PREfast for Drivers (PFD) Lightweight / fast Easy to use early in development Limited to function scope Works on anything, C and C++ Static Driver Verifier (SDV) Extremely deep analysis More useful in the later stages of development Requires complete driver Works over the whole driver Limited to some kinds of drivers, and to C If you have access to others, use them, but use PFD and SDV, too

Driver Tools Relationship Hard Ease Of Use Reproducibility Easy Hard A problem has been detected and Windows has been shut down to prevent Damage to your computer. . DRIVER_IRQL_NOT_LESS_OR_EQUAL PREfast For Drivers If this is the first time you've seen this Stop error screen, restart your computer. If this screen appears again, follow these steps: Depth 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. Driver Verifier Static Driver Verifier 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 F 8 to select Advanced Startup Options, and then select Safe Mode Technical information: Complex *** STOP: 0 x 00000001 (0 x 0000000, 00000002, 0 x 00000000) By cook

PREfast For Drivers (PFD) Fast (2 -5 x compile time, usually) Finds a lot of “stupid” errors and some “hard” ones Works on code that compiles; doesn’t need to run User or Kernel mode drivers, C or C++, any size 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 (esp. in recent versions)

Sample: Driver Specific Resource Leak #include <wdm. h > <wdm. h> void Leak. Sample(BOOLEAN Option 1) PKSPIN_LOCK My. Lock; { typedef struct { NTSTATUS Status; char buff[100]; KIRQL Old. Irql; } Buf. Info; Buf. Info *p. Buf. Info; Ke. Acquire. Spin. Lock(My. Lock, &Old. Irql); //. . . if (Option 1) { p. Buf. Info = Ex. Allocate. Pool. With. Tag(Non. Paged. Pool, sizeof(Buf. Info), 'fu. B_'); if (NULL==p. Buf. Info) { return STATUS_NO_MEMORY; } //. . . Ke. Release. Spin. Lock(My. Lock, Old. Irql); return STATUS_SUCCESS; } //. . .

Sample: Driver Specific Resource Leak #include <wdm. h > <wdm. h> void Leak. Sample(BOOLEAN Option 1) PKSPIN_LOCK My. Lock; { typedef struct { NTSTATUS Status; char buff[100]; KIRQL Old. Irql; } Buf. Info; Buf. Info *p. Buf. Info; Ke. Acquire. Spin. Lock(My. Lock, &Old. Irql); //. . . if (Option 1) { p. Buf. Info = Ex. Allocate. Pool. With. Tag(Non. Paged. Pool, sizeof(Buf. Info), 'fu. B_'); warning 8103: Leaking the if (NULL==p. Buf. Info) { resource stored in return STATUS_NO_MEMORY; 'Spin. Lock: My. Lock'. } //. . . Ke. Release. Spin. Lock(My. Lock, Old. Irql); return STATUS_SUCCESS; } //. . .

Sample: Driver Specific Resource Leak #include <wdm. h > <wdm. h> void Leak. Sample(BOOLEAN Option 1) PKSPIN_LOCK My. Lock; { typedef struct { NTSTATUS Status; char buff[100]; KIRQL Old. Irql; } Buf. Info; Buf. Info *p. Buf. Info; Ke. Acquire. Spin. Lock(My. Lock, &Old. Irql); //. . . if (Option 1) { p. Buf. Info = Ex. Allocate. Pool. With. Tag(Non. Paged. Pool, sizeof(Buf. Info), 'fu. B_'); if (NULL==p. Buf. Info) { Ke. Release. Spin. Lock(My. Lock, Old. Irql); return STATUS_NO_MEMORY; } //. . . Ke. Release. Spin. Lock(My. Lock, Old. Irql); return STATUS_SUCCESS; } //. . .

Filter Presets PFD comes with a number of filters to reduce the set of things you look at. (See the “Filters” button in the viewer. ) WSPMIN: the “you really, really should fix these” set Drivers_only: high-likelihood of being driver problems Drivers_all: the combination of the two above But: take a few minutes to look at all the bugs (in your sources and headers) and see if there’s anything else that scares you If you don’t agree with the presets (either way) let us know so we can get better

PFD Limitations The usual static tool limitations Executable is currently 32 -bit only Designed to work on 32 bit applications, but compile 64 -bit applications as 32 -bit and get most of the benefit Function-scope analysis

Hints Watch out for “continuable asserts” You thought the assert made it impossible, but if it’s like many drivers, there’s a way to continue from the debugger. PFD doesn’t know that. Use __declspec(noreturn) and #if _PREFAST_ Twice around a loop If it looks “impossible” check the order of the line numbers listed: you might be going around a loop more than once to get to the error Read the documents for other hints. It’s really hard to explain some things in a sentence or two

Using PREfast For Drivers There are three versions of PREfast (New) Driversion (2. 1. xxxx) (PFD): in the WDK (the only “PREfast” there) Older (in DDK) (Old) Driversion (1. 5. 2402): Default in the newest Server 2003 SP 1 DDK. (See DDK online documents if you have older DDKs) (Run ‘prefast version’ and look for 1. 5. 2402) Non-driversion (1. 5. 2400): Default in older versions of 2003 SP 1 DDK. (Avoid using: not as useful to you. ) Read the “PREfast Step-by-Step” paper

Static Driver Verifier Introduction Example Concepts Rules OS Model Verification Engine Summary

Introduction Static Driver Verifier Is a compile time static analysis tool Operates on driver source code Completely Automatic What Static Driver Verifier does Finds bugs in drivers Verifies that the driver adheres to the WDM interface requirements

Introduction Supported Drivers WDM drivers Functions drivers Filter drivers Bus drivers Only pure C drivers Up to 50 K lines of code Support for KMDF planned post Longhorn

Example I/O System Irp Dispatch function Driver Irp; Irp X Io. Complete. Request Device Driver Interface

Example Parport driver sample in Win XP SP 1 DDK

Example X One defect found

Double First Completion

Example Server 2003 SP 1 DDK ü Rule Passes

Introduction Quality Comprehensive Path Coverage Driver is exercised in a hostile environment Verifies all possible paths in the drivers Verifies cross function calls Verifies driver together with supporting libraries But there are places where SDV is imprecise Only one driver (not the entire driver stack) OS Model imperfect The verification engine is not precise

Introduction Experience Defects SDV finds a few serious, hard to repro defects The defects are inherently complex Performance SDV may run in a few minutes But may also need to run overnight

Concepts library. c Rules more_code. c driver. c SDV Verificatio n Engine OS Model ü X

Concepts library. c Rules more_code. c driver. c SDV Verificatio n Engine OS Model ü X

Rules library. c more_code. c driver. c Rules SDV Verificatio n Engine OS Model ü X

Rules Each rule captures an aspect of the WDM interface requirements Rules are written in a language called SLIC Each rule defines State declarations in form of C style variables Events that are associated with DDI functions SDV comes with 64 rules IRP Rules IRQL Rules Pn. P Rules Synchronization Rules Other Miscellaneous rules Ideas to new rules are welcome!

Spin. Lock Rule I/O System Entry Point Driver Ke. Acquire Spin. Lock Ke. Release Spin. Lock Device Driver Interface

Spin. Lock Rule Unlocked Ke. Acquire Spin. Lock Release Acquire Driver returns Entry Point Driver called I/O System state { enum {unlocked, locked} s = unlocked; } Ke. Release Spin. Lock Device Driver Interface Locked Re lea se Abort d lle a e c urns r i et qu r c r A ive r D

Spin. Lock Rule I/O System Entry Point Driver Ke. Acquire Spin. Lock Ke. Release Spin. Lock Device Driver Interface state { enum {unlocked, locked} s = unlocked; } Run. Dispatch. Function. exit { if (s != unlocked) abort; } Ke. Acquire. Spin. Lock. entry { if (s != unlocked) abort; else s = locked; } Ke. Release. Spin. Lock. entry { if (s != locked) abort; else s = unlocked; }

IRP Rules Pnp. Surprise. Remove Double. Completion Forwarded. At. Bad. Irql Irp. Processing. Complete Marking. Interlocked. Queued. Irps Marking. Queued. Irps Pended. Completed. Request Null. Device. Object. Forwarded Target. Relation. Needs. Ref Pnp. Irp. Completion Requested. Power. Irp Start. Io. Cancel Start. Io. Recursion Lower. Driver. Return Wmi. Complete Wmi. Forward Mark. Irp. Pending

IRQL Rules Irql. Ke. Release. Spin. Lock Forwarded. At. Bad. Irql. Apc. Lte Irql. Dispatch. Lt Irql. Ex. Allocate. Pool Irql. Ex. Passive Irql. Io. Passive 1 Irql. Io. Passive 2 Irql. Io. Passive 3 Irql. Io. Passive 4 Irql. Io. Passive 5 Irql. Ke. Dispatch. Lte Irql. Io. Build. Device. Io. Control. Request Irql. Ke. Passive Irql. Ke. Raise. Lower Irql. Ke. Set. Event Irql. Ke. Wait. For. Mutex. Object Irql. Ke. Wait. For. Single. Object Irql. Mm. Passive Irql. Ob. Passive Irql. Probe. Passive Irql. Ps. Passive Irql. Return Irql. Rtl. Passive Irql. Zw. Passive Paged. Code Irql. Ke. Insert. Queue. Dpc

IRQL Rules Irql. Ke. Release. Spin. Lock Irql. Ke. Passive Forwarded. At. Bad. Irql. Ke. Raise. Lower Irql. Apc. Lte Irql. Ke. Set. Event Irql. Dispatch Irql. Ke. Wait. For. Mutex. Object Irql. Dispatch. Lt Irql. Ke. Wait. For. Single. Object Irql. Ex. Allocate. Pool Irql. Mm. Passive Irql. Ex. Passive Irql. Ob. Passive Irql. Io. Passive 1 Irql. Probe. Passive Irql. Io. Passive 2 Irql. Ps. Passive Irql. Io. Passive 3 Irql. Return Irql. Ke. Release. Spin. Lock. slic: Irql. Io. Passive 4 Irql. Rtl. Passive Ke. Release. Spin. Lock. entry Irql. Io. Passive 5 Irql. Zw. Passive { if (irql != DISPATCH_LEVEL) abort; Irql. Ke. Dispatch. Lte Paged. Code else if ($2 != previous_irql) abort; Irql. Io. Build. Device. Io. Control. Request Irql. Ke. Insert. Queue. Dpc }

Operating System Model library. c Rules more_code. c driver. c SDV Verificatio n Engine OS Model ü X

Operating System Model Introduction I/O System Driver Exercises the driver Calls Driver. Entry Calls Dispatch functions Calls ISRs Models certain aspects of the OS state Like the current Interrupt Request Level Device Driver Interface Models Device Driver Interface functions Like the Io. Create. Device function

Operating System Model Device Driver Interface Functions I/O System Io. Create. Device( … , OUT *Device. Object ) { … switch (choice) { case 0: (*Device. Object) = p. Valid. Device; return STATUS_SUCCESS; case 1: (*Device. Object) = NULL; return STATUS_INSUFFICIENT_RESOURCES; Driver case 2: (*Device. Object) = NULL; return STATUS_OBJECT_NAME_EXISTS; default: (*Device. Object) = NULL; return STATUS_OBJECT_NAME_COLLISION; } Io. Create. Device Driver Interface }

Verification Engine library. c Rules more_code. c driver. c SDV Verification Engine OS Model ü X

Verification Engine Executes Your driver in the context of the OS Model While keeping track of the rule state While looking for rule violations Checks each and every path of the driver Implements worst case behavior Symbolic model checker Strategy: Throw away many irrelevant details through aggressive, but correct, abstraction

Practical Experience It reports serious bugs indeed present in a driver 1+ bug in average for sample drivers in Server 2003 DDK (3677) Reasonable Noise level 33% false positives on 30 DDK samples SDV does not report tons of suspicious issues Less than 1 false bug reported per driver, in average Experiments show High quality drivers are often clean One driver with 15 bugs reported of which 14 were true

Static Driver Verifier Summary SDV is a compile-time tool that finds bugs in device drivers Finds corner cases that are hard to reproduce with Driver Verifier Finds bugs that are deeper than PREfast for Drivers SDV is composed of three parts Rules OS Model Verification Engine SDV can help improve the quality of your driver

Static Analysis Tools For Drivers Summary PREfast for Drivers Tool Status Applicability Issues found Development Cycle Available now Static Driver Verifier Planned for beta program WDM drivers Yes C only • Local defects • Global defects • Easy to fix • Harder to fix • Potentially high volume • Generally Low volume Apply early: Apply later: “When the driver “When the basic structure of compiles” the driver is in place. . ” Run often Run ad hoc or overnight

Additional Resources Email Pfdfdbk @ microsoft. com (PREfast for Drivers) Sdvfdbk @ microsoft. com (Static Driver Verifier) Web Resources Whitepapers PREfast with Driver specific Rules on http: //www. microsoft. com/whdc/devtools/PREfast-drv. mspx PREfast Step-by-Step http: //www. microsoft. com/whdc/Dev. Tools/tools/PREfast_steps. mspx Static Driver Verifier: Finding Bugs in Device Drivers at Compile-Time on http: //www. microsoft. com/whdc/devtools/SDV. mspx

© 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.