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

2. Software engineering problem
Building and maintaining large systems that are correct

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

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

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

6. 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

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

8. 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

9. 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

10. 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

11. 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()

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

13. 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

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

15. 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 ( * );

16. 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

17. 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

18. 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

19. 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

20. 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

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

22. 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

23. 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);

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

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

26. 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

27. 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

28. 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.

29. 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

30. 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;

31. Spec# demo

32. 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

33. 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

34. 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

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

36. 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;

37. 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

38. 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

39. 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
download Spec# from here