Verifying Regular Behavior of C modules Sagar Chaki, Edmund Clarke, Alex Groce, CMU Somesh Jha, Wisconsin.

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 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?
Abstraction in Model Checking Nishant Sinha. Model Checking Given a: –Finite transition system M –A temporal property p The model checking problem: –Does.
Abstraction of Source Code (from Bandera lectures and talks)
Verification of Evolving Software Natasha Sharygina Joint work with Sagar Chaki and Nishant Sinha Carnegie Mellon University.
Abstraction and Modular Reasoning for the Verification of Software Corina Pasareanu NASA Ames Research Center.
Model-based reasoning meets code verification Michael Butler 21 May 2014 WG 2.3 Meeting 55, Orlando.
Lecture #21 Software Model Checking: predicate abstraction Thomas Ball Testing, Verification and Measurement Microsoft Research.
Chair of Software Engineering Software Verification Stephan van Staden Lecture 10: Model Checking.
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.
Specifying and Verifying Device Drivers Wes Weimer George Necula Gregoire Sutre.
Using Statically Computed Invariants Inside the Predicate Abstraction and Refinement Loop Himanshu Jain Franjo Ivančić Aarti Gupta Ilya Shlyakhter Chao.
A … Framework for Verifying Concurrent C Programs Sagar Chaki Thesis Defense Talk.
State-Event Software Verification for Branching-Time Specifications Sagar Chaki, Ed Clarke, Joel Ouaknine, Orna Grumberg Natasha Sharygina, Tayssir Touili,
Lazy Abstraction Thomas A. Henzinger Ranjit Jhala Rupak Majumdar Grégoire Sutre UC Berkeley.
Scalable Error Detection using Boolean Satisfiability 1 Yichen Xie and Alex Aiken Stanford University.
Synergy: A New Algorithm for Property Checking
Secrets of Software Model Checking Thomas Ball Sriram K. Rajamani Software Productivity Tools Microsoft Research
1 Predicate Abstraction of ANSI-C Programs using SAT Edmund Clarke Daniel Kroening Natalia Sharygina Karen Yorav (modified by Zaher Andraus for presentation.
Developing Verifiable Concurrent Software Tevfik Bultan Department of Computer Science University of California, Santa Barbara
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.
1 Eran Yahav and Mooly Sagiv School of Computer Science Tel-Aviv University Verifying Safety Properties.
Race Checking by Context Inference Tom Henzinger Ranjit Jhala Rupak Majumdar UC Berkeley.
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.
Verifying Commit-Atomicity Using Model Checking Cormac Flanagan University of California, Santa Cruz.
Efficient Software Model Checking of Data Structure Properties Paul T. Darga Chandrasekhar Boyapati The University of Michigan.
Word Level Predicate Abstraction and Refinement for Verifying RTL Verilog Himanshu Jain Daniel Kroening Natasha Sharygina Edmund Clarke Carnegie Mellon.
Lazy Abstraction Tom Henzinger Ranjit Jhala Rupak Majumdar Grégoire Sutre.
Formal Verification of SpecC Programs using Predicate Abstraction Himanshu Jain Daniel Kroening Edmund Clarke Carnegie Mellon University.
Automated Tools for Software Reliability Suhabe Bugrara Stanford University.
Grand Challenge Problem: Model Check Concurrent Software Edmund M. Clarke Department of Computer Science Carnegie Mellon University.
Cheng/Dillon-Software Engineering: Formal Methods Model Checking.
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,
Verification of Java Programs using Symbolic Execution and Loop Invariant Generation Corina Pasareanu (Kestrel Technology LLC) Willem Visser (RIACS/USRA)
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.
Survey on Trace Analyzer (2) Hong, Shin /34Survey on Trace Analyzer (2) KAIST.
Dynamic Component Substitutability Analysis Edmund Clarke Natasha Sharygina* Nishant Sinha Carnegie Mellon University The University of Lugano.
Race Checking by Context Inference Tom Henzinger Ranjit Jhala Rupak Majumdar UC Berkeley.
Automatic Verification of Finite-State Concurrent Systems Using Temporal Logic Specifications 1.
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
Formal Verification Lecture 9. Formal Verification Formal verification relies on Descriptions of the properties or requirements Descriptions of systems.
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.
1 Predicate Abstraction and Refinement for Verifying Hardware Designs Himanshu Jain Joint work with Daniel Kroening, Natasha Sharygina, Edmund M. Clarke.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
11 Counter-Example Based Predicate Discovery in Predicate Abstraction Satyaki Das and David L. Dill Computer Systems Lab Stanford University
Model Checking for Simple Java Programs Taehoon Lee, Gihwon Kwon Department of Computer Science Kyonggi University, Korea IWFST, Shanghai, China,
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
CHARME’03 Predicate abstraction with Minimum Predicates Sagar Chaki*, Ed Clarke*, Alex Groce*, Ofer Strichman** * Carnegie Mellon University ** Technion.
Compositional Verification part II Dimitra Giannakopoulou and Corina Păsăreanu CMU / NASA Ames Research Center.
Verifying Component Substitutability Nishant Sinha Sagar Chaki Edmund Clarke Natasha Sharygina Carnegie Mellon University.
Principles of Programming & Software Engineering
Presentation Title 2/4/2018 Software Verification using Predicate Abstraction and Iterative Refinement: Part Bug Catching: Automated Program Verification.
Over-Approximating Boolean Programs with Unbounded Thread Creation
Threads and Memory Models Hal Perkins Autumn 2009
Arrays .
Abstractions from Proofs
Abstraction, Verification & Refinement
Predicate Abstraction
Course: CS60030 Formal Systems
Presentation transcript:

Verifying Regular Behavior of C modules Sagar Chaki, Edmund Clarke, Alex Groce, CMU Somesh Jha, Wisconsin

Regular Behavior Expressed as Finite Labeled Transition Systems (FLTS) -Locking protocols We use the FSP syntax to describe FLTSs -Concurrency: State Models and Java Programs – Jeff Magee, Jeff Kramer - Wiley

Regular Behavior: LockUnlock U = (lock -> L | return -> S), L = (unlock -> U). UL lock unlock S return

C Module: PCI device driver void example() { do { KeAcquireSpinLock();//event lock nPackets = nPacketsOld; if(cond) { KeReleaseSpinLock();//event unlock nPackets++; } } while(nPackets != nPacketsOld); KeReleaseSpinLock();//event unlock }

Our Goal To show that LockUnlock simulates the PCI driver -Need to keep track of the predicate (nPackets == nPacketsOld) -Flow-insensitive analysis will fail Provide diagnostic feedback in case the simulation does not exist

POSIX pthread Spec pthread_mutex_lock() -Acquires lock and returns 0 -Increments user count on lock and returns 0 -Returns non-zero error code U U U U ret_err ret_zero lock inc_count

Glibc pthread source code int pthread_mutex_lock() { case PTHREAD_MUTEX_RECURSIVE_NP: self = thread_self(); if (mutex->__m_owner == self) { mutex->__m_count++;//inc_count return 0;//ret_zero } pthread_lock(&mutex->__m_lock, self);//lock mutex->__m_owner = self; mutex->__m_count = 0; return 0; }//ret_zero

C module Collection of C procedure definitions -The pthread library Designated main procedure -The pthread_mutex_lock function -We are interested in behavior observed during an invocation of main

C module For each procedure called, one of two things must be available -Definition of procedure -Information about behavior observed during invocation of procedure

Verification Check that every possible behavior of main is also a behavior of the FLTS -Trace-containment In practice it is sufficient to check for a stronger condition viz. simulation -FLTS ≥ main

FLTS: Definition Fix an alphabet: Σ -Assume Σ contains special symbol ε Three-tuple: -Q: finite set of states -I: initial state -δ: transition relation over Q X Σ X Q

Example U’ L’ lock S’ return V’ ε M’ ε unlock

Simulation FLTSs:, Relation ≥ Q1 X Q2 is simulation if (1)Init: For all t Є I2 exists s Є I1 s.t. s ≥ t (2)Step: s ≥ t and (t,a,t’) Є δ2 => exists s’ s.t. (s,a,s’) Є δ1 and s’ ≥ t’ (3)Stutter: s ≥ t and (t,ε,t’) Є δ2 => s ≥ t’ OR exists s’ s.t. (s,ε,s’) Є δ1 and s’ ≥ t’

Overall method Step 1: Compute relation R that satisfies conditions 2 and 3 Step 2: Check that R satisfies condition 1 as well

Step 1 Start with R = Q1 X Q2 Iteratively refine R using condition 2 and 3 till a fixed point is reached -If (s,t) Є R and if (t,a,t’) Є δ2 then remove (s,t) if there does not exist s’ s.t. (s,a,s’) Є δ1 and (s’,t’) Є R

Example U’ L’ lock S’ return V’ ε M’ ε unlock {U,L,S} lock UL unlock S return

Example U’ L’ lock S’ return V’ ε M’ ε unlock {U} {U,L,S} lock UL unlock S return

Example U’ L’ lock S’ return V’ ε M’ ε unlock {U} {U,L,S} lock UL unlock S return

Example U’ L’ lock S’ return V’ ε M’ ε unlock {U} {U,L,S} {L} {U,L,S} lock UL unlock S return

Example U’ L’ lock S’ return V’ ε M’ ε unlock {U} {L} {U,L,S} lock UL unlock S return

FLTS from C module Based on a set of predicates Each state of the FLTS consists of a control location of the C module and a valuation to the predicates -Non-context-sensitive Weakest preconditions and theorem proving are used to compute the transitions on-the-fly

Predicates and Property Need to specify predicates to be used -predicate (nPackets == nPacketsOld); Need to specify the simulation relation to be checked -property U simulates example;

Additional Info Specify that call to KeAcquireSpinLock() represents a locking action -action call KeAcquireSpinLock = lock; Similarly for KeReleaseSpinLock() -action call KeReleaseSpinLock = unlock;

Related Work Based on predicate abstraction -Graf & Saidi, Dill et. al. Do not work with C -SLAM, Bandera Specify desired behavior as patterns, or unwanted behavior as monitors -Engler et. al., SLAM, Bandera

Challenges Extract event information from C code Provide diagnostic feedback in case simulation is not found Pointers and dynamic memory allocation Introduce context-sensitivity Introduce concurrency

Major Differences Unlike Engler et. al. -Flow-sensitive, based on predicates -Check arbitrary regular behavior Unlike SLAM -On-the-fly: no boolean programs -Not context-sensitive Unlike Bandera -Work with C -Check arbitrary regular behavior