Software Model Checking with SLAM Thomas Ball Testing, Verification and Measurement Sriram K. Rajamani Software Productivity Tools Microsoft Research

Slides:



Advertisements
Similar presentations
A SAT characterization of boolean-program correctness K. Rustan M. Leino Microsoft Research, Redmond, WA 14 Nov 2002 IFIP WG 2.4 meeting, Schloβ Dagstuhl,
Advertisements

Advanced programming tools at Microsoft
The Static Driver Verifier Research Platform
The SLAM Project: Debugging System Software via Static Analysis
Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Semantics Static semantics Dynamic semantics attribute grammars
Context-Sensitive Interprocedural Points-to Analysis in the Presence of Function Pointers Presentation by Patrick Kaleem Justin.
Abstraction and Modular Reasoning for the Verification of Software Corina Pasareanu NASA Ames Research Center.
Bebop: A Symbolic Model Checker for Boolean Programs Thomas Ball Sriram K. Rajamani
1 Lecture 08(c) – Predicate Abstraction and SLAM Eran Yahav.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 13.
1 Thorough Static Analysis of Device Drivers Byron Cook – Microsoft Research Joint work with: Tom Ball, Vladimir Levin, Jakob Lichtenberg,
A survey of techniques for precise program slicing Komondoor V. Raghavan Indian Institute of Science, Bangalore.
Chair of Software Engineering Software Verification Stephan van Staden Lecture 10: Model Checking.
Automatic Predicate Abstraction of C-Programs T. Ball, R. Majumdar T. Millstein, S. Rajamani.
Thomas Ball, Rupak Majumdar, Todd Millstein, Sriram K. Rajamani Presented by Yifan Li November 22nd In PLDI 01: Programming Language.
1 Automatic Predicate Abstraction of C Programs Parts of the slides are from
ISBN Chapter 3 Describing Syntax and Semantics.
Verification of parameterised systems
Fall Semantics Juan Carlos Guzmán CS 3123 Programming Languages Concepts Southern Polytechnic State University.
Symmetry-Aware Predicate Abstraction for Shared-Variable Concurrent Programs Alastair Donaldson, Alexander Kaiser, Daniel Kroening, and Thomas Wahl Computer.
The Software Model Checker BLAST by Dirk Beyer, Thomas A. Henzinger, Ranjit Jhala and Rupak Majumdar Presented by Yunho Kim Provable Software Lab, KAIST.
Summarizing Procedures in Concurrent Programs Shaz Qadeer Sriram K. Rajamani Jakob Rehof Microsoft Research.
Software Verification via Refinement Checking Sagar Chaki, Edmund Clarke, Alex Groce, CMU Somesh Jha, Wisconsin.
Termination Proofs for Systems Code Andrey Rybalchenko, EPFL/MPI joint work with Byron Cook, MSR and Andreas Podelski, MPI PLDI’2006, Ottawa.
Lazy Abstraction Thomas A. Henzinger Ranjit Jhala Rupak Majumdar Grégoire Sutre UC Berkeley.
ESC Java. Static Analysis Spectrum Power Cost Type checking Data-flow analysis Model checking Program verification AutomatedManual ESC.
Synergy: A New Algorithm for Property Checking
Secrets of Software Model Checking Thomas Ball Sriram K. Rajamani Software Productivity Tools Microsoft Research
SLAM Over the Summer Wes Weimer (Tom Ball, Sriram Rajamani, Manuvir Das)
1 Predicate Abstraction of ANSI-C Programs using SAT Edmund Clarke Daniel Kroening Natalia Sharygina Karen Yorav (modified by Zaher Andraus for presentation.
Speeding Up Dataflow Analysis Using Flow- Insensitive Pointer Analysis Stephen Adams, Tom Ball, Manuvir Das Sorin Lerner, Mark Seigle Westley Weimer Microsoft.
CS 267: Automated Verification Lectures 14: Predicate Abstraction, Counter- Example Guided Abstraction Refinement, Abstract Interpretation Instructor:
Automatically Validating Temporal Safety Properties of Interfaces Thomas Ball and Sriram K. Rajamani Software Productivity Tools, Microsoft Research Presented.
Software Reliability Methods Sorin Lerner. Software reliability methods: issues What are the issues?
Predicate Abstraction for Software and Hardware Verification Himanshu Jain Model checking seminar April 22, 2005.
1 Program Analysis Mooly Sagiv Tel Aviv University Textbook: Principles of Program Analysis.
ESC Java. Static Analysis Spectrum Power Cost Type checking Data-flow analysis Model checking Program verification AutomatedManual ESC.
Review: forward E { P } { P && E } TF { P && ! E } { P 1 } { P 2 } { P 1 || P 2 } x = E { P } { \exists … }
Review: forward E { P } { P && E } TF { P && ! E } { P 1 } { P 2 } { P 1 || P 2 } x = E { P } { \exists … }
Describing Syntax and Semantics
Lazy Abstraction Tom Henzinger Ranjit Jhala Rupak Majumdar Grégoire Sutre.
Program Analysis Mooly Sagiv Tel Aviv University Sunday Scrieber 8 Monday Schrieber.
Automatic Predicate Abstraction of C Programs Thomas BallMicrosoft Rupak MajumdarUC Berkeley Todd MillsteinU Washington Sriram K. RajamaniMicrosoft
Formal Verification of SpecC Programs using Predicate Abstraction Himanshu Jain Daniel Kroening Edmund Clarke Carnegie Mellon University.
272: Software Engineering Fall 2012 Instructor: Tevfik Bultan Lecture 4: SMT-based Bounded Model Checking of Concurrent Software.
Lecture #11 Software Model Checking: automating the search for abstractions Thomas Ball Testing, Verification and Measurement Microsoft Research.
272: Software Engineering Fall 2012 Instructor: Tevfik Bultan Lecture 3: Modular Verification with Magic, Predicate Abstraction.
Rule Checking SLAM Checking Temporal Properties of Software with Boolean Programs Thomas Ball, Sriram K. Rajamani Microsoft Research Presented by Okan.
Aditya V. Nori, Sriram K. Rajamani Microsoft Research India.
SLAM :Software Model Checking From Theory To Practice Sriram K. Rajamani Software Productivity Tools Microsoft Research.
Newton: A tool for generating abstract explanations of infeasibility1 The Problem P (C Program) BP (Boolean Program of P) CFG(P) CFG(BP)
Thomas Ball Sriram K. Rajamani
Use of Models in Analysis and Design Sriram K. Rajamani Rigorous Software Engineering Microsoft Research, India.
Automatically Validating Temporal Safety Properties of Interfaces Thomas Ball, Sriram K. MSR Presented by Xin Li.
Chapter 3 Part II Describing Syntax and Semantics.
SLAM internals Sriram K. Rajamani Rigorous Software Engineering Microsoft Research, India.
Verification & Validation By: Amir Masoud Gharehbaghi
The Yogi Project Software property checking via static analysis and testing Aditya V. Nori, Sriram K. Rajamani, Sai Deep Tetali, Aditya V. Thakur Microsoft.
Static Techniques for V&V. Hierarchy of V&V techniques Static Analysis V&V Dynamic Techniques Model Checking Simulation Symbolic Execution Testing Informal.
1 Automatically Validating Temporal Safety Properties of Interfaces - Overview of SLAM Parts of the slides are from
Counter Example Guided Refinement CEGAR Mooly Sagiv.
Boolean Programs: A Model and Process For Software Analysis By Thomas Ball and Sriram K. Rajamani Microsoft technical paper MSR-TR Presented by.
Presentation Title 2/4/2018 Software Verification using Predicate Abstraction and Iterative Refinement: Part Bug Catching: Automated Program Verification.
Formal methods: Lecture
Software Model Checking with SLAM
Over-Approximating Boolean Programs with Unbounded Thread Creation
Predicate Abstraction
Course: CS60030 Formal Systems
Presentation transcript:

Software Model Checking with SLAM Thomas Ball Testing, Verification and Measurement Sriram K. Rajamani Software Productivity Tools Microsoft Research

People behind SLAM Summer interns –Sagar Chaki, Todd Millstein, Rupak Majumdar (2000) –Satyaki Das, Wes Weimer, Robby (2001) –Jakob Lichtenberg, Mayur Naik (2002) Visitors –Giorgio Delzanno, Andreas Podelski, Stefan Schwoon Windows Partners –Byron Cook, Vladimir Levin, Abdullah Ustuner

Outline Part I: Overview (30 min) –overview of SLAM process –demonstration (Static Driver Verifier) –lessons learned Part II: Basic SLAM (1 hour) –foundations –basic algorithms (no pointers) Part III: Advanced Topics (30 min) –pointers + procedures –imprecision in aliasing and mod analysis

Part I: Overview of SLAM

What is SLAM? SLAM is a software model checking project at Microsoft Research –Goal: Check C programs (system software) against safety properties using model checking –Application domain: device drivers Starting to be used internally inside Windows –Working on making this into a product

Source Code Testing Development Precise API Usage Rules (SLIC) Software Model Checking Read for understanding New API rules Drive testing tools Defects 100% path coverage Rules Static Driver Verifier

SLAM – Software Model Checking SLAM innovations –boolean programs: a new model for software –model creation (c2bp) –model checking (bebop) –model refinement (newton) SLAM toolkit –built on MSR program analysis infrastructure

SLIC Finite state language for stating rules –monitors behavior of C code –temporal safety properties (security automata) –familiar C syntax Suitable for expressing control-dominated properties –e.g. proper sequence of events –can encode data values inside state

State Machine for Locking UnlockedLocked Error Rel Acq Rel state { enum {Locked,Unlocked} s = Unlocked; } KeAcquireSpinLock.entry { if (s==Locked) abort; else s = Locked; } KeReleaseSpinLock.entry { if (s==Unlocked) abort; else s = Unlocked; } Locking Rule in SLIC

prog. P’ prog. P SLIC rule The SLAM Process boolean program path predicates slic c2bp bebop newton

do { KeAcquireSpinLock(); nPacketsOld = nPackets; if(request){ request = request->Next; KeReleaseSpinLock(); nPackets++; } } while (nPackets != nPacketsOld); KeReleaseSpinLock(); Example Does this code obey the locking rule?

do { KeAcquireSpinLock(); if(*){ KeReleaseSpinLock(); } } while (*); KeReleaseSpinLock(); Example Model checking boolean program (bebop) U L L L L U L U U U E

do { KeAcquireSpinLock(); nPacketsOld = nPackets; if(request){ request = request->Next; KeReleaseSpinLock(); nPackets++; } } while (nPackets != nPacketsOld); KeReleaseSpinLock(); Example Is error path feasible in C program? (newton) U L L L L U L U U U E

do { KeAcquireSpinLock(); nPacketsOld = nPackets; b = true; if(request){ request = request->Next; KeReleaseSpinLock(); nPackets++; b = b ? false : *; } } while (nPackets != nPacketsOld); !b KeReleaseSpinLock(); Example Add new predicate to boolean program (c2bp) b : (nPacketsOld == nPackets) U L L L L U L U U U E

do { KeAcquireSpinLock(); b = true; if(*){ KeReleaseSpinLock(); b = b ? false : *; } } while ( !b ); KeReleaseSpinLock(); b b b b Example Model checking refined boolean program (bebop) b : (nPacketsOld == nPackets) U L L L L U L U U U E b b !b

Example do { KeAcquireSpinLock(); b = true; if(*){ KeReleaseSpinLock(); b = b ? false : *; } } while ( !b ); KeReleaseSpinLock(); b : (nPacketsOld == nPackets) b b b b U L L L L U L U U b b !b Model checking refined boolean program (bebop)

Observations about SLAM Automatic discovery of invariants –driven by property and a finite set of (false) execution paths –predicates are not invariants, but observations –abstraction + model checking computes inductive invariants (boolean combinations of observations) A hybrid dynamic/static analysis –newton executes path through C code symbolically –c2bp+bebop explore all paths through abstraction A new form of program slicing –program code and data not relevant to property are dropped –non-determinism allows slices to have more behaviors

Part I: Demo Static Driver Verifier results

Part I: Lessons Learned

SLAM Boolean program model has proved itself Successful for domain of device drivers –control-dominated safety properties –few boolean variables needed to do proof or find real counterexamples Counterexample-driven refinement –terminates in practice –incompleteness of theorem prover not an issue

What is hard? Abstracting –from a language with pointers (C) –to one without pointers (boolean programs) All side effects need to be modeled by copying (as in dataflow) Open environment problem

What stayed fixed? Boolean program model Basic tool flow Repercussions: –newton has to copy between scopes –c2bp has to model side-effects by value-result –finite depth precision on the heap is all boolean programs can do

What changed? Interface between newton and c2bp We now use predicates for doing more things refine alias precision via aliasing predicates newton helps resolve pointer aliasing imprecision in c2bp

Scaling SLAM Largest driver we have processed has ~60K lines of code Largest abstractions we have analyzed have several hundred boolean variables Routinely get results after iterations Out of 672 runs we do daily, 607 terminate within 20 minutes

Scale and SLAM components Out of 67 runs that time out, tools that take longest time: –bebop: 50, c2bp: 10, newton: 5, constrain: 2 C2bp: –fast predicate abstraction (fastF) and incremental predicate abstraction (constrain) –re-use across iterations Newton: –biggest problems are due to scope-copying Bebop: –biggest issue is no re-use across iterations –solution in the works

SLAM Status –foundations, algorithms, prototyping –papers in CAV, PLDI, POPL, SPIN, TACAS March 2002 –Bill Gates review May 2002 –Windows committed to hire two people with model checking background to support Static Driver Verifier (SLAM+driver rules) July 2002 –running SLAM on 100+ drivers, 20+ properties September 3, 2002 –made initial release of SDV to Windows (friends and family) April 1, 2003 –made wide release of SDV to Windows (any internal driver developer)

Part II: Basic SLAM

C- Types  ::= void | bool | int | ref  Expressionse::=c | x | e 1 op e 2 | &x | *x LExpression l ::= x | *x Declarationd::=  x 1,x 2,…,x n Statementss::=skip | goto L 1,L 2 …L n | L: s | assume(e) | l = e | l = f (e 1,e 2,…,e n ) |return x |s 1 ; s 2 ;… ; s n Procedures p ::=  f (x 1 :  1,x 2 :  2,…,x n :  n ) Programg ::= d 1 d 2 … d n p 1 p 2 … p n

C-- Types  ::= void | bool | int Expressionse::=c | x | e 1 op e 2 LExpression l ::= x Declarationd::=  x 1,x 2,…,x n Statementss::=skip | goto L 1,L 2 …L n | L: s | assume(e) | l = e |f (e 1,e 2,…,e n ) |return |s 1 ; s 2 ;… ; s n Procedures p ::= f (x 1 :  1,x 2 :  2,…,x n :  n ) Programg ::= d 1 d 2 … d n p 1 p 2 … p n

BP Types  ::= void | bool Expressionse::=c | x | e 1 op e 2 LExpression l ::= x Declarationd::=  x 1,x 2,…,x n Statementss::=skip | goto L 1,L 2 …L n | L: s | assume(e) | l = e |f (e 1,e 2,…,e n ) |return |s 1 ; s 2 ;… ; s n Procedures p ::= f (x 1 :  1,x 2 :  2,…,x n :  n ) Programg ::= d 1 d 2 … d n p 1 p 2 … p n

Syntactic sugar if (e) { S1; } else { S2; } S3; goto L1, L2; L1: assume(e); S1; goto L3; L2: assume(!e); S2; goto L3; L3: S3;

Example, in C void cmp (int a, int b) { if (a == b) g = 0; else g = 1; } int g; main(int x, int y){ cmp(x, y); if (!g) { if (x != y) assert(0); }

void cmp(int a, int b) { goto L1, L2; L1: assume(a==b); g = 0; return; L2: assume(a!=b); g = 1; return; } int g; main(int x, int y){ cmp(x, y); assume(!g); assume(x != y) assert(0); } Example, in C--

prog. P’ prog. P SLIC rule The SLAM Process boolean program path predicates slic c2bp bebop newton

c2bp: Predicate Abstraction for C Programs Given P : a C program F = {e 1,...,e n } –each e i a pure boolean expression –each e i represents set of states for which e i is true Produce a boolean program B(P,F) same control-flow structure as P boolean vars {b 1,...,b n } to match {e 1,...,e n } properties true of B(P,F) are true of P

Assumptions Given P : a C program F = {e 1,...,e n } –each e i a pure boolean expression –each e i represents set of states for which e i is true Assume: each e i uses either: –only globals (global predicate) –local variables from some procedure (local predicate for that procedure) Mixed predicates: –predicates using both local variables and global variables –complicate “return” processing –covered in advanced topics

C2bp Algorithm Performs modular abstraction –abstracts each procedure in isolation Within each procedure, abstracts each statement in isolation –no control-flow analysis –no need for loop invariants

void cmp (int a, int b) { goto L1, L2 L1: assume(a==b); g = 0; return; L2: assume(a!=b); g = 1; return; } int g; main(int x, int y){ cmp(x, y); assume(!g); assume(x != y) assert(0); } Preds: {x==y} {g==0} {a==b}

void cmp (int a, int b) { goto L1, L2 L1: assume(a==b); g = 0; return; L2: assume(a!=b); g = 1; return; } int g; main(int x, int y){ cmp(x, y); assume(!g); assume(x != y) assert(0); } decl {g==0} ; main( {x==y} ) { } void cmp ( {a==b} ) { } Preds: {x==y} {g==0} {a==b}

void equal (int a, int b) { goto L1, L2 L1: assume(a==b); g = 0; return; L2: assume(a!=b); g = 1; return; } int g; main(int x, int y){ cmp(x, y); assume(!g); assume(x != y) assert(0); } decl {g==0} ; main( {x==y} ) { cmp( {x==y} ); assume( {g==0} ); assume( !{x==y} ); assert(0); } void cmp ( {a==b} ) { goto L1, L2; L1: assume( {a==b} ); {g==0} = T; return; L2: assume( !{a==b} ); {g==0} = F; return; } Preds: {x==y} {g==0} {a==b}

C-- Types  ::= void | bool | int Expressionse::=c | x | e 1 op e 2 LExpression l ::= x Declarationd::=  x 1,x 2,…,x n Statementss::=skip | goto L 1,L 2 …L n | L: s | assume(e) | l = e | f (e 1,e 2,…,e n ) | return | s 1 ; s 2 ;… ; s n Procedures p ::= f (x 1 :  1,x 2 :  2,…,x n :  n ) Programg ::= d 1 d 2 … d n p 1 p 2 … p n

Statement y=y+1 and F={ y<4, y<5 } –{y<4}, {y<5} = ((!{y<5} || !{y<4}) ? F : *), {y<4} ; WP(x=e,Q) = Q[x -> e] WP(y=y+1, y<5)= (y y+1] = (y+1<5) = (y<4) Abstracting Assigns via WP

WP Problem WP(s, e i ) not always expressible via { e 1,...,e n } Example –F = { x==0, x==1, x<5 } –WP( x=x+1, x<5 ) = x<4 –Best possible: x==0 || x==1

Abstracting Expressions via F F = { e 1,...,e n } Implies F (e) –best boolean function over F that implies e ImpliedBy F (e) –best boolean function over F implied by e –ImpliedBy F (e) = !Implies F (!e)

Implies F (e) and ImpliedBy F (e) e Implies F (e) ImpliedBy F (e)

Computing Implies F (e) minterm m = d 1 &&... && d n –where d i = e i or d i = !e i Implies F (e) –disjunction of all minterms that imply e Naïve approach –generate all 2 n possible minterms –for each minterm m, use decision procedure to check validity of each implication m  e Many optimizations possible

Abstracting Assignments if Implies F (WP(s, e i )) is true before s then –e i is true after s if Implies F (WP(s, !e i )) is true before s then –e i is false after s {e i } = Implies F (WP(s, e i )) ?true : Implies F (WP(s, !e i )) ? false : *;

Assignment Example Statement in P: Predicates in E: y = y+1; {x==y} Weakest Precondition: WP(y=y+1, x==y) = x==y+1 Implies F ( x==y+1 ) = false Implies F ( x!=y+1 ) = x==y Abstraction of assignment in B: {x==y} = {x==y} ? false : *;

Absracting Assumes WP( assume(e), Q) = e  Q assume(e) is abstracted to: assume( ImpliedBy F (e) ) Example: F = {x==2, x<5} assume(x < 2) is abstracted to: assume( {x<5} && !{x==2} )

Abstracting Procedures Each predicate in F is annotated as being either global or local to a particular procedure Procedures abstracted in two passes: –a signature is produced for each procedure in isolation –procedure calls are abstracted given the callees’ signatures

Abstracting a procedure call Procedure call –a sequence of assignments from actuals to formals –see assignment abstraction Procedure return –NOP for C-- with assumption that all predicates mention either only globals or only locals –with pointers and with mixed predicates: Most complicated part of c2bp Covered in the advanced topics section

void cmp (int a, int b) { Goto L1, L2 L1: assume(a==b); g = 0; return; L2: assume(a!=b); g = 1; return; } int g; main(int x, int y){ cmp(x, y); assume(!g); assume(x != y) assert(0); } decl {g==0} ; main( {x==y} ) { cmp( {x==y} ); assume( {g==0} ); assume( !{x==y} ); assert(0); } void cmp ( {a==b} ) { Goto L1, L2 L1: assume( {a==b} ); {g==0} = T; return; L2: assume( !{a==b} ); {g==0} = F; return; } {x==y} {g==0} {a==b}

Precision For program P and E = {e 1,...,e n }, there exist two “ideal” abstractions: –Boolean(P,E) : most precise abstraction –Cartesian(P,E) : less precise abtraction, where each boolean variable is updated independently –[See Ball-Podelski-Rajamani, TACAS 00] Theory: –with an “ideal” theorem prover, c2bp can compute Cartesian(P,E) Practice: –c2bp computes a less precise abstraction than Cartesian(P,E) –we use Das/Dill’s technique to incrementally improve precision –with an “ideal” theorem prover, the combination of c2bp + Das/Dill can compute Boolean(P,E)

prog. P’ prog. P SLIC rule The SLAM Process boolean program path predicates slic c2bp bebop newton

Bebop Model checker for boolean programs Based on CFL reachability –[Sharir-Pnueli 81] [Reps-Sagiv-Horwitz 95] Iterative addition of edges to graph –“path edges”:  –“summary edges”: 

Symbolic CFL reachability  Partition path edges by their “target”  PE(v) = { |  }  What is for boolean programs?  A bit-vector!  What is PE(v)?  A set of bit-vectors  Use a BDD (attached to v) to represent PE(v)

BDDs Canonical representation of –boolean functions –set of (fixed-length) bitvectors –binary relations over finite domains Efficient algorithms for common dataflow operations –transfer function –join/meet –subsumption test void cmp ( e2 ) { [5]Goto L1, L2 [6]L1: assume( e2 ); [7] gz = T; goto L3; [8]L2: assume( !e2 ); [9]gz = F; goto L3 [10] L3: return; } e2=e2’ & gz’=e2’ BDD at line [10] of cmp: Read: “cmp leaves e2 unchanged and sets gz to have the same final value as e2”

gz=gz’& e=e’ e=e’& gz’=e’ e=e’ & gz’=1 & e’=1 gz=gz’& e2=e2’ gz=gz’& e2=e2’& e2’=T e2=e2’& gz’=e2’ decl gz ; main( e ) { [1] equal( e ); [2] assume( gz ); [3] assume( !e ); [4] assert(F); } void cmp ( e2 ) { [5]Goto L1, L2 [6]L1: assume( e2 ); [7] gz = T; goto L3; [8]L2: assume( !e2 ); [9]gz = F; goto L3 [10] L3: return; } gz=gz’& e2=e2’& e2’=F e2=e2’& e2’=T & gz’=T e2=e2’& e2’=F & gz’=F e2=e

Bebop: summary  Explicit representation of CFG  Implicit representation of path edges and summary edges  Generation of hierarchical error traces  Complexity: O(E * 2 O(N) )  E is the size of the CFG  N is the max. number of variables in scope

prog. P’ prog. P SLIC rule The SLAM Process boolean program path predicates slic c2bp bebop newton

Newton Given an error path p in boolean program B –is p a feasible path of the corresponding C program? Yes: found an error No: find predicates that explain the infeasibility –uses the same interfaces to the theorem provers as c2bp.

Newton Execute path symbolically Check conditions for inconsistency using theorem prover (satisfiability) After detecting inconsistency: –minimize inconsistent conditions –traverse dependencies –obtain predicates

Symbolic simulation for C-- Domains –variables: names in the program –values: constants + symbols State of the simulator has 3 components: –store: map from variables to values –conditions: predicates over symbols –history: past valuations of the store

Symbolic simulation Algorithm Input: path p For each statement s in p do match s with Assign(x,e): let val = Eval(e) in if (Store[x]) is defined then History[x] := History[x]  Store[x] Store[x] := val Assume(e): let val = Eval(e) in Cond := Cond and val let result = CheckConsistency(Cond) in if (result == “inconsistent”) then GenerateInconsistentPredicates() End Say “Path p is feasible”

Symbolic Simulation: Caveats Procedure calls –add a stack to the simulator –push and pop stack frames on calls and returns –implement mappings to keep values “in scope” at calls and returns Dependencies –for each condition or store, keep track of which values where used to generate this value –traverse dependency during predicate generation

void cmp (int a, int b) { Goto L1, L2 L1: assume(a==b); g = 0; return; L2: assume(a!=b); g = 1; return; } int g; main(int x, int y){ cmp(x, y); assume(!g); assume(x != y) assert(0); }

void cmp (int a, int b) { Goto L1, L2 L1: assume(a==b); g = 0; return; L2: assume(a!=b); g = 1; return; } int g; main(int x, int y){ cmp(x, y); assume(!g); assume(x != y) assert(0); } Global: main: (1)x: X (2)y: Y Conditions :

void cmp (int a, int b) { Goto L1, L2 L1: assume(a==b); g = 0; return; L2: assume(a!=b); g = 1; return; } int g; main(int x, int y){ cmp(x, y); assume(!g); assume(x != y) assert(0); } Global: main: (1)x: X (2)y: Y cmp : (3)a: A (4)b: B Conditions : Map : X  A Y  B

void cmp (int a, int b) { Goto L1, L2 L1: assume(a==b); g = 0; return; L2: assume(a!=b); g = 1; return; } int g; main(int x, int y){ cmp(x, y); assume(!g); assume(x != y) assert(0); } Global: (6) g: 0 main: (1)x: X (2)y: Y cmp : (3)a: A (4)b: B Conditions : (5)(A == B) [3, 4] Map : X  A Y  B

void cmp (int a, int b) { Goto L1, L2 L1: assume(a==b); g = 0; return; L2: assume(a!=b); g = 1; return; } int g; main(int x, int y){ cmp(x, y); assume(!g); assume(x != y) assert(0); } Global: (6) g: 0 main: (1)x: X (2)y: Y cmp : (3)a: A (4)b: B Conditions : (5)(A == B) [3, 4] (6)(X == Y) [5] Map : X  A Y  B

void cmp (int a, int b) { Goto L1, L2 L1: assume(a==b); g = 0; return; L2: assume(a!=b); g = 1; return; } int g; main(int x, int y){ cmp(x, y); assume(!g); assume(x != y) assert(0); } Global: (6) g: 0 main: (1)x: X (2)y: Y cmp : (3)a: A (4)b: B Conditions : (5)(A == B) [3, 4] (6)(X == Y) [5] (7) (X != Y) [1, 2]

void cmp (int a, int b) { Goto L1, L2 L1: assume(a==b); g = 0; return; L2: assume(a!=b); g = 1; return; } int g; main(int x, int y){ cmp(x, y); assume(!g); assume(x != y) assert(0); } Global: (6) g: 0 main: (1)x: X (2)y: Y cmp : (3)a: A (4)b: B Conditions : (5)(A == B) [3, 4] (6)(X == Y) [5] (7) (X != Y) [1, 2] Contradictory!

void cmp (int a, int b) { Goto L1, L2 L1: assume(a==b); g = 0; return; L2: assume(a!=b); g = 1; return; } int g; main(int x, int y){ cmp(x, y); assume(!g); assume(x != y) assert(0); } Global: (6) g: 0 main: (1)x: X (2)y: Y cmp : (3)a: A (4)b: B Conditions : (5)(A == B) [3, 4] (6)(X == Y) [5] (7) (X != Y) [1, 2] Contradictory!

void cmp (int a, int b) { Goto L1, L2 L1: assume(a==b); g = 0; return; L2: assume(a!=b); g = 1; return; } int g; main(int x, int y){ cmp(x, y); assume(!g); assume(x != y) assert(0); } Predicates after simplification: { x == y, a == b }

Part III: Advanced Topics

Types  ::= void | bool | int | ref  Expressionse::=c | x | e 1 op e 2 | &x | *x LExpression l ::= x | *x Declarationd::=  x 1,x 2,…,x n Statementss::=skip | goto L 1,L 2 …L n | L: s | assume(e) | l = e | l = f (e 1,e 2,…,e n ) |return x |s 1 ; s 2 ;… ; s n Procedures p ::=  f (x 1 :  1,x 2 :  2,…,x n :  n ) Programg ::= d 1 d 2 … d n p 1 p 2 … p n C-

Two Problems Extending SLAM tools for pointers Dealing with imprecision of alias analysis

Pointers and SLAM With pointers, C supports call by reference –Strictly speaking, C supports only call by value –With pointers and the address-of operator, one can simulate call-by-reference Boolean programs support only call-by-value-result –SLAM mimics call-by-reference with call-by-value-result Extra complications: –address operator (&) in C –multiple levels of pointer dereference in C

What changes with pointers? C2bp –abstracting assignments –abstracting procedure returns Newton –simulation needs to handle pointer accesses –need to copy local heap across scopes to match Bebop’s semantics –need to refine imprecise alias analysis using predicates Bebop –remains unchanged!

Assignments + Pointers Weakest Precondition: WP( *p=3, x==5 ) = x==5 What if *p and x alias? We use Das’s pointer analysis [PLDI 2000] to prune disjuncts representing infeasible alias scenarios. Correct Weakest Precondition: (p==&x and 3==5) or (p!=&x and x==5) Statement in P:Predicates in E: *p = 3 {x==5}

Abstracting Procedure Return Need to account for –lhs of procedure call –mixed predicates –side-effects of procedure Boolean programs support only call-by- value-result –C2bp models all side-effects using return processing

Abstracting Procedure Returns Let a be an actual at call-site P(…) –pre(a) = the value of a before transition to P Let f be a formal of a procedure P –pre(f) = the value of f upon entry to P

int R (int f) { int r = f+1; f = 0; return r; } WP(x=r, x==2) = r==2 Q() { int x = 1; x = R(x) } pre(f) == pre(x) x = r {x==1} {x==2} {f==pre(f)} {r==pre(f)+1} predicatecall/return relationcall/return assign {x==2} = s & {x==1}; } bool R ( {f==pre(f)} ) { {r==pre(f)+1} = {f==pre(f)}; {f==pre(f)} = *; return {r==pre(f)+1}; } WP(f=x, f==pre(f) ) = x==pre(f) f = x x==pre(f) is true at the call to R pre(f)==pre(x) and pre(x)==1 and r==pre(f)+1 implies r==2 Q() { {x==1},{x==2} = T,F; s = R(T); {x==1}s

{x==1}, {x==2} = *, s & {x==1}; } int R (int f) { int r = f+1; f = 0; return r; } WP(x=r, x==2) = r==2 Q() { int x = 1; x = R(x) } {x==1} {x==2} {f==pre(f)} {r==pre(f)+1} predicatecall/return relationcall/return assign bool R ( {f==pre(f)} ) { {r==pre(f)+1} = {f==pre(f)}; {f==pre(f)} = *; return {r==pre(f)+1}; } WP(f=x, f==pre(f) ) = x==pre(f) x==pre(f) is true at the call to R pre(f)==pre(x) and pre(x)==1 and r==pre(f)+1 implies r==2 Q() { {x==1},{x==2} = T,F; s = R(T); {x==1}s f = x x = r pre(f) == pre(x)

Extending Pre-states Suppose formal parameter is a pointer –eg. P(int *f) pre( *f ) –value of *f upon entry to P –can’t change during P * pre( f ) –value of dereference of pre( f ) –can change during P

int R (int *a) { *a = *a+1; } Q() { int x = 1; R(&x); } pre(a) = &x {x==1} {x==2} predicatecall/return relationcall/return assign {x==2} = s & {x==1}; } bool R ( {a==pre(a)}, {*pre(a)==pre(*a)} ) { {*pre(a)==pre(*a)+1} = {a==pre(a)} & {*pre(a)==pre(*a)} ; return {*pre(a)==pre(*a)+1}; } a = &x Q() { {x==1},{x==2} = T,F; s = R(T,T); {a==pre(a)} {*pre(a)==pre(*a)} {*pre(a)=pre(*a)+1} pre(x)==1 and pre(*a)==pre(x) and *pre(a)==pre(*a)+1 and pre(a)==&x implies x==2 {x==1 } s

Newton: what changes with pointers? Simulation needs to handle pointer accesses Need to copy local heap across scopes to match Bebop’s semantics

void foo (int *a) { assume(*a > 5); assert(0); } main(int *x){ assume(*x < 5); foo(x); }

Contradictory! void foo (int *a) { assume(*a > 5); assert(0); } main(int *x){ assume(*x < 5); foo(x); } main: (1) x: X (2)*X: Y [1] foo : (3) a: A (4)*A: B [3] Conditions : (5)(Y< 5) [1,2] (6)(B < 5) [3,4,5] (7)(B > 5) [3,4] Predicates after simplification: *x 5

SLAM Imprecision due to Alias Imprecision (Flow Insensitivity) x = 0; y = 0; p = &y *p = *p + 1; assume(x!=0); p = &x; {x==0} {x==0} = T; skip; {x==0} = *; assume( !{x==0} ); skip; Pts-to(p) = { &x, &y}

x = 0; y = 0; p = &y if (p == &x) x = x + 1; else y = y + 1; assume(x!=0); p = &x; x = 0; y = 0; p = &y *p = *p + 1; assume(x!=0); p = &x; {x==0} = T; skip; {x==0} = *; assume(!{x==0} ); skip; Newton: Path is Infeasible

Consider values in abstract trace x = 0; y = 0; p = &y *p = *p + 1; assume(x!=0); p = &x; {x==0} = T; skip; {x==0} = *; assume(!{x==0} ); skip; {x==0} is true {x==0} is false INCONSISTENT

Consider values in abstract trace x = 0; y = 0; p = &y *p = *p + 1; assume(x!=0); p = &x; {x==0} = T; skip; {x==0} = *; assume(!{x==0} ); skip; WP(*p = *p +1, !(x==0) ) = ((p == &x) and !(x==-1)) or ((p != &x) and !(x==0)) (p!=&x) gets added as a predicate

What changes with pointers? C2bp –abstracting assignments –abstracting procedure returns Newton –simulation needs to handle pointer accesses –need to copy local heap across scopes to match Bebop’s semantics –need to refine imprecise alias analysis using predicates Bebop –remains unchanged!

What worked well? Specific domain problem Safety properties Shoulders & synergies Separation of concerns Summer interns & visitors –Sagar Chaki, Todd Millstein, Rupak Majumdar (2000) –Satyaki Das, Wes Weimer, Robby (2001) –Jakob Lichtenberg, Mayur Naik (2002) –Giorgio Delzanno, Andreas Podelski, Stefan Schwoon Windows Partners –Byron Cook, Vladimir Levin, Abdullah Ustuner

Future Work Concurrency –SLAM analyzes drivers one thread at a time –Work in progress to analyze interleavings between threads Rules and environment-models –Large scale development or rules and environment-models is a challenge –How can we simplify and manage development of rules? Modeling C semantics faithfully Theory: –Prove that SLAM will make progress on any property and any program –Identify classes of programs and properties on which SLAM will terminate

Further Reading See papers, slides from:

Glossary Model checkingChecking properties by systematic exploration of the state-space of a model. Properties are usually specified as state machines, or using temporal logics Safety propertiesProperties whose violation can be witnessed by a finite run of the system. The most common safety properties are invariants ReachabilitySpecialization of model checking to invariant checking. Properties are specified as invariants. Most common use of model checking. Safety properties can be reduced to reachability. Boolean programs“C”-like programs with only boolean variables. Invariant checking and reachability is decidable for boolean programs. PredicateA Boolean expression over the state-space of the program eg. (x < 5) Predicate abstractionA technique to construct a boolean model from a system using a given set of predicates. Each predicate is represented by a boolean variable in the model. Weakest preconditionThe weakest precondition of a set of states S with respect to a statement T is the largest set of states from which executing T, when terminating, always results in a state in S.