Floyd-Hoare Style Program Verification

Similar documents
Program verification. 18 October 2017

Lecture Notes: Axiomatic Semantics and Hoare-style Verification

Hoare Logic I. Introduction to Deductive Program Verification. Simple Imperative Programming Language. Hoare Logic. Meaning of Hoare Triples

Classical Program Logics: Hoare Logic, Weakest Liberal Preconditions

Deterministic Program The While Program

Deductive Verification

Axiomatic Semantics: Verification Conditions. Review of Soundness and Completeness of Axiomatic Semantics. Announcements

Axiomatic Semantics. Lecture 9 CS 565 2/12/08

Program Analysis Part I : Sequential Programs

Program verification. Hoare triples. Assertional semantics (cont) Example: Semantics of assignment. Assertional semantics of a program

Dynamic Semantics. Dynamic Semantics. Operational Semantics Axiomatic Semantics Denotational Semantic. Operational Semantics

Axiomatic Semantics: Verification Conditions. Review of Soundness of Axiomatic Semantics. Questions? Announcements

Proof Calculus for Partial Correctness

Spring 2015 Program Analysis and Verification. Lecture 4: Axiomatic Semantics I. Roman Manevich Ben-Gurion University

Soundness and Completeness of Axiomatic Semantics

Spring 2016 Program Analysis and Verification. Lecture 3: Axiomatic Semantics I. Roman Manevich Ben-Gurion University

A Short Introduction to Hoare Logic

Axiomatic semantics. Semantics and Application to Program Verification. Antoine Miné. École normale supérieure, Paris year

Hoare Logic (I): Axiomatic Semantics and Program Correctness

Introduction to Axiomatic Semantics

Program verification using Hoare Logic¹

Hoare Logic and Model Checking

Programming Languages and Compilers (CS 421)

Lecture 2: Axiomatic semantics

Formal Methods in Software Engineering

In this episode of The Verification Corner, Rustan Leino talks about Loop Invariants. He gives a brief summary of the theoretical foundations and

Axiomatic Semantics. Hoare s Correctness Triplets Dijkstra s Predicate Transformers

Hoare Calculus and Predicate Transformers

COP4020 Programming Languages. Introduction to Axiomatic Semantics Prof. Robert van Engelen

Axiomatic Semantics. Operational semantics. Good for. Not good for automatic reasoning about programs

CS558 Programming Languages

Axiomatic Semantics. Semantics of Programming Languages course. Joosep Rõõmusaare

Axiomatic Semantics. Stansifer Ch 2.4, Ch. 9 Winskel Ch.6 Slonneger and Kurtz Ch. 11 CSE

Spring 2014 Program Analysis and Verification. Lecture 6: Axiomatic Semantics III. Roman Manevich Ben-Gurion University

Logical Abduction and its Applications in Program Verification. Isil Dillig MSR Cambridge

A Humble Introduction to DIJKSTRA S A A DISCIPLINE OF PROGRAMMING

Hoare Logic: Part II

Logic. Propositional Logic: Syntax

What happens to the value of the expression x + y every time we execute this loop? while x>0 do ( y := y+z ; x := x:= x z )

Hoare Logic: Reasoning About Imperative Programs

Verifying Properties of Parallel Programs: An Axiomatic Approach

Program Analysis and Verification

Spring 2015 Program Analysis and Verification. Lecture 6: Axiomatic Semantics III. Roman Manevich Ben-Gurion University

CSC 7101: Programming Language Structures 1. Axiomatic Semantics. Stansifer Ch 2.4, Ch. 9 Winskel Ch.6 Slonneger and Kurtz Ch. 11.

Probabilistic Guarded Commands Mechanized in HOL

Learning Goals of CS245 Logic and Computation

Verification and Validation

Reasoning About Imperative Programs. COS 441 Slides 10b

The Assignment Axiom (Hoare)

Rodin and refinement

Formal Specification and Verification. Specifications

THE AUSTRALIAN NATIONAL UNIVERSITY Second Semester COMP2600/COMP6260 (Formal Methods for Software Engineering)

COMP2111 Glossary. Kai Engelhardt. Contents. 1 Symbols. 1 Symbols 1. 2 Hoare Logic 3. 3 Refinement Calculus 5. rational numbers Q, real numbers R.

Calculating axiomatic semantics from program equations by means of functional predicate calculus

Design of Distributed Systems Melinda Tóth, Zoltán Horváth

Lectures on Separation Logic. Lecture 2: Foundations

Decision Procedures. Jochen Hoenicke. Software Engineering Albert-Ludwigs-University Freiburg. Winter Term 2016/17

Incremental Proof-Based Verification of Compiler Optimizations

Logic. Propositional Logic: Syntax. Wffs

5. Program Correctness: Mechanics

Softwaretechnik. Lecture 13: Design by Contract. Peter Thiemann University of Freiburg, Germany

Softwaretechnik. Lecture 13: Design by Contract. Peter Thiemann University of Freiburg, Germany

Hoare Logic: Reasoning About Imperative Programs

Complexity and algorithms for monomial and clausal predicate abstraction

Problem Sheet 1: Axiomatic Semantics

Software Engineering

Programming Languages

Verification Frameworks and Hoare Logic

Foundations of Computation

Last Time. Inference Rules

Introduction to Axiomatic Semantics

Weakest Precondition Calculus

CS156: The Calculus of Computation

Marie Farrell Supervisors: Dr Rosemary Monahan & Dr James Power Principles of Programming Research Group

Collecting garbage concurrently (but correctly)

CS156: The Calculus of Computation Zohar Manna Autumn 2008

Hoare Examples & Proof Theory. COS 441 Slides 11

Propositional Logic: Syntax

CSE 331 Winter 2018 Homework 1

Introduction to Turing Machines

CSE 331 Winter 2018 Reasoning About Code I

Predicate Transforms I

Towards a Unified Theory of Operational and Axiomatic Semantics

Formal Verification with Ada 2012

SMT-based Verification of Heap-manipulating Programs

Programming Languages

Horn-ICE Learning for Synthesizing Invariants and Contracts

Proof Rules for Correctness Triples

Coinductive big-step semantics and Hoare logics for nontermination

Proofs of Correctness: Introduction to Axiomatic Verification

Abstract Interpretation from a Topological Perspective

Unifying Theories of Programming

Towards a Unified Theory of Operational and Axiomatic Semantics

Mid-Semester Quiz Second Semester, 2012

SMT and Its Application in Software Verification

«Software verification» The Long-Standing Software Safety and Security Problem. Computer hardware change of scale

Ivy: Safety Verification by Interactive Generalization

First Order Logic vs Propositional Logic CS477 Formal Software Dev Methods

Leonardo de Moura Microsoft Research

Formal Reasoning CSE 331. Lecture 2 Formal Reasoning. Announcements. Formalization and Reasoning. Software Design and Implementation

Transcription:

Floyd-Hoare Style Program Verification Deepak D Souza Department of Computer Science and Automation Indian Institute of Science, Bangalore. 9 Feb 2017

Outline of this talk 1 Overview 2 Hoare Triples 3 Proving assertions 4 Inductive Annotation 5 Weakest Preconditions

Floyd-Hoare Style of Program Verification Robert W. Floyd: Assigning meanings to programs Proceedings of the American Mathematical Society Symposia on Applied Mathematics (1967) C A R Hoare: An axiomatic basis for computer programming, Communications of the ACM (1969).

Floyd-Hoare Logic A way of asserting properties of programs. Hoare triple: {A}P{B} asserts that Whenever program P is started in a state satisfying condition A, if it terminates, it will terminate in a state satisfying condition B. Example assertion: {n 0} P {a = n + m}, where P is the program: int a = m; int x = 0; while (x < n) { a = a + 1; x = x + 1; } Inductive Annotation ( consistent interpretation ) (due to Floyd) A proof system (due to Hoare) for proving such assertions. A way of reasoning about such assertions using the notion of Weakest Preconditions (due to Dijkstra).

Programs as State Transformers View program P as a partial map [P] : Stores Stores. (Assume that Stores = Var Z.) All States State s x 2, y 10, z 3 P y := y + 1; z := x + y State t x 2, y 11, z 13

Predicates on States All States A States satisfying Predicate A Eg. 0 x x < y

Assertion of Partial Correctness {A}P{B} {A}P{B} asserts that Whenever program P is started in a state satisfying condition A, either it will not terminate, or it will terminate in a state satisfying condition B. All States A {10 y} P y := y + 1; z := x + y B {x < z}

Mathematical meaning of a Hoare triple View program P as a relation [P] Stores Stores. so that (s, t) [P] iff it is possible to start P in the state s and terminate in state t. As usual here elements of Stores are maps from variables to integers. [P] is possibly non-determinisitic, in case we also want to model non-deterministic assignment etc. Then the Hoare triple {A} P {B} is true iff for all states s and t: whenever s = A and (s, t) [P], then t = B. In other words Post [P] ([A]) [B].

Example programs and pre/post conditions // Pre: true if (a <= b) min = a; else min = b; // Post: min <= a && min <= b // Pre: 0 <= n int a = m; int x = 0; while (x < n) { a = a + 1; x = x + 1; } // Post: a = m + n

Hoare s view: Program as a composition of statements int a = m; int x = 0; while (x < n) { a = a + 1; x = x + 1; }

Hoare s view: Program as a composition of statements int a = m; int x = 0; while (x < n) { a = a + 1; x = x + 1; } S1: int a = m; S2: int x = 0; S3: while (x < n) { a = a + 1; x = x + 1; } Program is S1;S2;S3

Proof rules of Hoare Logic Axiom of Valid formulas: A provided = A (i.e. A is a valid logical formula, eg. x > 10 = x > 0). Skip: Assignment {A} skip {A} {A[e/x]} x := e {A}

Proof rules of Hoare Logic If-then-else: {P b} S {Q}, {P b} T {Q} {P} if b then S else T {Q} While (here P is called a loop invariant) {P b} S {P} {P} while b do S {P b} Sequencing: Weakening: {P} S {Q}, {Q} T {R} {P} S;T {R} P = Q, {Q} S {R}, R = T {P} S {T }

a = m + n Inductive annotation based proof of a Hoare triple n 0 Annotate each program point i with a predicate A i Successive annotations must be inductive: A i [S i ] = A i+1. Annotation is adequate: Pre = A 1 and A n = Post. Adequate annotation constitutes a proof of {Pre} Prog {Post}. a := m; x := 0 while (x < n) { a := a + 1 x := x + 1 n 0 n 0 a = m a = m + x x

Example of inductive annotation To prove: {y > 10} y := y+1; z := x+y {z > x} y := y + 1 y > 10 y 0 y 1 z := x + y y 1 z = x + y z > x

Weakest Precondition WP(P, B) WP(P, B) is a predicate that describes the exact set of states s such that when program P is started in s, if it terminates it will terminate in a state satisfying condition B. All States A WP(P, B) {10 < y} P y := y + 1; z := x + y; {x < z} B

Exercise: Give weakest preconditions 1 {? } x := x + 2 {x 5}

Exercise: Give weakest preconditions 1 { x 3} x := x + 2 {x 5} 2 {? } if (y < 0) then x := x+1 else x := y {x > 0}

Exercise: Give weakest preconditions 1 { x 3} x := x + 2 {x 5} 2 { (y < 0 x > 1) (y > 0)} if (y < 0) then x := x+1 else x := y {x > 0} 3 {? } while (x 5) do x := x+1 {x = 6}

Exercise: Give weakest preconditions 1 { x 3} x := x + 2 {x 5} 2 { (y < 0 x > 1) (y > 0)} if (y < 0) then x := x+1 else x := y {x > 0} 3 { x 6} while (x 5) do x := x+1 {x = 6}

Exercise: How will you define WP(P, B)? All States WP(P, B) P B

Exercise: How will you define WP(P, B)? All States WP(P, B) P B WP(P, B) = {s t : (s, t) [P] we have t = B}

Using weakest preconditions in inductive proofs Weakest preconditions give us a way to: Check inductiveness of annotations {A i } S i {A i+1 } iff A i = WP(S i, A i+1 ) Reduce the amount of user-annotation needed Programs without loops don t need any user-annotation For programs with loops, user only needs to provide loop invariants

Checking {A} P {B} using WP y := y + 1 y > 10 y > 1 y > 0 z := x + y z > x Check that (y > 10) = WP(P, z > x)

Example proof of add program a := m; n 0 n 0 n 0 a = m x := 0 a = m + x x n while (x < n) { a := a + 1 x := x + 1 a = m + n

is satisfiable. Reducing verification to satisfiability: Generating Verification Conditions To check: {y > 10} y := y + 1; z := x + y; {x < z} Use the weakest precondition rules to generate the verification condition: (y > 10) = (y > 1). Check the verification condition by asking a theorem prover / SMT solver if the formula (y > 10) (y > 1).

What about while loops? Pre: 0 <= n int a = m; int x = 0; while (x < n) { a = a + 1; x = x + 1; } Post: a = m + n

Loop invariants A predicate P is a loop invariant for the while loop: while (b) { S } P if {P b} S {P} holds. If P is a loop invariant then we can infer that: {P} while b do S {P b} S b

Adequate loop invariant What is a good loop invariant for this program? x := 0; while (x < 10) { if (x >= 0) x := x + 1; else x := x 1; } assert(x <= 11);

Adequate loop invariant x := 0; while (x < 10) { if (x >= 0) x := x + 1; else x := x 1; } assert(x <= 11); Canonical Not inv Inv,not ind Inv,ind,not adeq Inv,ind,adeq Invariant 0 x 10 5 x 1 x 0 x 12 0 x 11 5 10 5 10 5 10 5 10 5 10

Adequate loop invariant a := m; x := 0 while (x < n) { a := a + 1 x := x + 1 n 0 n 0 n 0 a = m a = m + x x n An adequate loop invariant needs to satisfy: {n 0} a := m; x := 0 {a = m + x x n}. {a = m + x x n x < n} a := a+1; x := x+1 {a = m + x x n}. {a = m + x x n x n} skip {a = m + n}. Verification conditions are generated accordingly. Note that a = m + x is not an adequate loop invariant. a = m + n

Generating Verification Conditions for a program assume Pre S 1 while (b) { S 2 } invariant Inv The following VCs are generated: Pre [S 1 ] = Inv Or: Pre = WP(S 1, Inv) Inv b [S 2 ] = Inv Or: (Inv b) = WP(S 2, Inv) Inv b [S 3 ] = Post Or: Inv b = WP(S 3, Post) S 3 assert Post

Conclusion Features of this Floyd-Hoare style of verification: Tries to find a proof in the form of inductive annotation. Reduces verification to checking satisfiability of a logical formula Is flexible about predicates, logic used (for example can add quantifiers to reason about arrays). Main challenge is the need for user annotation (adequate loop invariants). Can be increasingly automated (using learning techniques).