Spring 2016 Program Analysis and Verification

Slides:



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

Semantics Static semantics Dynamic semantics attribute grammars
ICE1341 Programming Languages Spring 2005 Lecture #6 Lecture #6 In-Young Ko iko.AT. icu.ac.kr iko.AT. icu.ac.kr Information and Communications University.
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.
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.
Predicate Transformers
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.
Program Analysis and Verification Spring 2014 Program Analysis and Verification Lecture 5: Axiomatic Semantics II Roman Manevich Ben-Gurion University.
CS 355 – Programming Languages
Programming Language Semantics Axiomatic Semantics Chapter 6.
CSE115/ENGR160 Discrete Mathematics 04/12/11 Ming-Hsuan Yang UC Merced 1.
1 Operational Semantics Mooly Sagiv Tel Aviv University Textbook: Semantics with Applications.
Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 18 Program Correctness To treat programming.
Software Verification Bertrand Meyer Chair of Software Engineering Lecture 2: Axiomatic semantics.
Describing Syntax and Semantics
Program Analysis and Verification Noam Rinetzky Lecture 3: Axiomatic Semantics 1 Slides credit: Roman Manevich, Mooly Sagiv, Eran Yahav.
Program Analysis and Verification
Reading and Writing Mathematical Proofs
Program Analysis and Verification Spring 2015 Program Analysis and Verification Lecture 2: Operational Semantics I Roman Manevich Ben-Gurion University.
CSI 3125, Axiomatic Semantics, page 1 Axiomatic semantics The assignment statement Statement composition The "if-then-else" statement The "while" statement.
CS 363 Comparative Programming Languages Semantics.
Program Analysis and Verification
Program Analysis and Verification Spring 2014 Program Analysis and Verification Lecture 4: Axiomatic Semantics I Roman Manevich Ben-Gurion University.
Semantics In Text: Chapter 3.
Program Analysis and Verification Spring 2015 Program Analysis and Verification Lecture 12: Abstract Interpretation IV Roman Manevich Ben-Gurion University.
COP4020 Programming Languages Introduction to Axiomatic Semantics Prof. Robert van Engelen.
13 Aug 2013 Program Verification. Proofs about Programs Why make you study logic? Why make you do proofs? Because we want to prove properties of programs.
Program Analysis and Verification Spring 2015 Program Analysis and Verification Lecture 4: Axiomatic Semantics I Roman Manevich Ben-Gurion University.
Principle of Programming Lanugages 3: Compilation of statements Statements in C Assertion Hoare logic Department of Information Science and Engineering.
Program Analysis and Verification Spring 2015 Program Analysis and Verification Lecture 13: Abstract Interpretation V Roman Manevich Ben-Gurion University.
Compiler Principles Fall Compiler Principles Lecture 7: Lowering Correctness Roman Manevich Ben-Gurion University of the Negev.
Operational Semantics Mooly Sagiv Tel Aviv University Textbook: Semantics with Applications Chapter.
Cs7100(Prasad)L18-9WP1 Axiomatic Semantics Predicate Transformers.
CSC3315 (Spring 2009)1 CSC 3315 Languages & Compilers Hamid Harroud School of Science and Engineering, Akhawayn University
Program Analysis and Verification
Operational Semantics Mooly Sagiv Tel Aviv University Sunday Scrieber 8 Monday Schrieber.
Program Analysis and Verification Spring 2014 Program Analysis and Verification Lecture 8: Static Analysis II Roman Manevich Ben-Gurion University.
Operational Semantics Mooly Sagiv Reference: Semantics with Applications Chapter 2 H. Nielson and F. Nielson
Operational Semantics Mooly Sagiv Reference: Semantics with Applications Chapter 2 H. Nielson and F. Nielson
Program Analysis and Verification Spring 2014 Program Analysis and Verification Lecture 6: Axiomatic Semantics III Roman Manevich Ben-Gurion University.
Program Analysis and Verification Spring 2015 Program Analysis and Verification Lecture 8: Static Analysis II Roman Manevich Ben-Gurion University.
Program Analysis and Verification Spring 2016 Program Analysis and Verification Lecture 5: Axiomatic Semantics II Roman Manevich Ben-Gurion University.
Spring 2017 Program Analysis and Verification
Spring 2017 Program Analysis and Verification
Spring 2016 Program Analysis and Verification
Spring 2017 Program Analysis and Verification
Warm-up exercises Define program state: Define state predicate:
Formal Methods in Software Engineering 1
Program Analysis and Verification
Spring 2017 Program Analysis and Verification Operational Semantics
Lecture 5 Floyd-Hoare Style Verification
Program Analysis and Verification
Axiomatic semantics Points to discuss: The assignment statement
Programming Languages and Compilers (CS 421)
Programming Languages 2nd edition Tucker and Noonan
Semantics In Text: Chapter 3.
Predicate Transformers
Axiomatic Semantics Will consider axiomatic semantics (A.S.) of IMP:
Spring 2016 Program Analysis and Verification
Program correctness Axiomatic semantics
Program Verification with Hoare Logic
Spring 2016 Program Analysis and Verification Operational Semantics
Programming Languages and Compilers (CS 421)
Programming Languages 2nd edition Tucker and Noonan
COP4020 Programming Languages
Presentation transcript:

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

Warm-up exercises Define program state: Define structural semantics configurations: Define the form of structural semantics transitions:

Tentative syllabus Program Verification Program Analysis Basics Operational semantics Axiomatic Verification Program Analysis Basics Control Flow Graphs Equation Systems Collecting Semantics Using Soot Abstract Interpretation fundamentals Lattices Fixed-Points Chaotic Iteration Galois Connections Domain constructors Widening/ Narrowing Analysis Techniques Numerical Domains Alias analysis Interprocedural Analysis Shape Analysis CEGAR

Agenda Basic concepts of correctness Axiomatic semantics (pages 175-183) Motivation First-order logic reminder Hoare Logic

program correctness

Program correctness concepts Specification = a certain relationship between initial state and final state Partial correctness = specifications that hold if the program terminates Termination = program always terminates i.e., for every input state Main focus of this course partial correctness + termination = total correctness Other correctness concepts exist: liveness, resource usage, …

Verifying factorial with structural semantics

Structural semantics for While x := a,   1 [x Aa] [asssos] skip,  1  [skipsos] S1,  1 S1’, ’ S1; S2,  1 S1’; S2,  [comp1sos] S1,  1 ’ S1; S2,  1 S2, ’ [comp2sos] if b then S1 else S2,  1 S1,  if B b  = tt [ifttsos] if b then S1 else S2,  1 S2,  if B b  = ff [ifffsos] while b do S,  1 if b then S; while b do S) else skip,  [whilesos]

Sfac  y:=1; while (x1) do (y:=y*x; x:=x–1) Factorial example Sfac  y:=1; while (x1) do (y:=y*x; x:=x–1) Factorial partial correctness specification = if the statement terminates then the final value of y will be the factorial of the initial value of x What if  x < 0? Formally, using structural semantics: Sfac,  1* ’ implies ’ y = ( x)!

Factorial proof strategy Sfac  y:=1; while (x1) do (y:=y*x; x:=x–1) Lemma 1 Lemma 2 Lemma 3 Lemma 1: if  x>1 then y:=y*x; x:=x–1,  1* ’ implies  y * ( x)! = ’ y * (’ x)! and ’ x1 Lemma 2: if  x1 then while (x=1) do (y:=y*x; x:=x–1),  1* ’ implies  y * ( x)! = ’ y * (’ x)! and ’ x=1 Lemma 3: if  x1 then Sfac,  1* ’ implies ’ y = ( x)!

Factorial example: lemma 1 Sfac  y:=1; while (x1) do (y:=y*x; x:=x–1) Lemma 1: if  x>1 then y:=y*x; x:=x–1,  1 * ’ implies  y * ( x)! = ’ y * (’ x)! and ’ x1 Proof: Assume  x>1 y:=y*x; x:=x–1,  1 x:=x–1, [y y* x] 1 [y y* x, xx–1] = ’ Now ’ y * (’ x)! = ( y* x) * ( x–1)! =  y * ( x)! And since’ x =  x-1 we have that ’ x1 QED

Factorial example: lemma 2 Sfac  y:=1; while (x1) do (y:=y*x; x:=x–1) Lemma 2: if  x1 then while (x1) do (y:=y*x; x:=x–1),  1* ’ implies  y * ( x)! = ’ y * (’ x)! and ’ x=1 Proof: W,  1 if (x1) then (y:=y*x; x:=x–1); W) else skip,  Case 1:  x=1 Case 2:  x1 – meaning  x>1

Factorial example: lemma 2, case 1 Sfac  y:=1; while (x1) do (y:=y*x; x:=x–1) Lemma 2: if  x1 then while (x1) do (y:=y*x; x:=x–1),  1* ’ implies  y * ( x)! = ’ y * (’ x)! and ’ x=1 Proof: W,  1 if (x1) then (y:=y*x; x:=x–1); W) else skip,  1 skip,  1  Claim holds

Factorial example: lemma 2, case 2 Sfac  y:=1; while (x1) do (y:=y*x; x:=x–1) Lemma 2: if  x1 then while (x1) do (y:=y*x; x:=x–1),  1* ’ implies  y * ( x)! = ’ y * (’ x)! and ’ x=1 Proof: W,  1 if (x1) then (y:=y*x; x:=x–1); W) else skip,  1 (y:=y*x; x:=x–1); while,  1* while, ’’ 1* ’ From lemma 1 we have that  y * ( x)! = ’ y * (’’ x)! and ’’ x1 Applying Lemma by induction (case 1 is the base case) gives us that ’’ y * (’’ x)! = ’ y * (’ x)! and ’ x=1 Combining the two, we get ’ y * (’ x)! = ’’ y * (’’ x)! =  y * ( x)! and ’ x=1 QED

Factorial example: lemma 3 Sfac  y:=1; while (x1) do (y:=y*x; x:=x–1) Lemma 3: if  x1 then Sfac,  1* ’ implies ’ y = ( x)! Proof: Assume  x1 Now y:=1; W,  1 W, [y1] and [y1] x =  x Therefore, we can apply lemma 2 and obtain W,  1* ’  [y1] y * ( [y1] x)! = ’ y * (’ x)! and ’ x=1 Simplifying this yields: 1 * ( x)! = ’ y * 1! and ’ x=1 Meaning: ’ y = ( x)! QED

How easy was that? Proof is very laborious Proof is long Need to connect all transitions and argue about relationships between their states Reason: too closely connected to semantics of programming language Proof is long Makes it hard to find possible mistakes How did we know to find this proof? Is there a methodology?

I’ll use operational semantics Can you prove my program correct? Better use axiomatic verification

One of the oldest surviving fragments of Euclid's Elements, a textbook used for millennia to teach proof-writing techniques. The diagram accompanies Book II, Proposition 5 "P. Oxy. I 29" by Euclid - http://www.math.ubc.ca/~cass/Euclid/papyrus/tha.jpg. Licensed under Public Domain via Wikimedia Commons - http://commons.wikimedia.org/wiki/File:P._Oxy._I_29.jpg#/media/File:P._Oxy._I_29.jpg

A systematic approach to program verification

Axiomatic verification approach What do we need in order to prove that the program does what it supposed to do? A language to express specifications Compare the behavior with the one obtained by the operational semantics Develop a proof system for showing that the program satisfies the specification Mechanically use the proof system to show correctness

Axiomatic semantics contributors Robert Floyd C.A.R. Hoare Edsger W. Dijkstra 1967: use assertions as foundation for static correctness proofs 1969: use Floyd’s ideas to define axiomatic semantics “An axiomatic basis for computer programming” Predicate transformer semantics: weakest precondition and strongest postcondition

Assertions, a.k.a Hoare triples { P } C { Q } statement a.k.a command precondition postcondition P and Q are state predicates expressed as logical formulas Example: x>0 If P holds in the initial state, and if execution of C terminates on that state, then Q will hold in the state in which C halts C is not required to always terminate {true} while true do skip {false}

Total correctness assertions [ P ] C [ Q ] If P holds in the initial state, execution of C must terminate on that state, and Q will hold in the state in which C halts

Specifying correctness of factorial

Factorial example: specify precondition/postcondition { ? } y := 1; while (x=1) do (y := y*x; x := x–1) { ? }

{ x>0 } y := 1; while (x=1) do (y := y*x; x := x–1) { y=x! } First attempt We need a way to “remember” value of x before execution { x>0 } y := 1; while (x=1) do (y := y*x; x := x–1) { y=x! } Holds only for value of x at state after execution finishes

{ x=n } y := 1; while (x=1) do (y := y*x; x := x–1) { y=n!  n>0 } Fixed assertion A logical variable, must not appear in statements – immutable. Also called a ghost variable. { x=n } y := 1; while (x=1) do (y := y*x; x := x–1) { y=n!  n>0 }

The proof outline Background axiom { n!=n*(n-1)! } { x>0  x=n } y := 1; { x>0  y*x!=n!  nx } while (x=1) do { x-1>0  (y*x)*(x-1)!=n!  n(x-1) } y := y*x; { x-1>0  y*(x-1)!=n!  n(x-1) } x := x–1 { y*x!=n!  n>0  x=1 }

Factorial spec and proof in Dafny online function Factorial(n: int): int requires n >= 1 { if n == 1 then 1 else n * Factorial(n - 1) } method ComputeFactorial(n: int) returns (y: int) ensures y == Factorial(n) var x := n; y := 1; while x != 1 invariant y * Factorial(x) == Factorial(n) decreases x y := y * x; x := x - 1;

Formalizing partial correctness via hoare logic

States and predicates  P   – program states (State)  – undefined A state predicate P is a (possibly infinite) set of states   P P holds in state  P 

Formalizing Hoare triples Q Ssos C  = ’ if C,  1*’  else P C(P)  C ’ { P } C { Q } , ’   . (  P  C,  1* ’)  ’  Q alternatively Convention:   P for all P    .   P  SsosC  Q

How do we express predicates? Extensional approach Abstract mathematical functions P : State  {tt, ff} Intensional approach via language of formulae

An assertion language Bexp is not expressive enough to express predicates needed for many proofs Extend Bexp Allow quantification z. … z. … z. z = kn Import well-known mathematical concepts n!  n  (n-1)   2  1

An assertion language Either a program variables or a logical variable a ::= n | x | a1 + a2 | a1  a2 | a1 – a2 A ::= true | false | a1 = a2 | a1  a2 | A | A1  A2 | A1  A2 | A1  A2 | z. A | z. A

Some FO logic definitions before we get to the rules

Free/bound variables A variable is said to be bound in a formula when it occurs in the scope of a quantifier Otherwise it is said to be free i. k=im (i+10077)i. j+1=i+3) FV(A)  the free variables of A Defined inductively on the abstract syntax tree of A

Computing free variables FV(n)  {} FV(x)  {x} FV(a1+a2)  FV(a1a2)  FV(a1-a2)  FV(a1)  FV(a2) FV(true)  FV(false) {} FV(a1=a2)  FV(a1a2)  FV(a1)  FV(a2) FV(A)  FV(A) FV(A1  A2)  FV(A1  A2)  FV(A1  A2)  FV(a1)  FV(a2) FV(z. A)  FV(z. A)  FV(A) \ {z}

Substitution An expression t is pure (a term) if it does not contain quantifiers A[t/z] denotes the assertion A’ which is the same as A, except that all instances of the free variable z are replaced by t A  i. k=im A[5/k] = …? A[5/i] = …?

Calculating substitutions n[t/z] = n x[t/z] = x x[t/x] = t (a1 + a2)[t/z] = a1[t/z] + a2[t/z] (a1  a2)[t/z] = a1[t/z]  a2[t/z] (a1 - a2)[t/z] = a1[t/z] - a2[t/z]

Calculating substitutions true[t/x] = true false[t/x] = false (a1 = a2)[t/z] = a1[t/z] = a2[t/z] (a1  a2)[t/z] = a1[t/z]  a2[t/z] (A)[t/z] = (A[t/z]) (A1  A2)[t/z] = A1[t/z]  A2[t/z] (A1  A2)[t/z] = A1[t/z]  A2[t/z] (A1  A2)[t/z] = A1[t/z]  A2[t/z] (z. A)[t/z] = z. A (z. A)[t/y] = z. A[t/y] ( z. A)[t/z] =  z. A ( z. A)[t/y] =  z. A[t/y]

Equivalence in FO logic We write A  B if for all states  if   A then   B { |   A }  { |   B } For every predicate A: false  A  true We write A  B if A  B and B  A false  5=7 In writing Hoare-style proofs, we will often replace a predicate A with A’ such that A  A’ and A’ is “simpler”

six are completely enough and now… the rules

Axiomatic semantics for While { P[a/x] } x := a { P } [assp] { P } skip { P } [skipp] { P } S1 { Q }, { Q } S2 { R } { P } S1; S2 { R } [compp] { b  P } S1 { Q }, { b  P } S2 { Q } { P } if b then S1 else S2 { Q } [ifp] What’s different about this rule? { b  P } S { P } { P } while b do S {b  P } [whilep] { P’ } S { Q’ } { P } S { Q } [consp] if PP’ and Q’Q

Assignment rule { P[a/x] } x := a { P } [assp] A “backwards” rule x := a always finishes Why is this true? Recall operational semantics: { | [xAa  P} 1 {[xAa | [xAa  P} [xAa]  P x:= a,  1 [xAa] [ass]

Practice with Dafny Ghost methods do not get compiled to code ghost method AssignRuleTest1() { var x, y, z; assume ???; x := y * z; assert x < 9; } ghost method AssignRuleTest2() { var x: int, y: int , z: int; x := x + 1; assert x > 8; ghost method AssignRuleTest3() { var x: int, y: int , z: int , w: int; assert w == 5; { } x:=y*z {x<9} Filters out states that do not satisfy the predicate A proof obligation { } x:=x+1 {x>8} { } x:=y*z {w=5}

skip rule { P } skip { P } [skipp]

Composition rule { P } S1 { Q }, { Q } S2 { R } { P } S1; S2 { R } [compp] S1,  1* ’, S2, ’ 1* ’’ S1; S2,  1* ’’ Lemma: Holds when S1 terminates in every state where P holds and then Q holds and S2 terminates in every state where Q holds and then R holds

Practice with Dafny ghost method CompositionRuleTest() { var x: int; assume x < 9; x := x + 1; assert ???; x := x * 2; assert x < 20; } { x < 9 } x := x + 1 { } x := x * 2; { x < 20 }

Condition rule { b  P } S1 { Q }, { b  P } S2 { Q } { P } if b then S1 else S2 { Q } [ifp] Intuitively, it means: Split cases on either b holds or not For each case make sure Q holds Conclude that Q holds on both cases

Practice with Dafny ghost method ConditionRuleTest() { var x: int, y: int; assume x > 8 || x < -8; if x > 0 { y := x; } else { y := -1 * x; assert ???;

{ b  P } S { P } { P } while b do S {b  P } Loop rule { b  P } S { P } { P } while b do S {b  P } [whilep] Here P is called an invariant for the loop Holds before and after each loop iteration Finding loop invariants – most challenging part of proofs When loop finishes, b is false

Example: write a specification { } while (timer  0) do timer := timer – 1 { } “The program should count to zero”

Practice with Dafny ghost method Timer(x: int) returns (timer: int) requires x >= 0; ensures timer == 0; { timer := x; while (timer != 0) invariant timer >= 0; timer := timer - 1; }

Rule of consequence { P’ } S { Q’ } { P } S { Q } [consp] if PP’ and Q’Q Allows strengthening the precondition and weakening the postcondition The only rule that is not related to a statement

Rule of consequence { P’ } S { Q’ } { P } S { Q } [consp] if PP’ and Q’Q Why do we need it? Allows the following {y*z<9} x:=y*z {x<9} {y*z<9w=5} x:=y*z {x<9}

See you next time