Specifying and Verifying Device Drivers Wes Weimer George Necula Gregoire Sutre.

Slides:



Advertisements
Similar presentations
Advanced programming tools at Microsoft
Advertisements

Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 18 Program Correctness To treat programming.
Writing specifications for object-oriented programs K. Rustan M. Leino Microsoft Research, Redmond, WA, USA 21 Jan 2005 Invited talk, AIOOL 2005 Paris,
Technologies for finding errors in object-oriented software K. Rustan M. Leino Microsoft Research, Redmond, WA Lecture 1 Summer school on Formal Models.
Technologies for finding errors in object-oriented software K. Rustan M. Leino Microsoft Research, Redmond, WA Lecture 0 Summer school on Formal Models.
Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Challenges in increasing tool support for programming K. Rustan M. Leino Microsoft Research, Redmond, WA, USA 23 Sep 2004 ICTAC Guiyang, Guizhou, PRC joint.
Copyright W. Howden1 Programming by Contract CSE 111 6/4/2014.
De necessariis pre condiciones consequentia sine machina P. Consobrinus, R. Consobrinus M. Aquilifer, F. Oratio.
Abstraction of Source Code (from Bandera lectures and talks)
A Program Transformation For Faster Goal-Directed Search Akash Lal, Shaz Qadeer Microsoft Research.
Compilation 2011 Static Analysis Johnni Winther Michael I. Schwartzbach Aarhus University.
Verifying Executable Object-Oriented Specifications with Separation Logic Stephan van Staden, Cristiano Calcagno, Bertrand Meyer.
Abstraction and Modular Reasoning for the Verification of Software Corina Pasareanu NASA Ames Research Center.
Data-Flow Analysis Framework Domain – What kind of solution is the analysis looking for? Ex. Variables have not yet been defined – Algorithm assigns a.
Hoare’s Correctness Triplets Dijkstra’s Predicate Transformers
1 Symbolic Execution for Model Checking and Testing Corina Păsăreanu (Kestrel) Joint work with Sarfraz Khurshid (MIT) and Willem Visser (RIACS)
1/20 Generalized Symbolic Execution for Model Checking and Testing Charngki PSWLAB Generalized Symbolic Execution for Model Checking and Testing.
Data Abstraction II SWE 619 Software Construction Last Modified, Spring 2009 Paul Ammann.
Concolic Modularity Testing Derrick Coetzee University of California, Berkeley CS 265 Final Project Presentation.
1 Design by Contract Building Reliable Software. 2 Software Correctness Correctness is a relative notion  A program is correct with respect to its specification.
The Software Model Checker BLAST by Dirk Beyer, Thomas A. Henzinger, Ranjit Jhala and Rupak Majumdar Presented by Yunho Kim Provable Software Lab, KAIST.
Formal Methods of Systems Specification Logical Specification of Hard- and Software Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt.
ESC Java. Static Analysis Spectrum Power Cost Type checking Data-flow analysis Model checking Program verification AutomatedManual ESC.
Copyright W. Howden1 Lecture 13: Programming by Contract.
Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 18 Program Correctness To treat programming.
Software Testing and Quality Assurance
CS 267: Automated Verification Lectures 14: Predicate Abstraction, Counter- Example Guided Abstraction Refinement, Abstract Interpretation Instructor:
4/25/08Prof. Hilfinger CS164 Lecture 371 Global Optimization Lecture 37 (From notes by R. Bodik & G. Necula)
Houdini: An Annotation Assistant for ESC/Java Cormac Flanagan and K. Rustan M. Leino Compaq Systems Research Center.
Software Reliability Methods Sorin Lerner. Software reliability methods: issues What are the issues?
OOP #10: Correctness Fritz Henglein. Wrap-up: Types A type is a collection of objects with common behavior (operations and properties). (Abstract) types.
Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 18 Program Correctness To treat programming.
Run-Time Error Handling Wes Weimer, George Necula.
272: Software Engineering Fall 2012 Instructor: Tevfik Bultan Lecture 4: SMT-based Bounded Model Checking of Concurrent Software.
Ranga Rodrigo. Class is central to object oriented programming.
REFACTORING Lecture 4. Definition Refactoring is a process of changing the internal structure of the program, not affecting its external behavior and.
Software Engineering Prof. Dr. Bertrand Meyer March 2007 – June 2007 Chair of Software Engineering Static program checking and verification Slides: Based.
1 Abstraction  Identify important aspects and ignore the details  Permeates software development programming languages are abstractions built on hardware.
1 Inference Rules and Proofs (Z); Program Specification and Verification Inference Rules and Proofs (Z); Program Specification and Verification.
Tammy Dahlgren with Tom Epperly, Scott Kohn, and Gary Kumfert Center for Applied Scientific Computing Common Component Architecture Working Group October.
Aditya V. Nori, Sriram K. Rajamani Microsoft Research India.
CS 261 – Data Structures Preconditions, Postconditions & Assert.
Static Program Analyses of DSP Software Systems Ramakrishnan Venkitaraman and Gopal Gupta.
Reasoning about programs March CSE 403, Winter 2011, Brun.
CSC 480 Software Engineering Design by Contract. Detail Design Road Map Begin with architectural models  Class model: domain classes  Overall state.
COP4020 Programming Languages Introduction to Axiomatic Semantics Prof. Robert van Engelen.
Java Basics Hussein Suleman March 2007 UCT Department of Computer Science Computer Science 1015F.
Formal Verification of Synchronization Issues of SpecC Description with Automatic Abstraction Thanyapat Sakunkonchak Masahiro Fujita Department of Electronics.
David Streader Computer Science Victoria University of Wellington Copyright: David Streader, Victoria University of Wellington Debugging COMP T1.
ANU COMP2110 Software Design in 2003 Lecture 10Slide 1 COMP2110 Software Design in 2004 Lecture 12 Documenting Detailed Design How to write down detailed.
L13: Design by Contract Definition Reliability Correctness Pre- and post-condition Asserts and Exceptions Weak & Strong Conditions Class invariants Conditions.
PROGRAMMING PRE- AND POSTCONDITIONS, INVARIANTS AND METHOD CONTRACTS B MODULE 2: SOFTWARE SYSTEMS 13 NOVEMBER 2013.
Static Techniques for V&V. Hierarchy of V&V techniques Static Analysis V&V Dynamic Techniques Model Checking Simulation Symbolic Execution Testing Informal.
/ PSWLAB Thread Modular Model Checking by Cormac Flanagan and Shaz Qadeer (published in Spin’03) Hong,Shin Thread Modular Model.
1 Exceptions When the Contract is Broken. 2 Definitions A routine call succeeds if it terminates its execution in a state satisfying its contract A routine.
Reasoning and Design (and Assertions). How to Design Your Code The hard way: Just start coding. When something doesn’t work, code some more! The easier.
© Bertrand Meyer and Yishai Feldman Notice Some of the material is taken from Object-Oriented Software Construction, 2nd edition, by Bertrand Meyer (Prentice.
Chapter 3 of Programming Languages by Ravi Sethi
Chapter 6 CS 3370 – C++ Functions.
Accessible Formal Methods A Study of the Java Modeling Language
System Structure and Process Model
Programming Languages 2nd edition Tucker and Noonan
CSC 143 Error Handling Kinds of errors: invalid input vs programming bugs How to handle: Bugs: use assert to trap during testing Bad data: should never.
Java Modeling Language (JML)
The Zoo of Software Security Techniques
Predicate Abstraction
Programming Languages 2nd edition Tucker and Noonan
Programming Languages 2nd edition Tucker and Noonan
Presentation transcript:

Specifying and Verifying Device Drivers Wes Weimer George Necula Gregoire Sutre

Overview Background and Motivation Safety Properties Events and History Registers Driver States Specifications Verification Implementation

Background and Motivation Why bother? PCC-style background –Want a sound analysis Decided on an all-paths analysis –Similar to PREfix, ESC, Slam, Magick –Check pre- and post-conditions, kernel API –But also specify resource management, etc. Greg will recast as model checking later

Safety Properties We aim to verify that … –Allocated resources are freed Over the lifetime of the driver Enforce acquire order: no deadlocks –Kernel functions are called correctly Also includes ordering requirements and obligations, like schedule() and signal_pending(). –Certain minimum actions are performed

Events Three broad types: + allocation, - deallocation, ! event Applied to uninterpreted constructors: irq, dma, memory, schedule And given program values as arguments: +irq(5), -dma(3), !schedule Function call and return may be treated as events

History Register Abstract register used to verify programs –Like the “memory register” in PCC/VCGen –Never appears in user-written code Keeps an ever-increasing list of events –E.g., [ +irq(7) ; !schedule ; +misc(&qpmouse) ] May refer to it in conditions –E.g., PRE(!historyContains(+irq(i)))

Driver States S0: Uninitialized S1: Initialized S2: Opened init_module=0cleanup_module=0 misc_open=0 misc_release=0 misc_read=* misc_write=* Inv(S0) = true Inv(S1) = historyContains(+misc(any))

Driver States (cont’d) Kernel API guarantees a certain state-like behavior for device drivers –E.g., misc_open will only be called if the driver is in S1 We associate an invariant with each state –Captures history register values –And global variables in the driver Must check all paths from S0 to S0. –For resource leaks, etc. –Similar to data-flow analysis

Specifications Write spec in C, just like driver –May use data and control non-determinism –May use pre-conditions: like assert(), but will not fail Spec is minimal –List only things that must be done –Looks like a “template” device driver –Normal device drivers often written by copying others Side-conditions govern optional behavior –Like matching alloc/free –Or checking signals after sleeping

Specification Example int init_module() { /* user code must look like this */ PRE(!historyContains(+misc(any))); switch (__rand_int_range(0,3)) { case 0: misc_register(any); /* use kernel API */ return 0; case 1: return –5; /* EIO */ case 2: return –6; /* ENXIO */ case 3: return –19; /* ENODEV */ }}

Specification Example (2) int misc_fasync(void *fd, void *filp, int on) { PRE(fd != 0 && filp && (on == 1 || on == 0) && current->state == TASK_RUNNING && historyCount(!misc_open) > historyCount(!misc_release)); int retval = fasync_helper(fd, filp, on, any); if (retval < 0) return retval; else return 0; }

Kernel API Spec Model behavior of kernel functions –Like kmalloc(), schedule(), kfree() –May modify history register Example: int request_irq(int i, void *f, …) { PRE(historyCount(+irq(i)) == historyCount(-irq(i)) && implements(f, irq_handler) && …); if (__rand_int_range(0,1)) { return –5; } else { historyAdd(+irq(i)); return 0; } }

Kernel API Spec (2) int kmalloc(int size, int prio) { PRE(size > 0 && size < (128*1024) && (prio & GFP_KERNEL || prio & GFP_ATOMIC) && !(prio & GFP_KERNEL && prio & GFP_ATOMIC)); if (prio & GFP_KERNEL) { int old_state = current->state; current->state = TASK_INTERRUPTIBLE; schedule(); current->state = old_state; historyAdd(!signal_pending); } if (__rand_int_range(0,1) { void *retval = __rand_int_range(1, MAX_INT/4)*4; historyAdd(+memory(retval)); return retval; } else return NULL; }

Side Conditions Used to verify optional behavior –Like resource allocation, scheduling –Conditions on the history register Examples: –Every !schedule must match a !signal_pending –After !must_return(-512), must return –512 –All +irq(…) before any +dma(…) –All +irq(…) occur after !misc_open

Story so far … We have the user source code We have the history register abstraction –Keep track of the past, etc. We have a spec for the user code –Minimal, lists things that must be done We have a spec for the kernel API We have side conditions

Verification When does the user code meet the spec? –Each user function F “matches up” (defined next) with our spec for function F –If the user calls a kernel function with a pre- condition, the condition will always be satisfied –All of the side conditions hold over the life of the device driver

“Matching Up” Can be phrased as a trace inclusion problem –More on that with the next speaker We’ll do it as an all-paths analysis Symbolically execute all paths in user code Keep track of history register Remove +resource(X) and –resource(X) Make sure other important events match

How to Verify Symbolically execute all paths in user code –End up with a set of final states U –Verify pre-conditions, use theorem prover Symbolically execute all paths in spec –End up with a set of final states S For every u  U, find an s  S such that –They have the same return value –Their history registers match up –If s proves T then u proves T (for a few global T’s)

How to Verify: States Start in S0, then check init_module() –Match each final state against the spec –Check all side-conditions in each final state Gather all states R with return value 0 –Their LUB becomes the invariant for S1 –Analyze all paths out of S1 (= symbolically execute those functions with that invariant) Repeat until this terminates.

What can go wrong? User code can call a kernel function and fail to meet the pre-condition User code can fail to meet a side condition User code can fail to match up to the spec If so, report an error! And hope that it’s not a false positive.

Loop Invariants Used in symbolic execution to model loops Currently, we guess “true” –or use any other heuristic (e.g., on “for” loops) Except for the history register Gather all history changes in the loop body Add a special history element: X_copies_of(history_element_list)

Does it work? Sample implementation Tested on init_module() in 46 misc device drivers (about 300k post-processed each) 30 successful terminations (25 meet spec) –Others look fine, spec needs to be refined 16 “no answer after 45 seconds” –All-paths analysis is expensive: O(2 n )

Conclusions and Future Work Method for specifying and verifying –Spec looks like original code –Sound, incomplete, expensive –Uses abstract events Captures allocation, function ordering, other API and behavioral restrictions Next steps: –folding similar paths –handling concurrency (e.g., irq handlers)