Automatically Validating Temporal Safety Properties of Interfaces Thomas Ball and Sriram K. Rajamani Software Productivity Tools, Microsoft Research Presented.

Slides:



Advertisements
Similar presentations
1 Verification by Model Checking. 2 Part 1 : Motivation.
Advertisements

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,
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?
Verification of Evolving Software Natasha Sharygina Joint work with Sagar Chaki and Nishant Sinha Carnegie Mellon University.
Bebop: A Symbolic Model Checker for Boolean Programs Thomas Ball Sriram K. Rajamani
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.
Proofs from Tests Nels E. Beckman Aditya V. Nori Sriram K. Rajamani Robert J. Simmons Carnegie Mellon UniversityMicrosoft Research India Carnegie Mellon.
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.
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.
Permissive Interfaces Tom Henzinger Ranjit Jhala Rupak Majumdar.
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
Model Checking. Used in studying behaviors of reactive systems Typically involves three steps: Create a finite state model (FSM) of the system design.
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.
CS 267: Automated Verification Lectures 14: Predicate Abstraction, Counter- Example Guided Abstraction Refinement, Abstract Interpretation Instructor:
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.
From last time S1: l := new Cons p := l S2: t := new Cons *p := t p := t l p S1 l p tS2 l p S1 t S2 l t S1 p S2 l t S1 p S2 l t S1 p L2 l t S1 p S2 l t.
Lazy Abstraction Tom Henzinger Ranjit Jhala Rupak Majumdar Grégoire Sutre.
Automatic Predicate Abstraction of C Programs Thomas BallMicrosoft Rupak MajumdarUC Berkeley Todd MillsteinU Washington Sriram K. RajamaniMicrosoft
Formal verification Marco A. Peña Universitat Politècnica de Catalunya.
Formal Verification of SpecC Programs using Predicate Abstraction Himanshu Jain Daniel Kroening Edmund Clarke Carnegie Mellon University.
Lazy Abstraction Lecture 3 : Partial Analysis Ranjit Jhala UC San Diego With: Tom Henzinger, Rupak Majumdar, Ken McMillan, Gregoire Sutre.
Thread-modular Abstraction Refinement Thomas A. Henzinger, et al. CAV 2003 Seonggun Kim KAIST CS750b.
Cheng/Dillon-Software Engineering: Formal Methods Model Checking.
50.530: Software Engineering
Software Engineering Prof. Dr. Bertrand Meyer March 2007 – June 2007 Chair of Software Engineering Static program checking and verification Slides: Based.
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.
Survey on Trace Analyzer (2) Hong, Shin /34Survey on Trace Analyzer (2) KAIST.
Inferring Specifications to Detect Errors in Code Mana Taghdiri Presented by: Robert Seater MIT Computer Science & AI Lab.
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.
Lazy Abstraction Jinseong Jeon ARCS, KAIST CS750b, KAIST2/26 References Lazy Abstraction –Thomas A. Henzinger et al., POPL ’02 Software verification.
Automatically Validating Temporal Safety Properties of Interfaces Thomas Ball, Sriram K. MSR Presented by Xin Li.
Convergence of Model Checking & Program Analysis Philippe Giabbanelli CMPT 894 – Spring 2008.
Localization and Register Sharing for Predicate Abstraction Himanshu Jain Franjo Ivančić Aarti Gupta Malay Ganai.
SLAM internals Sriram K. Rajamani Rigorous Software Engineering Microsoft Research, India.
The Yogi Project Software property checking via static analysis and testing Aditya V. Nori, Sriram K. Rajamani, Sai Deep Tetali, Aditya V. Thakur Microsoft.
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.
Deriving formal specifications (almost) automatically Glenn Ammons and Ras Bodik and James R. Larus.
#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
50.530: Software Engineering
Predicate Abstraction
Course: CS60030 Formal Systems
Presentation transcript:

Automatically Validating Temporal Safety Properties of Interfaces Thomas Ball and Sriram K. Rajamani Software Productivity Tools, Microsoft Research Presented for CMSC631 by Iulian Neamtiu

2 Goal: Validate temporal safety properties using model checking SLAM Project, Microsoft Research

3

4 Motivation Large-scale software – many components, many programmers Integration testing Impossible Ineffective at best Fuzzy requirements -> inconsistent implementation Consistent requirements -> inconsistent implementation (Jim Larus)

5 SLAM Approach Modules interact properly… If program observes temporal safety properties of interfaces it uses temporal safety = properties whose violation is witnessed by a finite execution trace, i.e. path to ERROR state State temporal safety properties formally Automatic verification Interface compliance checked statically (catch bugs early)

6 SLAM Process prog. P’ prog. P SLIC rule boolean program path predicates slic C2BP BEBOP NEWTON Language for specifying safety properties Generate abstract boolean program from C code Model checker Predicate discoverer

7 SLAM - formally 1. P’ a C program, E i ={e 1,e 2,…,e n } a set of predicates, apply C2BP to create a boolean program BP(P’,E i ) 2. Apply BEBOP to check whether exists a path p i in BP(P’,E i ) that reaches ERROR state if p i not found, terminate with SUCCESS if p i found go to 3 3. Use NEWTON to check p i feasible If p i feasible, terminate with FAILURE If p i not feasible find set F i of predicates that explains infeasibility 4. E i+1 = E i UF i+1, i=i+1, go to 1

8 Example – device driver do { KeAcquireSpinLock(); nPacketsOld = nPackets; if(request){ request = request->Next; KeReleaseSpinLock(); nPackets++; } } while (nPackets != nPacketsOld); KeReleaseSpinLock(); Prove safety – “something bad does not happen” (lock acquired/released twice)

9 Step 0 – Property Specification typedef {Locked, Unlocked} STATETYPE; typedef {Acq, Rel} MTYPE; STATETYPE state = Unlocked; FSM(m : MTYPE){ if ((state==Unlocked) && (m==Acq)) A: state = Locked; else if ((state==Locked) && (m==Rel)) B: state = Unlocked; else ERROR: ; } SLIC Specification = FSM Global state State transitions (events)

10 Instrumented Program P’ Step 1 - Instrumentation do { KeAcquireSpinLock(); C: FSM(Acq); nPacketsOld = nPackets; if(request){ request = request->Next; KeReleaseSpinLock(); D: FSM(Rel); nPackets++; } E:E: } while (nPackets != nPacketsOld); KeReleaseSpinLock(); F: FSM(Rel); typedef {Locked, Unlocked} STATETYPE; typedef {Acq, Rel} MTYPE; STATETYPE state = Unlocked; FSM(m : MTYPE){ if ((state==Unlocked) && (m==Acq)) A: state = Locked; else if ((state==Locked) && (m==Rel)) B: state = Unlocked; else ERROR: ; } Program PSLIC Specification

11 Step 0 - Specification Step 1 - Instrumentation Step 2 - Abstraction Step 3 - Model Checking Step 4 - Theorem Proving Step 5 – Predicate discovery Outline manual automated

12 Abstraction Abstract Interpretation In C program P set of predicates E={e 1,e 2,…,e n } Out abstract boolean program BP(P,E) with n boolean variables V={b 1,b 2,…,b n } Boolean program (C-like) all vars have type bool control nondeterminism (*) only call by value

13 Step 2 – Abstraction (C2BP) typedef {Locked, Unlocked} STATETYPE; typedef {Acq, Rel} MTYPE; STATETYPE state = Unlocked; FSM(m : MTYPE){ if ((state==Unlocked) && (m==Acq)) A: state = Locked; else if ((state==Locked) && (m==Rel)) B: state = Unlocked; else ERROR: ; } decl {state==Locked, state==Unlocked}; void FSM({m==Acq,m==Rel}){ if ({state==Unlocked} & {m==Acq}) A: {state==Locked, state==Unlocked }:=1,0 ; else if ({state==Locked} & {m==Rel}) B: {state==Locked, state==Unlocked }:=0,1; else ERROR: ; }

14 Instrumented Program P’ Step 2 – Abstraction (C2BP) do { KeAcquireSpinLock(); C: FSM(Acq); nPacketsOld = nPackets; if(request){ request = request->Next; KeReleaseSpinLock(); D: FSM(Rel); nPackets++; } E: } while (nPackets != nPacketsOld); KeReleaseSpinLock(); F: FSM(Rel); Boolean Program BP(P’,E 0 ) do { skip; C: FSM(1,0); skip; if(*){ skip; D: FSM(0,1); skip; } E: } while (*); skip; F: FSM(0,1);

15 Step 3 - Model Checking (BEBOP) Boolean Program BP(P’,E 0 ) do { skip; C: FSM(1,0); skip; if(*){ skip; D: FSM(0,1); skip; } E: } while (*); skip; F: FSM(0,1); decl {state==Locked, state==Unlocked}; void FSM({m==Acq,m==Rel}){ if ({state==Unlocked} & {m==Acq}) A: {state==Locked, state==Unlocked }:=1,0 ; else if ({state==Locked} & {m==Rel}) B: {state==Locked, state==Unlocked }:=0,1; else ERROR: ; } Is there a path that leads to ERROR ?YES [C,A,E,C,ERROR ]

16 do { KeAcquireSpinLock(); C: FSM(Acq); nPacketsOld = nPackets; if(request){ request = request->Next; KeReleaseSpinLock(); D: FSM(Rel); nPackets++; } E: } while (nPackets != nPacketsOld); KeReleaseSpinLock(); F: FSM(Rel); Step 4 – Theorem Proving (NEWTON) typedef {Locked, Unlocked} STATETYPE; typedef {Acq, Rel} MTYPE; STATETYPE state = Unlocked; FSM(m : MTYPE){ if ((state==Unlocked) && (m==Acq)) A: state = Locked; else if ((state==Locked) && (m==Rel)) B: state = Unlocked; else ERROR: ; } Is path [C,A,E,C] feasible ?NO // nPacketsOld==nPackets, nPacketsOld != nPackets

17 Step 5 – Predicate Discovery (NEWTON) b: {nPackets == nPacketsOld}; do { skip; b:=1; C: FSM(1,0); skip; if(*){ skip; D: FSM(0,1); skip; b:=0; } E: } while (!b); skip; F: FSM(0,1); do { skip; C: FSM(1,0); skip; if(*){ skip; D: FSM(0,1); skip; } E: } while (*); skip; F: FSM(0,1); Boolean Program BP(P’,E 0 )Boolean Program BP(P’,E 1 )

18 Step 3 - Model Checking (BEBOP) do { skip; b:=1; C: FSM(1,0); skip; if(*){ skip; D: FSM(0,1); skip; b:=0; } E: } while (!b); skip; F: FSM(0,1); decl {state==Locked, state==Unlocked}; decl b: {nPackets==nPacketsOld}; void FSM({m==Acq,m==Rel}){ if ({state==Unlocked} & {m==Acq}) A: {state==Locked, state==Unlocked }:=1,0 ; else if ({state==Locked} & {m==Rel}) B: {state==Locked, state==Unlocked }:=0,1; else ERROR: ; } Is there a path that leads to ERROR ?NO

19 C2BP From a C program P and a set of predicates E={e 1,e 2,…,e n } create an abstract boolean program BP(P,E) which has n boolean variables V={b 1,b 2,…,b n } Determine for each statement s in P and predicate e i in E how the execution of s can affect the truth value of e i if it doesn’t, s->skip

20 C2BP cont’d Static analysis alias logical model: p, p+i same object interprocedural side-effects (conservative)

21 BEBOP Essentially a model checker Interprocedural dataflow analysis -> reachable states Uses BDDs to represent state/transfer functions ERROR state reachability reduces to vertex reachability on the CFG of the boolean program BP which is decidable

22 NEWTON Predicate discoverer / Theorem prover walk error path p found by BEBOP compute conditions (predicate values) along p if algorithm terminates inconsistence detected (  =!  ), add  to list of predicates, repeat whole process else report p as witness

23 Results NT device drivers Max LOC <10 user-supplied predicates, tens-hundreds inferred < iterations 672 runs daily, 607 terminate within 20 minutes

24 SLAM vs Metacompilation (Engler et al.) SLAMMetacompilation SpecificationSLICmetal Sound Complete Scalability (LOC)10,0001,000,000 Refinement Spurious errorsVery FewMany

25 Conclusions SLAM = process for checking temporal safety properties Formally state safety properties that interface clients must observe Fully automated validation (iterative refinement) Sound; if process terminates either SUCCESS or FAILURE (w/counterexample) reported Accurate (few false positives) - Poor scalability

Thank You Questions ?

27 Complexity O(|P| x 2 |E| ) worst case In practice O(|E| 3 )

28 SLAM = A collection of tools SLIC Language for specifying safety properties C2BP Generate abstract boolean program from C code BEBOP Model checking boolean programs NEWTON Theorem prover Refine boolean program

29