1 Towards a Verifying Compiler: The Spec# Approach Wolfram Schulte Microsoft Research Formal Methods 2006 Joint work with Rustan Leino, Mike Barnett, Manuel.

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

1 Lecture 5 Towards a Verifying Compiler: Multithreading Wolfram Schulte Microsoft Research Formal Methods 2006 Race Conditions, Locks, Deadlocks, Invariants,
Hoare-style program verification K. Rustan M. Leino Guest lecturer Rob DeLines CSE 503, Software Engineering University of Washington 26 Apr 2004.
Program Verification using Probabilistic Techniques Sumit Gulwani Microsoft Research Invited Talk: VSTTE Workshop August 2006 Joint work with George Necula.
Verification of object-oriented programs with invariants Mike Barnett, Robert DeLine, Manuel Fahndrich, K. Rustan M. Leino, Wolfram Schulte Formal techniques.
Advanced programming tools at Microsoft
Joint work with Mike Barnett, Robert DeLine, Manuel Fahndrich, and Wolfram Schulte Verifying invariants in object-oriented programs K. Rustan M. Leino.
Copyright © 2003 Pearson Education, Inc. Slide 1 Computer Systems Organization & Architecture Chapters 8-12 John D. Carpinelli.
Extended Static Checking for Java Cormac Flanagan K. Rustan M. Leino Mark Lillibridge Greg Nelson James B. Saxe Raymie Stata Compaq SRC 18 June 2002 PLDI02,
The Spec# programming system K. Rustan M. Leino Microsoft Research, Redmond, WA, USA Lunch seminar, Praxis Bath, UK 6 Dec 2005 joint work with Mike Barnett,
Bor-Yuh Evan Chang Daan Leijen Peter Müller David A. Naumann The Spec# programming system Mike Barnett Rob DeLine Manuel Fähndrich Bart Jacobs K. Rustan.
Demand-driven inference of loop invariants in a theorem prover
Object Invariants in Specification and Verification K. Rustan M. Leino Microsoft Research, Redmond, WA Joint work with: Mike Barnett, Ádám Darvas, Manuel.
Writing specifications for object-oriented programs K. Rustan M. Leino Microsoft Research, Redmond, WA, USA 21 Jan 2005 Invited talk, AIOOL 2005 Paris,
Program Verification Using the Spec# Programming System ETAPS Tutorial K. Rustan M. Leino, Microsoft Research, Redmond Rosemary Monahan, NUIM Maynooth.
Technologies for finding errors in object-oriented software K. Rustan M. Leino Microsoft Research, Redmond, WA Lecture 3 Summer school on Formal Models.
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.
Spec# K. Rustan M. Leino Senior Researcher Programming Languages and Methods Microsoft Research, Redmond, WA, USA Microsoft Research faculty summit, Redmond,
Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Lecture 4 Towards a Verifying Compiler: Data Abstraction Wolfram Schulte Microsoft Research Formal Methods 2006 Purity, Model fields, Inconsistency _____________.
Challenges in increasing tool support for programming K. Rustan M. Leino Microsoft Research, Redmond, WA, USA 23 Sep 2004 ICTAC Guiyang, Guizhou, PRC joint.
1 Program verification: flowchart programs (Book: chapter 7)
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 5.
Chapter 1 Object Oriented Programming 1. OOP revolves around the concept of an objects. Objects are created using the class definition. Programming techniques.
1 Decision Procedures An algorithmic point of view Equality Logic and Uninterpreted Functions.
The Spec# programming system K. Rustan M. Leino Microsoft Research, Redmond, WA, USA Distinguished Lecture Series Max Planck Institute for Software Systems.
25 seconds left…...
Lilian Blot CORE ELEMENTS SELECTION & FUNCTIONS Lecture 3 Autumn 2014 TPOP 1.
Techniques for proving programs with pointers A. Tikhomirov.
User Defined Functions Lesson 1 CS1313 Fall User Defined Functions 1 Outline 1.User Defined Functions 1 Outline 2.Standard Library Not Enough #1.
Synthesis, Analysis, and Verification Lecture 04c Lectures: Viktor Kuncak VC Generation for Programs with Data Structures “Beyond Integers”
Semantics Static semantics Dynamic semantics attribute grammars
Automated Software Verification with a Permission-Based Logic 20 th June 2014, Zürich Malte Schwerhoff, ETH Zürich.
Hoare’s Correctness Triplets Dijkstra’s Predicate Transformers
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 11.
A simple sequential reasoning approach for sound modular verification of mainstream multithreaded programs Wolfram Schulte & Bart Jacobs Microsoft Research.
K. Rustan M. Leino Research in Software Engineering (RiSE) Microsoft Research, Redmond, WA, USA 3 December 2008 U. Lugano Lugano, Switzerland.
ISBN Chapter 3 Describing Syntax and Semantics.
1 Semantic Description of Programming languages. 2 Static versus Dynamic Semantics n Static Semantics represents legal forms of programs that cannot be.
K. Rustan M. Leino Research in Software Engineering (RiSE) Microsoft Research, Redmond, WA part 0 International Summer School Marktoberdorf Marktoberdorf,
Formal Methods of Systems Specification Logical Specification of Hard- and Software Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt.
ECI 2007: Specification and Verification of Object-Oriented Programs Lecture 2 Courtesy: K. Rustan M. Leino and Wolfram Schulte.
Lecture 2 Towards a Verifying Compiler: Logic of Object oriented Programs Wolfram Schulte Microsoft Research Formal Methods 2006 Objects, references, heaps,
ESC Java. Static Analysis Spectrum Power Cost Type checking Data-flow analysis Model checking Program verification AutomatedManual ESC.
K. Rustan M. Leino Research in Software Engineering (RiSE) Microsoft Research, Redmond, WA part 0 Summer School on Logic and Theorem-Proving in Programming.
ECI 2007: Specification and Verification of Object- Oriented Programs Lecture 1.
Building a program verifier K. Rustan M. Leino Microsoft Research, Redmond, WA 10 May 2006 Guest lecture, Shaz Qadeer’s cse599f, Formal Verification of.
K. Rustan M. Leino Microsoft Research, Redmond NUI Maynooth Maynooth, Ireland 8 June 2007.
ESC Java. Static Analysis Spectrum Power Cost Type checking Data-flow analysis Model checking Program verification AutomatedManual ESC.
K. Rustan M. Leino Microsoft Research, Redmond, WA, USA with Mike Barnett, Robert DeLine, Manuel Fahndrich, and Wolfram Schulte Toward enforceable contracts.
Well-cooked Spaghetti: Weakest-Precondition of Unstructured Programs Mike Barnett and Rustan Leino Microsoft Research Redmond, WA, USA.
Describing Syntax and Semantics
Spec# K. Rustan M. Leino Senior Researcher Programming Languages and Methods Microsoft Corporation Joint work with: Mike Barnett, Robert DeLine, Manuel.
Software Engineering Prof. Dr. Bertrand Meyer March 2007 – June 2007 Chair of Software Engineering Static program checking and verification Slides: Based.
Chapter 25 Formal Methods Formal methods Specify program using math Develop program using math Prove program matches specification using.
ISBN Chapter 3 Describing Semantics -Attribute Grammars -Dynamic Semantics.
Specifying and verifying programs in Spec# K. Rustan M. Leino Microsoft Research, Redmond, WA, USA Invited talk, PSI 2006 Novosibirsk, Russia 27 June 2006.
K. Rustan M. Leino Microsoft Research, Redmond, WA, USA 15 Nov 2007 Chalmers Göteborg, Sweden.
Spec# John Lefor Program Manager Developer Division, Microsoft.
1 Verification of object-oriented programs with invariants Mike Barnett, Robert DeLine, Manuel Fahndrich, K. Rustan M. Leino, Wolfram Schulte ECOOP 2003.
CSC3315 (Spring 2009)1 CSC 3315 Languages & Compilers Hamid Harroud School of Science and Engineering, Akhawayn University
Specification techniques for verifying object-oriented software
Weakest Precondition of Unstructured Programs
Further with Hoare Logic Sections 6.12, 6.10, 6.13
Program Verification via an Intermediate Verification Language
Lecture 5 Floyd-Hoare Style Verification
Programming Languages 2nd edition Tucker and Noonan
Hoare-style program verification
Programming Languages 2nd edition Tucker and Noonan
Presentation transcript:

1 Towards a Verifying Compiler: The Spec# Approach Wolfram Schulte Microsoft Research Formal Methods 2006 Joint work with Rustan Leino, Mike Barnett, Manuel Fähndrich, Herman Venter, Rob DeLine, Wolfram Schulte (all MSR), and Peter Müller (ETH), Bart Jacobs (KU Leuven) and Bor-Yuh Evan Chung (Berkley)

2 The Verifying Compiler A verifying compiler uses automated.. reasoning to check the correctness of the program that it compiles. Correctness is specified by types, assertions,.. and other redundant annotations that accompany the program. [Hoare, 2004]

3 Spec# Approach for a Verifying Compiler As source language we use C# As specifications we use method contracts, invariants, and also class, field and type annotations As program logic we use Dijkstras weakest preconditions For automatic verification we use type checking, verification condition generation (VCG) and automatic theorem proving (ATP)

4 Spec#: Research Challenge How to verify object oriented programs and in particular object invariants in the presence of Callbacks Aliasing Inheritance Multi-threading

5 Demo (Spec#)

6 Spec# Tool Architecture Spec# (annotated C#) Boogie PL Spec# Compiler VC Generator Formulas Automatic Theorem Prover

7 Goal of these Lectures Enable participants to Understand and verify Spec# programs Understand and verify Boogie PL programs Build your own verifier [reusing Boogie]

8 Lectures 1.Verification Condition Generation 2.Logic of Object-oriented Programs 3.Invariants and Ownership 4.Abstraction 5.Multithreaded Programs From Boogie PL To Formulas From Spec# To BoogiePL

9 Lecture 1 Verification Condition Generation for Boogie PL Unstructured Code Theories Theorem Provers

10 Boogie PL Source language (eg. Spec#) BoogiePL Formulas Translate source language features using particular programming methodology Translate Boogie PL code using particular VC generation Intermediate language for automatic verification of imperative code

11 Boogie PL: Parts Boogie PL source contains a first order theory to encode the background semantics of the source language and the program, described by constants, functions and axioms an imperative part used to encode the traces of the source program, described by: procedures, pre and postconditions, mutable variables, and unstructured code

12 Limits of Boogie PL Boogie PL does not contain structured control flow structured types a heap expressions with side effects visibility subtyping dynamic dispatch

13 Motivation: Spec#s Conditional to Boogie PL if (Guard) S else T assume Guard; S assume !Guard; T Spec# BoogiePL Then Branch Else Branch

14 Motivation: Spec# sWhile Loops to Boogie PL assert Inv(x) havoc x; assume Inv(x); assume !Guard(x); assume Guard(x); S(x) assert Inv(x) while (Guard(x)) invariant Inv(x) { S(x) } Loop Head Loop Body Loop Exit Loop Pre- decessor Spec# BoogiePL

15 Boogie PL: Code Code is unstructured Code ::= VarDecl* Block+ Block ::= Label: Cmd goto Label+; | return; Cmd ::= Passive | Assign | Call Passive::= assert E | assume E | Cmd ; Cmd Assign ::= id := E | havoc id Call ::= call id := P(E) Variables are (weakly) typed VarDecl ::= var id : Type Type ::= int | bool | Array |… Array ::= [Type+] Type Remark: Types disappear during VCG; they are (if ncessary) encoded as axioms.

16 Boogie PL: Meaning of Code For any command S and predicate Q, which describes the result of executing S, we define another predicate, its weakest precondition, denoted by wp(S,Q), that represents the set of all states such that execution of S begun in any of those states –does not go wrong, and –if it terminates, terminates in Q

17 Verification Condition Generation 1.Passive commands: assert, assume, ; 2.Acyclic control flow: goto (no loops) 3.State changes: :=, havoc 4.Loops 5.Procedure calls

18 VCG 1: Passive Commands assert E - Programmer claims that the condition E holds - Verifier checks E wp( assert E, Q) = E Q assume E - Programmer cares only about executions where E holds - Verifier uses E as an assumption henceforth wp( assume E, Q) = E Q S; T –wp(S; T, E) = wp(S, wp(T, E))

19 VCG 1: Examples wp( assert x>1, Q) = x>1 Q wp( assert true, Q) = Q wp( assume y=x+1, y=5) = (y=x+1 y=5) wp( assume false, Q) = true wp( assert P; assume P, Q) = P (P Q)

20 VCG 1: Assume-Assert Reasoning wp( assume P; S; assert Q, true) = wp( assume P, wp (S, wp( assert Q, true)) = wp( assume P, wp (S, Q)) = P wp(S,Q)

21 VCG 1: Correctness for Procedures (simplified) Let proc M(par) returns (res) requires P, ensures Q and impl M(par) returns (res) { start: S; return; } Then valid (M) = wp (assume P; S; assert Q, true) = P wp(S,Q) We will refine this later.

22 VCG 2: Acyclic Control Flow The problem of redundancy wp(l 0 :S 0 ; goto l 1,..l n, Q) = wp(S 0, wp(l 1 :S 1, Q) … wp(l n :S n, Q)) How can we get a linear (in size of the passive program) formula?

23 VCG 2: Acyclic Control Flow For each block A = L: S goto L B1,..,L Bn introduce a variable A ok, which holds when all executions starting at A are okay. Introduce a Block Equation for each block A (BE A ): A ok wp(S, ( B Succ(A) : B ok )) VC (semantics of entire code): ( A : BE A ) Start ok

24 VCG 3: State Changes The wp for control flow assumes stateless blocks How do we get rid of assignments? (1)Establish dynamic single assignment form (DSA), i.e. there is at most one definition for each variable on each path Replace defs/uses with new incarnations x := x+1 with x n+1 = x n + 1 Replace havoc x with new incarnations x n+1 At join points unify variable incarnations 2)Eliminate assignments by replacing x := E with assume x = E

25 VCG 4: Loops Loops introduce back edges in control flow graph. But technique can only deal with acyclic graphs. How do we get rid of back edges? We showed the result of this transformation earlier in the slide entitled: Spec# sWhile Loops to Boogie PL In detail: 1.Duplicate loop invariant P by using assert P = assert P; assume P 2.Check loop invariant at loop entry and exit 3.Delete back edges after havoc-ing loop targets

26 Declaration proc Find(xs: [int] int, ct: int, x: int) returns (result: int); Implementation impl Find(xs: [int] int, ct: int, x: int) returns (result: int) {…} Call call r := Find(bits, 100, true) Remark: In Boogie PL the keywords are procedure and implementation Boogie PL: Procedures

27 Caller obligations described by Precondition Implementation obligation described by Postcondition proc Find(xs: [int] int, ct: int, x: int) returns (result: int); requires ct0; ensures result 0 result < ct xs[result]=x; ensures result < 0 !( i:int :: 0i i<ct xs[i] == x); A specification spells out the entire contract. Boogie PL: Procedure Specifications

28 var xs: [int] int; var ct: int; proc Find(x: int) returns (result: int); requires ct0; ensures result 0 result < ct xs[result]=x; ensures result < 0 ! ( i:int :: 0i i<ct xs[i] == x); impl Find(x: int) returns (result: int) { start:ct := 0; result := -1; return; } A Bogus Implementation?

29 Postconditions often relate pre-state and post-state –ensures x == old(x)+1; must say which variables x might change –modifies x; variables not mentioned are not allowed to change proc Find(x: int) returns (result: int); … modifies ct; // would allow the previous implementation ensures ct == old(ct); // would disallow the change (despite // modifies clause) More about Postconditions

30 VCG 5: Calls Given proc P(par) returns (res) requires Pre; modifies state; ensures Post; Then wp(call x = P(E), R) = wp( {var par, res; par := E; assert Pre; havoc state; assume Post; x := res }, R) Remark: par and res are assumed to be fresh locals in the method bodys scope

31 VCG 5: Bodies Given proc P(par) returns (res) requires Pre; modifies state; ensures Post; impl P(par) returns (res) {var …; start: S goto … end: return;} Then valid (P) = let (start: S goto … end: S; return;) = Passify(MakeAcyclic (start: assume Pre; S goto … end: assert Post[old(par) par 0 ]; return;) in (start ok wp(S, ( b succs(start) : b ok )) … end ok wp(S, true) start ok ) Remark: assumes that all normal terminations of P terminate at end.

32 BoogiePL: Arrays and Background Boogie s array operations are just a short hand notation, i.e. x := a[i] x := select(a, i) a[i] := E a := store(a, i, E) select and store are defined as (untyped) axioms in Boogies background predicate (m,i,j,v i j select(store(m, i, v), i) = v select(store(m, i, v), j) = select(m, j))

33 Boogie PL: Final VCG Boogie PL has a universal background predicate BP Univ Each Boogie PL program has a local theory BP Prog The generated VC for each procedure implementation P is: BP Univ BP Prog valid(P)

34 Background: Automatic Theorem Provers Usable ATPs have to support first order logic –examples: Simplify, Zap, SMT solvers They are build on Nelson-Oppen cooperating decision procedures and have decision procedures for –congruence closure –linear arithmetic –partial orders –quantifiers Their key features are –automatic: no user interaction –refutation based: searches for counterexamples –heuristics tuned for program checking –Labels and time limit

35 Summary Boogie PL is a simple intermediate language. Boogie supports Modular verification using contracts Linear (in size of the code) VC generation A standard background as well as a program specific one

36 Appendix: VCG Example start: assume x > 100; goto loop; loop: assert x >= 0; goto body, end; body : assume x > 0; x := x - 1; goto loop; end : assume !(x > 0); assert x == 0; return;

37 Create assume start: assume x > 100; goto loop; loop: assert x >= 0; assume x>=0; goto body, end; body : assume x > 0; x := x - 1; goto loop; end : assume !(x > 0); assert x == 0; return;

38 Move loop invariant into Loop-Pre- Header and after Loop Body start: assume x > 100; assert x >= 0; goto loop; loop: assume x>=0; goto body, end; body : assume x > 0; x := x - 1; assert x >= 0; goto loop; end : assume !(x > 0); assert x == 0; return;

39 Cut back jumps: assume havoc on variables assigned inside the loop;block loop body start: assume x > 100; assert x >= 0; goto loop; loop: havoc x; assume x>=0; goto body, end; body : assume x > 0; x := x - 1; assert x >= 0;return; end : assume !(x > 0); assert x == 0; return;

40 Create Dynamic Single Assignment Form start: assume x > 100; assert x >= 0; goto loop; loop: skip assume x1>=0; goto body, end; body : assume x1 > 0; x2 := x1 - 1; assert x2 >= 0;return; end : assume !(x1 > 0); assert x1 == 0; return;

41 Passify Assigments start: assume x > 100; assert x >= 0; goto loop; loop: skip assume x1>=0; goto body, end; body : assume x1 > 0; assume x2 == x1 - 1; assert x2 >= 0;return; end : assume !(x1 > 0); assert x1 == 0; return;

42 Apply Block Translation and wp start x > 100 x >= 0 loop loop x1 >= 0 body end body x1 > 0 x2 = x1 - 1 x2 >= 0 true end !(x1 > 0) x1 = 0 true start