Advanced programming tools at Microsoft K. Rustan M. Leino Microsoft Research, Redmond, WA, USA 16 May 2005 Distinguished lecture, York University Toronto, ON, Canada

Software engineering problem Building and maintaining large systems that are correct

Approach Specifications record design decisions bridge intent and code Tools amplify human effort manage details find inconsistencies ensure quality

Design decisions – examples and trends procedural abstraction int x; assert(x < a.Length); finite-state protocols mark-ups pre- and postconditions, and object invariants

More powerful techniques —a selection 0. PREfix 1. SLAM 2. SpecStrings 3. Spec#

0. PREfix Detects common errors in C/C++ Performs symbolic execution [Bush, Pincus, Sielaff, et al.] Detects common errors in C/C++ incorrect usage of null pointers, memory allocation, uninitialized variables, library idioms, ... Performs symbolic execution detailed C semantics paths simulated in detail, not all paths simulated interprocedural, procedures summarized by small subset of their paths

possible use of uninitialized variable PREfix example int abs(int x) { int y; if (0 <= x) { y = x; } return y; } possible use of uninitialized variable

PREfix virtues Expensive to run Reduces effects of spurious warnings whole-program analysis Reduces effects of spurious warnings filters and prioritizes output, uses heuristics Effective at finding errors 1/8 of bugs fixed in Windows Server 2003 found by PREfix (and PREfast) Widely deployed

The PREfast revolution [Weise, et al.] PREfast – framework for authoring analyses (walks AST) PREfix runs centrally after check-ins, PREfast can run on developer desktops before check-ins Name recognition, plug-ins

On the road to embracing static analysis: PREfix milestone PREfix and PREfast have opened eyes of developers and management to power of compile-time checking

1. Niche: device drivers bugs can have severe effects relatively small code base (usually ≤ 50 KLOC) crash-freedom specified by finite-state API protocols correctness mostly depends on flow of control, not data Acquire() Release() Acquire() Release()

SLAM Software model checking predicate abstraction [Ball, Rajamani, et al.] Software model checking predicate abstraction model checking (state exploration) counterexample-driven predicate refinement

Predicate abstraction and refinement correct model checker boolean program abstract trace predicate abstraction concrete trace C program predicates feasible? no yes error message predicate refinement

SLAM example do { KeAcquireSpinLock(); nPacketsOld = nPackets; if (request) { request = request->Next; KeReleaseSpinLock(); nPackets++; } } while (nPackets != nPacketsOld); Release() Acquire() Release()

SLAM example do { assert ¬P; P := true; // KeAcquireSpinLock(); Predicates: P: spin lock held do { assert ¬P; P := true; // KeAcquireSpinLock(); if ( * ) { assert P; P := false; // KeReleaseSpinLock(); } } while ( * );

error path in abstract program SLAM example Predicates: P: spin lock held do { assert ¬P; P := true; if ( * ) { assert P; P := false; } } while ( * ); error path in abstract program

SLAM example do { KeAcquireSpinLock(); nPacketsOld = nPackets; Predicates: P: spin lock held do { KeAcquireSpinLock(); nPacketsOld = nPackets; if (request) { request = request->Next; KeReleaseSpinLock(); nPackets++; } } while (nPackets != nPacketsOld); infeasible path in concrete program error path in abstract program

SLAM example do { KeAcquireSpinLock(); nPacketsOld = nPackets; Predicates: P: spin lock held Q: nPackets == nPacketsOld do { KeAcquireSpinLock(); nPacketsOld = nPackets; if (request) { request = request->Next; KeReleaseSpinLock(); nPackets++; } } while (nPackets != nPacketsOld); infeasible path in concrete program error path in abstract program

no error path in abstract program; hence, concrete program is correct SLAM example Predicates: P: spin lock held Q: nPackets == nPacketsOld do { assert ¬P; P := true; Q := true; // nPacketsOld = nPackets; if ( * ) { assert P; P := false; Q := if Q then false else * end; // nPackets++; } } while (¬ Q); // nPackets != nPacketsOld no error path in abstract program; hence, concrete program is correct

SLAM at Microsoft finite-state API protocols specified by experts applied to 100s of Windows drivers, for 10s of rules, found 60+ errors Static Driver Verifier transferred to Windows Driver Quality group to be released in DDK

On the road to embracing static analysis: SLAM milestone SLAM showcases specifications and powerful checking

2. SpecStrings company-wide effort to annotate C/C++ APIs [Das, Fähndrich, et al.] company-wide effort to annotate C/C++ APIs standard annotation language (SAL) for describing assumptions about parameters limited checking by PREfast plug-in can catch some null problems and buffer overruns

SpecString example void * memcpy( pre notnull pre writableTo(pre byteCount(num)) post readableTo(pre byteCount(num)) void * dest, pre readableTo(pre byteCount(num)) void * src, size_t num);

SpecStrings at Microsoft emphasizes importance of interfaces better documentation improves checking fewer spurious warnings can detect errors from violations of stated intent

On the road to embracing static analysis: SpecStrings milestone With SpecStrings, developers become used to source-code annotations that go beyond what compiler requires

3. Into the future managed code (C#, …) involve developers more intimately capture design decisions earlier let developers take control of their code reach beyond checking limits of current tools

Spec# Experimental mix of contracts and tool support Aimed at experienced developers who know the high cost of testing and maintenance Superset of C# non-null types pre- and postconditions object invariants Tool support more type checking compiler-emitted run-time checks static program verification contracts everywhere C# into the future type checking run-time checks static verification degree of checking, effort

Specifications today StringBuilder.Append Method (Char[ ], Int32, Int32) Appends the string representation of a specified subarray of Unicode characters to the end of this instance. public StringBuilder Append(char[] value, int startIndex, int charCount); Parameters value A character array. startIndex The starting position in value. charCount The number of characters append. Return Value A reference to this instance after the append operation has occurred. Exceptions Exception Type Condition ArgumentNullException value is a null reference, and startIndex and charCount are not zero. ArgumentOutOfRangeException charCount is less than zero. -or- startIndex is less than zero. startIndex + charCount is less than the length of value.

Spec# specifications Precondition Callers are expected to establish precondition before invoking method Implementations can assume precondition holds on entry public StringBuilder Append( char[ ] value, int startIndex, int charCount); requires value != null || (startIndex == 0 && charCount == 0); requires 0 <= startIndex && 0 <= charCount; requires startIndex + charCount <= value.Length; ensures result == this; Postcondition Implementations are expected to establish postcondition on exit Callers can assume postcondition upon return from method invocation

Object invariants readonly int rows; readonly int columns; readonly double[,] m; readonly int numInitialVars; readonly int numSlackVars; readonly int rhsColumn; readonly ArrayList<object> dims; readonly int[] basisColumns; readonly int[] inBasis; bool constructionDone = false; invariant rows == m.GetLength(0); invariant 1 <= columns && columns == m.GetLength(1); invariant 0 <= numInitialVars; invariant 0 <= numSlackVars && numSlackVars <= rows; invariant numInitialVars + numSlackVars + 1 == columns; invariant rhsColumn == columns - 1; invariant dims.Count == numInitialVars; invariant basisColumns.Length == rows; invariant inBasis.Length == numInitialVars + numSlackVars;

Spec# demo

Spec# verifier architecture Spec# compiler MSIL (“bytecode”) Spec# static program verifier, aka Boogie translator inference engine Boogie PL V.C. generator verification condition automatic theorem prover “correct” or list of errors

Analyzing verification conditions Automatic theorem prover can be hidden from programmer generates counterexamples Interactive theorem prover requires gurus not limited by built-in decision procedures

Generating verification conditions Weakest preconditions int AbsX(Robot c) requires c ≠ null; ensures 0 ≤ result; { if (0 ≤ c.x) { a := c.x; } else { a := −c.x; } return a; } c ≠ null  c ≠ null  (0 ≤ sel(c,x)  c ≠ null  0 ≤ sel(c,x))  (¬(0 ≤ sel(c,x))  c ≠ null  0 ≤ −sel(c,x)) c ≠ null  (0 ≤ sel(c,x)  c ≠ null  0 ≤ sel(c,x))  (¬(0 ≤ sel(c,x))  c ≠ null  0 ≤ −sel(c,x)) c ≠ null  0 ≤ sel(c,x) c ≠ null  0 ≤ −sel(c,x) 0 ≤ a 0 ≤ result

What’s in a language the programming language is the software engineer's primary thinking and working tool

Designing more rigor into the language Examples Type system impose coarse-grained restrictions easy to understand and use sound efficient checking General specifications enforce by mix of dynamic and static checking don’t worry about completeness or decidability Develop good defaults non-null types requires Pre; modifies Frame; ensures Post; Roll in what you can into the type system. Use general specifications where types don’t have their advantages. The defaults cope with the possibly overwhelming generality. requires this.inv = Valid; modifies this.*; ensures true;

Enforcing specifications Run-time checking may leave out expensive checks, if not required for soundness example: modifies clauses Static verification requires more effort from the user modular checking a necessity type checking run-time checks static verification degree of checking, effort

Migration problems To the new language From (!) the new language how does the language compare to existing ones? From (!) the new language development organizations may have process requirements contracts everywhere C# into the future

download Spec# from here Conclusions Trend toward more rigorous languages and checking Desire to contribute customized specifications Tool support is crucial Despite significant advances in the use of static analyses, we need more experience before we’d expect users to take on more detailed verification tasks Some areas where more research will help language design program semantics specification techniques inference algorithms decision procedures methodology http://research.microsoft.com/specsharp download Spec# from here