The SLAM Project: Debugging System Software via Static Analysis

transcript

The SLAM Project:Debugging System Software via Static Analysis

Thomas BallSriram K. Rajamani

Microsoft Researchhttp://research.microsoft.com/slam/

Thanks To

Sagar Chaki (CMU) Satyaki Das (Stanford) Rupak Majumdar (UC Berkeley) Todd Millstein (U. Washington) Robby (KSU) Westley Weimer (UC Berkeley)

Andreas Podelski (MPI) Stefan Schwoon (U. Edinburgh)

Software Productivity Tools Research group at MSR

SLAM Agenda

Overview

Termination (of SLAM)

Termination (of talk)

Specifying and Checking Properties of Programs

Goals defect detection partial validation

Properties memory safety temporal safety security …

Many (mature) techniquesautomated deductionprogram analysistype checkingmodel checking

Many projectsBandera, ESC-Java, FeaVer, JPF, LClint, OSQ, PolyScope, PREfix, rccjava, TVLA, Verisoft, Vault, xgcc, …

ProgrammingTesting

APIUsage Rules

Windows Device Drivers Kernel presents a very complex interface to driver

stack of drivers NT kernel multi-threaded IRP completion, IRQL, plug-n-play, power management,

Correct API usage described by finite state protocols

Automatically check that clients respect these protocols

CallDriver

MPRcompletion

not pending returned

IPCCallDriver

Skip returnchild status

Completerequest

returnnot Pend

PPCprop

completion

CallDriver

no propcompletion

CallDriver

start NP

returnPending

MPRcompletion

IPCCallDriver

CallDriver

Completerequest

PPCprop

completion

CallDriver

no propcompletion

CallDriver

start P Mark Pending

IRP accessible N/A

SKIP1CallDriver

SKIP1Skip

MPR2 MPR1

CallDrivernot pending returned

The SLAM Thesis

We can soundly and precisely check a program without annotations against API rules by creating a program abstraction exploring the abstraction’s state space refining the abstraction

We can scale such an approach to many 100kloc via modular analysis model checking

SLAM Input

API usage rules client C source code “as is”

Analysis create, explore and refine boolean program

abstractions

Output Error traces (minimize noise) Verification (soundness)

Usage Rule for Locking

Unlocked Locked Error

state {

int locked = 0;

KeAcquireSpinLock.call {

if (locked==1) abort;

else locked = 1;

KeReleaseSpinLock.call {

if (locked==0) abort;

else locked = 0;

SLICState Machine

Example

do { //get the write lock

KeAcquireSpinLock(&devExt->writeListLock);

nPacketsOld = nPackets; request = devExt->WLHeadVa;

if (request){KeReleaseSpinLock(&devExt->writeListLock);...nPackets++;

}} while (nPackets != nPacketsOld);KeReleaseSpinLock(&devExt->writeListLock);

Loop Invariant: nPackets = nPacketsOld IFF lock is held

newton

prog. P’prog. P

SLIC rules

The SLAM Process

boolean program

path p

predicates

Instrumented Codedo { //get the write lock

SLIC_KeAcquireSpinLock_call();KeAcquireSpinLock(&devExt->writeListLock);

if (request){SLIC_KeReleaseSpinLock_call();KeReleaseSpinLock(&devExt->writeListLock);...nPackets++;

}} while (nPackets != nPacketsOld);SLIC_KeReleaseSpinLock_call();KeReleaseSpinLock(&devExt->writeListLock);

Predicate Abstraction of C (c2bp)

Input: a C program P and set of predicates E predicate = pure C boolean expression

Output: a boolean program bp(P,E) that is a sound abstraction of P a precise (boolean) abstraction of P

Results separate compilation (predicate abstraction) in

presence of procedures and pointers

Skeletal Boolean Program

do //get the write lock

SLIC_KeAcquireSpinLock_call();

if (*) then SLIC_KeReleaseSpinLock_call();

fiwhile (*);SLIC_KeReleaseSpinLock_call();

Predicates:

(locked==0)(locked==1)

Reachability in Boolean Programs (bebop)

Symbolic interprocedural data flow analysis Based on CFL-reachability [Reps-Horwitz-Sagiv 95] Explicit representation of CFG Implicit representation of reachable states via BDDs

Worst-case complexity is O( P (GL)3 ) P = program size G = number of global states in state machine L = max. number of local states over all procedures

Shortest Error Path (Acquire 2x)

SLIC_KeAcquireSpinLock_call();

fiwhile (*);SLIC_KeReleaseSpinLock_call();

Predicates:

(locked==0)(locked==1)

Counterexample-driven Refinement (newton)

Symbolically execute path in C program

Check for path infeasibility at each conditional Simplify theorem prover

If path is infeasible, generate new predicates to rule out infeasible path heuristics to generate “weak” explanation

Error Path in C code

do { //get the write lock

KeAcquireSpinLock(&devExt->writeListLock);

if (request){KeReleaseSpinLock(&devExt->writeListLock);...nPackets++;

}} while (nPackets != nPacketsOld);KeReleaseSpinLock(&devExt->writeListLock);

Newton: Path Simulation

Store:

Conditions:

nPackets = nPacketsOld;

request = devExt->WLHeadVa;

assume(!request);

assume(nPackets != nPacketsOld);

Newton

Store:

(1) nPacketsOld:

Conditions:

assume(!request);

Newton

Store:

(1) nPacketsOld:

(2) nPackets: (1)

Conditions:

assume(!request);

Newton

Store:

(1) nPacketsOld:

(2) nPackets: (1)

(3) devExt:

Conditions:

assume(!request);

Newton

assume(!request);

Store:

(1) nPacketsOld:

(2) nPackets: (1)

(3) devExt:

(4) ->WLHeadVa: (3)

Conditions:

Newton

Store:

(1) nPacketsOld:

(2) nPackets: (1)

(3) devExt:

(4) ->WLHeadVa: (3)

(5) request: (3,4)

Conditions:

assume(!request);

Newton

Store:

(1) nPacketsOld:

(2) nPackets: (1)

(3) devExt:

(4) ->WLHeadVa: (3)

(5) request: (3,4)

Conditions:

assume(!request);

Newton

Store:

(1) nPacketsOld:

(2) nPackets: (1)

(3) devExt:

(4) ->WLHeadVa: (3)

(5) request: (3,4)

Conditions:

!= (1,2)

assume(!request);

Newton

Store:

(1) nPacketsOld:

(2) nPackets: (1)

(3) devExt:

(4) ->WLHeadVa: (3)

(5) request: (3,4)

Conditions:

!= (1,2)

assume(!request);

Newton

Store:

(1) nPacketsOld:

(2) nPackets: (1)

Conditions:

!= (1,2)

assume(!request);

Newton

Predicates:

(nPacketsOld == )

(nPackets == )

( != )

assume(!request);

Newton

Predicates:

(nPacketsOld != nPackets)

assume(!request);

Newton

Predicates:

(nPacketsOld == nPackets)

assume(!request);

Refined Boolean Program

SLIC_KeAcquireSpinLock_call();b := true; // npacketsOld = npackets;

b := b ? false : *; // npackets++;fi

while ( !b ); // (nPackets != nPacketsOld);SLIC_KeReleaseSpinLock_call();

Boolean variable b represents the condition

(nPacketsOld==nPackets)

Results on Drivers (so far)

Handful of drivers analyzed so far 2k-30k of C code each

Each driver has yielded bugs

SLAM process has always terminated minutes to ½ hour

Process optimizations have huge effects

Lock example validation

Lock example with bug error trace

SLAM’s first bug floppy device driver

Termination of SLAM

[Cousot-Cousot, PLILP’92] widening + abstract interpretation with infinite lattices

(WAIL) is more powerful than a (single) finite abstraction

[Ball-Podelski-Rajamani, TACAS’02] finite abstractions plus iterative refinement (FAIR) is more

powerful than WAIL

Termination and Widening

Widening is used to achieve termination by enlarging the set of states (to reach a fixpoint) 5 x 10 widened to 5 x

Of course, widening may lose precision

Every fixpoint algorithm that loses precision (in order to terminate) uses widening (implicitly)

Fixpoint

X := init;while X S do X’ := X F(X) if X’ X then break

X := X’odreturn X S

X := init;while X S do X’ := X F(X) if X’ X then break i := oracle’s guess X := W(i, X’)odreturn X S

Fixpoint + Widening(WAIL)

Search Space of Widenings

Finite Abstraction + Iterative Refinement

X := init; while true do P := atoms(X); X# := lfp(F#

P, init)

if X# S then break X := X F(X)odreturn X# S

If WAIL succeeds in N iterations then FAIR will succeed in N iterations

But, FAIR can succeed earlier, due to use of interior (abstract) fixpoint

Search Space

WAIL+oracle FAIR

Searching for Solutions

Once upon a time, only a human could play a great game of chess… … but then smart brute force won the day (Deep Blue vs.

Kasparov)

Once upon a time, only a human could design a great abstraction…

Termination of Talk

SLAM automatically discovers inductive invariants viapredicate abstraction of C programsmodel checking of boolean programscounterexample-driven refinement

Implemented and starting to yield results on NT device drivers

SLAMming on the shoulders of …

Model checking predicate abstraction counterexample-driven

refinement BDDs and symbolic model

checking

Program analysis abstract interpretation points-to analysis dataflow via CFL-

reachability

Automated deduction weakest preconditions theorem proving

Software AST toolkit Das’s Golf CU and CMU BDD Simplify, Vampyre OCAML

SLAM Future Work More impact

Static Driver Verifier (internal, external)

More features Heap abstractions Concurrency

More languages C# and CIL

More users 2002 public release of SLAM toolkit

Predictions

The holy grail of full program verification has been abandoned

New checking tools will emerge and be widely used

Tools will exploit ideas from various analysis disciplines alleviate the “chicken-and-egg” problem of

specifications

Challenges / SLAM Reading List

Specifications Mining specifications

Abstractions Predicate abstraction for software verification

Annotations Types as models: model checking MP programs Role analysis

Soundness Ccured: type-safe retrofitting of legacy code

Scaling Lazy abstraction

The End

The SLAM Project: Debugging System Software via Static Analysis

Documents