The SLAM Project: Debugging System Software via Static Analysis

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
Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
A Program Transformation For Faster Goal-Directed Search Akash Lal, Shaz Qadeer Microsoft Research.
Automatic Verification Book: Chapter 6. What is verification? Traditionally, verification means proof of correctness automatic: model checking deductive:
Abstraction and Modular Reasoning for the Verification of Software Corina Pasareanu NASA Ames Research Center.
1 Symbolic Execution for Model Checking and Testing Corina Păsăreanu (Kestrel) Joint work with Sarfraz Khurshid (MIT) and Willem Visser (RIACS)
Lecture #21 Software Model Checking: predicate abstraction Thomas Ball Testing, Verification and Measurement Microsoft Research.
Bebop: A Symbolic Model Checker for Boolean Programs Thomas Ball Sriram K. Rajamani
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,
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.
Verification of parameterised systems
BLAST-A Model Checker for C Developed by Thomas A. Henzinger (EPFL) Rupak Majumdar (UC Los Angeles) Ranjit Jhala (UC San Diego) Dirk Beyer (Simon Fraser.
The Software Model Checker BLAST by Dirk Beyer, Thomas A. Henzinger, Ranjit Jhala and Rupak Majumdar Presented by Yunho Kim Provable Software Lab, KAIST.
Software Verification via Refinement Checking Sagar Chaki, Edmund Clarke, Alex Groce, CMU Somesh Jha, Wisconsin.
Thread-modular Abstraction Refinement Tom Henzinger Ranjit Jhala Rupak Majumdar Shaz Qadeer.
Termination Proofs for Systems Code Andrey Rybalchenko, EPFL/MPI joint work with Byron Cook, MSR and Andreas Podelski, MPI PLDI’2006, Ottawa.
Software Verification with Blast Thomas A. Henzinger, Ranjit Jhala, Rupak Majumdar, George Necula, Grégoire Sutre, Wes Weimer UC Berkeley.
Lazy Abstraction Thomas A. Henzinger Ranjit Jhala Rupak Majumdar Grégoire Sutre UC Berkeley.
Thread-modular Abstraction Refinement Tom Henzinger Ranjit Jhala Rupak Majumdar [UC Berkeley] Shaz Qadeer [Microsoft Research]
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)
Speeding Up Dataflow Analysis Using Flow- Insensitive Pointer Analysis Stephen Adams, Tom Ball, Manuvir Das Sorin Lerner, Mark Seigle Westley Weimer Microsoft.
Counter Example Guided Refinement CEGAR Mooly Sagiv.
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.
Synthesis of Interface Specifications for Java Classes Rajeev Alur University of Pennsylvania Joint work with P. Cerny, G. Gupta, P. Madhusudan, W. Nam,
Temporal-Safety Proofs for Systems Code Thomas A. Henzinger Ranjit Jhala Rupak Majumdar George Necula Westley Weimer Grégoire Sutre UC Berkeley.
Software Verification with BLAST Tom Henzinger Ranjit Jhala Rupak Majumdar.
Efficient Software Model Checking of Data Structure Properties Paul T. Darga Chandrasekhar Boyapati The University of Michigan.
Specifying and Checking Properties of Programs Thomas Ball Sriram K. Rajamani Software Productivity Tools Microsoft Research.
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
Symbolic Path Simulation in Path-Sensitive Dataflow Analysis Hari Hampapuram Jason Yue Yang Manuvir Das Center for Software Excellence (CSE) Microsoft.
Verifying Concurrent Message- Passing C Programs with Recursive Calls Sagar Chaki, Edmund Clarke, Nicholas Kidd, Thomas Reps, and Tayssir Touili.
Towards Scalable Modular Checking of User-defined Properties Thomas Ball, MSR Brian Hackett, Mozilla Shuvendu Lahiri, MSR Shaz Qadeer, MSR Julien Vanegue,
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.
Parameterized Verification of Thread-safe Libraries Thomas Ball Sagar Chaki Sriram K. Rajamani.
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.
Model Checking C Programs Zijiang (James) Yang Department of Computer Science Western Michigan University In collaboration with NEC Laboratories America.
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.
#1 Having a BLAST with SLAM. #2 Software Model Checking via Counter-Example Guided Abstraction Refinement Topic: Software Model Checking via Counter-Example.
Verifying Regular Behavior of C modules Sagar Chaki, Edmund Clarke, Alex Groce, CMU Somesh Jha, Wisconsin.
Presentation Title 2/4/2018 Software Verification using Predicate Abstraction and Iterative Refinement: Part Bug Catching: Automated Program Verification.
Having a BLAST with SLAM
Software Model Checking with SLAM
Abstractions from Proofs
The Zoo of Software Security Techniques
Predicate Abstraction
Course: CS60030 Formal Systems
BLAST: A Software Verification Tool for C programs
Presentation transcript:

The SLAM Project: Debugging System Software via Static Analysis Thomas Ball Sriram K. Rajamani Microsoft Research http://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 Summer interns Visitors Members of MSR

SLAM Agenda Overview Demo Termination (of SLAM) Termination (of talk)

Specifying and Checking Properties of Programs Many (mature) techniques automated deduction program analysis type checking model checking Many projects Bandera, ESC-Java, FeaVer, JPF, LClint, OSQ, PolyScope, PREfix, rccjava, TVLA, Verisoft, Vault, xgcc, … Goals defect detection partial validation Properties memory safety temporal safety security … elapsed time: 1

API Usage Rules Programming Testing elapsed time: 2 Code

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 elapsed time: 4

start NP CallDriver SKIP1 SKIP2 return child status Skip CallDriver IPC MPR3 synch NP CallDriver prop completion PPC not pending returned MPR completion Complete request MPR2 CallDriver MPR1 DC return not Pend no prop completion synch CallDriver N/A N/A IRP accessible start P CallDriver Mark Pending SKIP1 SKIP2 Skip CallDriver IPC MPR3 synch NP CallDriver prop completion return Pending PPC not pending returned MPR completion Complete request MPR2 CallDriver MPR1 DC no prop completion CallDriver N/A

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

SLAM Input Analysis Output API usage rules client C source code “as is” Analysis create, explore and refine boolean program abstractions Output Error traces (minimize noise) Verification (soundness) ET 8

Usage Rule for Locking SLIC State Machine U L L U Unlocked Locked int locked = 0; } KeAcquireSpinLock.call { if (locked==1) abort; else locked = 1; KeReleaseSpinLock.call { if (locked==0) abort; else locked = 0; SLIC U L Unlocked Locked Error L ET 9 U

Example do { //get the write lock KeAcquireSpinLock(&devExt->writeListLock); nPacketsOld = nPackets; request = devExt->WLHeadVa; if (request){ KeReleaseSpinLock(&devExt->writeListLock); ... nPackets++; } } while (nPackets != nPacketsOld); ET 11 Loop Invariant: nPackets = nPacketsOld IFF lock is held

The SLAM Process predicates boolean program c2bp prog. P prog. P’ slic bebop SLIC rules ET 12 newton path p

Instrumented Code do { //get the write lock SLIC_KeAcquireSpinLock_call(); KeAcquireSpinLock(&devExt->writeListLock); nPacketsOld = nPackets; request = devExt->WLHeadVa; if (request){ SLIC_KeReleaseSpinLock_call(); KeReleaseSpinLock(&devExt->writeListLock); ... nPackets++; } } while (nPackets != nPacketsOld); Put state machine in picture Fix the colors!!

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 ET 15

Skeletal Boolean Program Predicates: (locked==0) (locked==1) do //get the write lock SLIC_KeAcquireSpinLock_call(); if (*) then SLIC_KeReleaseSpinLock_call(); fi while (*); We have replaced the calls to acquiring and releasing the lock with calls to an FSM that enforces the locking protocol. Note that this is a boolean program.

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

Shortest Error Path (Acquire 2x) Predicates: (locked==0) (locked==1) do //get the write lock SLIC_KeAcquireSpinLock_call(); if (*) then SLIC_KeReleaseSpinLock_call(); fi while (*); ET 19

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

Error Path in C code do { //get the write lock KeAcquireSpinLock(&devExt->writeListLock); nPacketsOld = nPackets; request = devExt->WLHeadVa; if (request){ KeReleaseSpinLock(&devExt->writeListLock); ... nPackets++; } } while (nPackets != nPacketsOld); Put state machine in picture Fix the colors!!

Newton: Path Simulation Store: nPackets = nPacketsOld; request = devExt->WLHeadVa; assume(!request); assume(nPackets != nPacketsOld); Conditions:

Newton Store: Conditions: nPacketsOld:  nPackets = nPacketsOld; request = devExt->WLHeadVa; assume(!request); assume(nPackets != nPacketsOld); Conditions:

Newton Store: Conditions: nPacketsOld:  nPackets = nPacketsOld; request = devExt->WLHeadVa; assume(!request); assume(nPackets != nPacketsOld); Conditions:

Newton Store: Conditions: nPacketsOld:  nPackets = nPacketsOld; devExt:  nPackets = nPacketsOld; request = devExt->WLHeadVa; assume(!request); assume(nPackets != nPacketsOld); Conditions:

Newton Store: Conditions: nPacketsOld:  nPackets = nPacketsOld; devExt:   ->WLHeadVa:  (3) nPackets = nPacketsOld; request = devExt->WLHeadVa; assume(!request); assume(nPackets != nPacketsOld); Conditions:

Newton Store: Conditions: nPacketsOld:  nPackets:  (1) devExt:   ->WLHeadVa:  (3) request:  (3,4) nPackets = nPacketsOld; request = devExt->WLHeadVa; assume(!request); assume(nPackets != nPacketsOld); Conditions:

Newton Store: Conditions: nPacketsOld:  nPackets:  (1) devExt:   ->WLHeadVa:  (3) request:  (3,4) nPackets = nPacketsOld; request = devExt->WLHeadVa; assume(!request); assume(nPackets != nPacketsOld); Conditions: !  (5)

Newton Store: Conditions: nPacketsOld:  nPackets:  (1) devExt:   ->WLHeadVa:  (3) request:  (3,4) nPackets = nPacketsOld; request = devExt->WLHeadVa; assume(!request); assume(nPackets != nPacketsOld); Conditions: !  (5)  !=  (1,2)

Newton Store: Conditions: nPacketsOld:  nPackets:  (1) devExt:   ->WLHeadVa:  (3) request:  (3,4) nPackets = nPacketsOld; request = devExt->WLHeadVa; assume(!request); assume(nPackets != nPacketsOld); Conditions:  !=  (1,2)

Newton Store: Conditions: nPacketsOld:  nPackets = nPacketsOld; request = devExt->WLHeadVa; assume(!request); assume(nPackets != nPacketsOld); Conditions:  !=  (1,2)

Newton Predicates: (nPacketsOld == ) (nPackets ==  ) ( != ) nPackets = nPacketsOld; request = devExt->WLHeadVa; assume(!request); assume(nPackets != nPacketsOld);

Newton nPackets = nPacketsOld; Predicates: (nPacketsOld != nPackets) request = devExt->WLHeadVa; assume(!request); assume(nPackets != nPacketsOld); Predicates: (nPacketsOld != nPackets)

Newton nPackets = nPacketsOld; Predicates: (nPacketsOld == nPackets) request = devExt->WLHeadVa; assume(!request); assume(nPackets != nPacketsOld); Predicates: (nPacketsOld == nPackets)

Refined Boolean Program Boolean variable b represents the condition (nPacketsOld==nPackets) do //get the write lock SLIC_KeAcquireSpinLock_call(); b := true; // npacketsOld = npackets; if (*) then SLIC_KeReleaseSpinLock_call(); b := b ? false : *; // npackets++; fi while ( !b ); // (nPackets != nPacketsOld); !b b b !b ET 25

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

Demo Lock example Lock example with bug SLAM’s first bug validation error trace SLAM’s first bug floppy device driver ET 28

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 ET 35

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 + Widening (WAIL) X := init; while X  S do X’ := X  F(X) if X’  X then break i := oracle’s guess X := W(i, X’) od return X  S Fixpoint + Widening (WAIL) X := init; while X  S do X’ := X  F(X) if X’  X then break X := X’ od return X  S

Search Space of Widenings

Finite Abstraction + Iterative Refinement 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 X := init; while true do P := atoms(X); X# := lfp(F#P, init) if X#  S then break X := X  F(X) od return X#  S for n iterations, accurate to n steps

Search Space F W F 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 via predicate abstraction of C programs model checking of boolean programs counterexample-driven refinement Implemented and starting to yield results on NT device drivers We summarize, returning to the four points (specification, abstract model, creation, analysis) in the first slide.

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 More features More languages More users 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