Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?

Slides:



Advertisements
Similar presentations
Technologies for finding errors in object-oriented software K. Rustan M. Leino Microsoft Research, Redmond, WA Lecture 1 Summer school on Formal Models.
Advertisements

Technologies for finding errors in object-oriented software K. Rustan M. Leino Microsoft Research, Redmond, WA Lecture 0 Summer school on Formal Models.
Program verification: flowchart programs Book: chapter 7.
Program verification: flowchart programs Book: chapter 7.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 12.
In this episode of The Verification Corner, Rustan Leino talks about Loop Invariants. He gives a brief summary of the theoretical foundations and shows.
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
Copyright , Doron Peled and Cesare Tinelli. These notes are based on a set of lecture notes originally developed by Doron Peled at the University.
Reasoning About Code; Hoare Logic, continued
Hoare’s Correctness Triplets Dijkstra’s Predicate Transformers
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 11.
Formal Semantics of Programming Languages 虞慧群 Topic 5: Axiomatic Semantics.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 13.
David Evans CS655: Programming Languages University of Virginia Computer Science Lecture 19: Minding Ps & Qs: Axiomatic.
Partial correctness © Marcelo d’Amorim 2010.
Axiomatic Semantics The meaning of a program is defined by a formal system that allows one to deduce true properties of that program. No specific meaning.
Copyright © 2006 Addison-Wesley. All rights reserved.1-1 ICS 410: Programming Languages Chapter 3 : Describing Syntax and Semantics Axiomatic Semantics.
ISBN Chapter 3 Describing Syntax and Semantics.
1 Design by Contract Building Reliable Software. 2 Software Correctness Correctness is a relative notion  A program is correct with respect to its specification.
Predicate Transformers
Prof. Necula CS Lecture 91 Theorem Proving CS Lecture 9.
Program Proving Notes Ellen L. Walker.
1 Semantic Description of Programming languages. 2 Static versus Dynamic Semantics n Static Semantics represents legal forms of programs that cannot be.
1/22 Programs : Semantics and Verification Charngki PSWLAB Programs: Semantics and Verification Mordechai Ben-Ari Mathematical Logic for Computer.
CS 355 – Programming Languages
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.
ECI 2007: Specification and Verification of Object- Oriented Programs Lecture 1.
Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 18 Program Correctness To treat programming.
ESC Java. Static Analysis Spectrum Power Cost Type checking Data-flow analysis Model checking Program verification AutomatedManual ESC.
Review: forward E { P } { P && E } TF { P && ! E } { P 1 } { P 2 } { P 1 || P 2 } x = E { P } { \exists … }
Review: forward E { P } { P && E } TF { P && ! E } { P 1 } { P 2 } { P 1 || P 2 } x = E { P } { \exists … }
Software Verification Bertrand Meyer Chair of Software Engineering Lecture 2: Axiomatic semantics.
ECI 2007: Specification and Verification of Object- Oriented Programs Lecture 4.
Describing Syntax and Semantics
Pre/Post Condition Logic 03/06/2013. Agenda Hoare’s Logic Overview Application to Pre/Post Conditions.
1 Inference Rules and Proofs (Z); Program Specification and Verification Inference Rules and Proofs (Z); Program Specification and Verification.
1 Formal Semantics of Programming Languages “Program testing can be used to show the presence of bugs, but never to show their absence!” --Dijkstra.
ISBN Chapter 3 Describing Semantics -Attribute Grammars -Dynamic Semantics.
CS 363 Comparative Programming Languages Semantics.
Chapter 5: Sequences, Mathematical Induction, and Recursion 5.5 Application: Correctness of Algorithms 1 [P]rogramming reliability – must be an activity.
Reasoning about programs March CSE 403, Winter 2011, Brun.
Program Analysis and Verification Spring 2014 Program Analysis and Verification Lecture 4: Axiomatic Semantics I Roman Manevich Ben-Gurion University.
Chapter 3 Part II Describing Syntax and Semantics.
Semantics In Text: Chapter 3.
COP4020 Programming Languages Introduction to Axiomatic Semantics Prof. Robert van Engelen.
1 First order theories (Chapter 1, Sections 1.4 – 1.5) From the slides for the book “Decision procedures” by D.Kroening and O.Strichman.
Static Techniques for V&V. Hierarchy of V&V techniques Static Analysis V&V Dynamic Techniques Model Checking Simulation Symbolic Execution Testing Informal.
Cs7100(Prasad)L18-9WP1 Axiomatic Semantics Predicate Transformers.
1/20 Arrays Changki PSWLAB Arrays Daniel Kroening and Ofer Strichman Decision Procedure.
CSC3315 (Spring 2009)1 CSC 3315 Languages & Compilers Hamid Harroud School of Science and Engineering, Akhawayn University
C HAPTER 3 Describing Syntax and Semantics. D YNAMIC S EMANTICS Describing syntax is relatively simple There is no single widely acceptable notation or.
Zach Tatlock / Winter 2016 CSE 331 Software Design and Implementation Lecture 2 Formal Reasoning.
Reasoning About Code.
Reasoning about code CSE 331 University of Washington.
Formal Methods in Software Engineering 1
Lecture 5 Floyd-Hoare Style Verification
Lecture 2: Axiomatic semantics
Programming Languages and Compilers (CS 421)
Programming Languages 2nd edition Tucker and Noonan
Semantics In Text: Chapter 3.
Formal Methods in software development
Predicate Transformers
Formal Methods in software development
Program correctness Axiomatic semantics
Programming Languages 2nd edition Tucker and Noonan
COP4020 Programming Languages
Presentation transcript:

Automated Theorem Proving Lecture 1

Program verification is undecidable! Given program P and specification S, does P satisfy S?

The model checking approach Create a model of the program in a decidable formalism Verify the model algorithmically Difficulties –Model creation is burden on programmer –The model might be incorrect. If verification fails, is the problem in the model or the program?

The axiomatic approach Add auxiliary specifications to the program to decompose the verification task into a set of local verification tasks Verify each local verification problem Difficulties –Auxiliary spec is burden on programmer –Auxiliary spec might be incorrect. If verification fails, is the problem with the auxiliary specification or the program?

Theorem Proving and Software Meets spec/Found Bug Theorem in a logic Program Specification Semantics VC generation Validity Provability (theorem proving) Soundness: –If the theorem is valid then the program meets specification –If the theorem is provable then it is valid

Overview of the Next Few Lectures From programs to theorems –Verification condition generation From theorems to proofs –Theorem provers –Decision procedures

Programs ! Theorems = Axiomatic Semantics Consists of: –A language for making assertions about programs –Rules for establishing when assertions hold Typical assertions: –During the execution, only non-null pointers are dereferenced –This program terminates with x = 0 Partial vs. total correctness assertions –Safety vs. liveness properties –Usually focus on safety (partial correctness)

Hoare Triples Partial correctness: { A } s { B} –When you start s in any state that satisfies A –If the execution of s terminates –It does so in a state that satisfies B Total correctness: [ A ] s [ B ] –When you start s in any state that satisfies A –The execution of s terminates and –It does so in a state that satisfies B Defined inductively on the structure of statements

Hoare Rules {A} s 1 {C} {C} s 2 {B} { A } s 1 ; s 2 {B} {A Æ E} s 1 {B} {A Æ : E} s 2 {B} {A} if E then s 1 else s 2 {B} {I Æ E} s {I} I Æ : E ) B { I} while E do s {B}

Hoare Rules: Assignment Example: { A } x := x + 2 {x >= 5 }. What is A? General rule: Surprising how simple the rule is ! The key is to compute backwards the precondition from the postcondition Forward rule is more complicated: { B[E/x] } x := E {B} { A } x := E { 9 x. A[x/x] Æ x = E[x/x] }

Weakest preconditions Dijkstras idea: To verify that { A } s { B} a) Let Pre(s, B) = {A | { A} s { B} } b) (Pre(s,B), )) is a lattice - false Pre(s,B) - if Pre(s,B) and Pre(s,B), then Pre(s,B) c) WP(s, B) = lub (Pre(s, B)) d) Compute WP(s, B) and prove A WP(s, B)

Predicate lattice falsetrue ) strong weak Pre(s, B) weakest precondition: WP(s, B) A

Weakest preconditions WP(x := E, B) = B[E/x] WP(s 1 ; s 2, B) = WP(s 1, WP(s 2, B)) WP(if E then s 1 else s 2, B) = E ) WP(s 1, B) Æ : E ) WP(s 2, B) WP(assert E, B) = E B

Example returns c requires true ensures c = a b bool or(bool a, bool b) { if (a) c := true else c := b } Conjecture to be proved: true (a true = a b) ( a b = a b) WP(S, c = a b) = (a true = a b) ( a b = a b) S

Weakest preconditions (Contd.) What about loops? Define a family of weakest preconditions –WP k (while E do S, B) = weakest precondition from which if the loop terminates in k or fewer iterations, then it terminates in B WP 0 = : E ) B WP i+1 = WP i (E ) WP(s, WP i )) WP(while E do S, B) = Æ k ¸ 0 WP k = glb {WP k | k ¸ 0} –Hard to compute –Can we find something easier yet sufficient ?

Not quite weakest preconditions Recall what we are trying to do: falsetrue ) strong weak Pre(s, B) weakest precondition: WP(s, B) A verification condition: VC(s, B) We shall construct a verification condition: VC(s, B) –The loops are annotated with loop invariants ! –VC is guaranteed stronger than WP –But hopefully still weaker than A: A ) VC(s, B) ) WP(s, B)

Verification condition generation Computed in a manner similar to WP Except the rule for while: VC(while I,T E do s, B) = I Æ ( I ((E ) VC(s, I)) Æ ( : E ) B)) )[T 0 /T] I is the loop invariant (provided by the programmer) T is the set of loop targets (can be approximated by scanning the loop body) I holds on entry I is preserved in an arbitrary iteration B holds when the loop terminates

returns c requires b >= 0 ensures c = a + b int add(int a, int b) { int t; t := b c := a invariant t 0 c = a + b - t while (t > 0) { c := c + 1 t := t - 1 } Example Conjecture to be proved: b 0 VC(A, c = a + b) VC(B, t 0 c = a + b - t) t c + 1 = a + b – (t – 1) B L A VC(L, c = a + b) t 0 c = a + b – t (t 0 c = a + b – t t > 0 t c + 1 = a + b – (t - 1) t 0 c = a + b)[c 0 /c,t 0 /t] VC(L, c = a + b) t 0 c = a + b – t (t 0 0 c 0 = a + b – t 0 t 0 > 0 t c = a + b – (t 0 - 1) t 0 0 c 0 = a + b) VC(A, c = a + b) b 0 a = a + b – b (t 0 0 c 0 = a + b – t 0 t 0 > 0 t c = a + b – (t 0 - 1) t 0 0 c 0 = a + b)

Invariants Are Not Easy Consider the following code from QuickSort int partition(int *a, int L 0, int H 0, int pivot) { int L = L 0, H = H 0 ; while(L < H) { while(a[L] < pivot) L ++; while(a[H] > pivot) H --; if(L < H) { swap a[L] and a[H] } L++; } return L } Consider verifying only memory safety What is the loop invariant for the outer loop ?

Verification conditions (Contd.) What about procedure calls? –Annotate each procedure with a precondition pre and a postcondition post –VC(f(), B) = pre (post B)

Program verification Annotate each procedure with a precondition and a postcondition and each loop with an invariant Verify each procedure separately requires pre ensures post f() { S; } Verify that the formula VC(f) pre VC(S, post) is valid

Proving verification conditions What is the decision procedure for proving validity of VC(f)? Depends on the logic in which VC(f) is expressed VC(f) pre VC(S, post)

Verification condition logic Atoms connected by boolean operators –,,, Atoms depend on the program variables and operations on them –boolean, integer, memory Atoms depend on the language of assertions, i.e., program assertions, loop invariants, preconditions and postconditions –quantification, reachability predicate

Assume each assertion is a quantifier-free boolean combination of expressions over program variables. VC(f) is a boolean combination of atoms –Each atom is a relation over terms –Each term is built using functions and logical constants Logical constants are different from program variables –program variables change over time –logical constants are fixed The logical constants in VC(f) refer to the values of program variables at the beginning of f.

Case I: Boolean programs Boolean-valued variables and boolean operations Formula := A | | A Atom := b b SymBoolConst

Example returns c requires true ensures c = a b bool or(bool a, bool b) { if (a) c := true else c := b } Conjecture to be proved: true (a true = a b) ( a b = a b) VC(S, c = a b) = (a true = a b) ( a b = a b) S

Case II: Arithmetic programs In addition, integer-valued variables with affine operations Formula := A | | A Atom := b | t = 0 | t < 0 | t 0 t Term := c | x | t + t | t – t | ct b SymBoolConst x SymIntConst c {…,-1,0,1,…}

returns c requires b >= 0 ensures c = a + b int add(int a, int b) { int t; t := b c := a invariant t 0 c = a + b - t while (t > 0) { c := c + 1 t := t - 1 } Example Conjecture to be proved: b 0 VC(A, c = a + b) VC(B, t 0 c = a + b - t) t c + 1 = a + b – (t – 1) B L A VC(L, c = a + b) t 0 c = a + b – t (t 0 c = a + b – t t > 0 t c + 1 = a + b – (t - 1) t 0 c = a + b)[c 0 /c,t 0 /t] VC(L, c = a + b) t 0 c = a + b – t (t 0 0 c 0 = a + b – t 0 t 0 > 0 t c = a + b – (t 0 - 1) t 0 0 c 0 = a + b) VC(A, c = a + b) b 0 a = a + b – b (t 0 0 c 0 = a + b – t 0 t 0 > 0 t c = a + b – (t 0 - 1) t 0 0 c 0 = a + b)

Case III: Memory programs In addition, a memory with read and write operations –an unbounded set of objects –a finite set of fields in each object –each field contains a boolean value, an integer value, or a reference to an object For each field f, two operations Select and Update –Select(f,o) is the content of the memory at object o and field f –Update(f,o,v) is a new memory obtained by updating field f of object o to v

Memory axioms for all objects o and o, and memories m: o = o Select(Update(m,o,v),o) = v o o Select(Update(m,o,v),o) = Select(m,o)

Modeling memory operations Treat each field f as a map variable: a = b.f a = Select(f,b) a.f = b f = Update(f,a,b) { ? } a.f = 5 { a.f + b.f = 10 } WP(a.f = 5, a.f + b.f = 10) WP(f = Update(f,a,5), Select(f,a) + Select(f,b) = 10) Select(Update(f,a,5),a) + Select(Update(f,a,5),b) = 10

Simplify using memory axiom Select(Update(f,a,5),a) + Select(Update(f,a,5),b) = 10 iff 5 + Select(Update(f,a,5),b) = 10 iff Select(Update(f,a,5),b) = 5 iff a = b 5 = 5 a b Select(f,b) = 5 iff a b Select(f,b) = 5

Formula := A | | A Atom := b | t = 0 | t < 0 | t 0 t Term := c | x | t + t | t – t | ct | Select(m,t) m MemTerm := f | Update(m,t,t) b SymBoolConst x SymIntConst c {…,-1,0,1,…}

Decision procedures Boolean programs –Propositional satisfiability Arithmetic programs –Propositional satisfiability modulo theory of linear arithmetic Memory programs –Propositional satisfiability modulo theory of linear arithmetic + arrays