ESC Java. Static Analysis Spectrum Power Cost Type checking Data-flow analysis Model checking Program verification AutomatedManual ESC.

Slides:



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

In this episode of The Verification Corner, Rustan Leino talks about Loop Invariants. He gives a brief summary of the theoretical foundations and shows.
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.
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.
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.
50.530: Software Engineering Sun Jun SUTD. Week 9: Hoare Logic.
1 University of Toronto Department of Computer Science © 2001, Steve Easterbrook Lecture 10: Formal Verification Formal Methods Basics of Logic first order.
David Evans CS655: Programming Languages University of Virginia Computer Science Lecture 19: Minding Ps & Qs: Axiomatic.
Axiomatic Verification I Prepared by Stephen M. Thebaut, Ph.D. University of Florida Software Testing and Verification Lecture 17.
Partial correctness © Marcelo d’Amorim 2010.
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.
Simple Example {i = 0} j := i * i {j < 100} Can we ‘verify’ this triple? Only if we know the semantics of assignment.
1 Discrete Structures Lecture 29 Predicates and Programming Read Ch
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
Program Proving Notes Ellen L. Walker.
Fall Semantics Juan Carlos Guzmán CS 3123 Programming Languages Concepts Southern Polytechnic State University.
CSE 331 Software Design & Implementation Dan Grossman Winter 2014 Lecture 2 – Reasoning About Code With Logic 1CSE 331 Winter 2014.
1/22 Programs : Semantics and Verification Charngki PSWLAB Programs: Semantics and Verification Mordechai Ben-Ari Mathematical Logic for Computer.
Hoare-style program verification K. Rustan M. Leino Guest lecturer Rob DeLine’s CSE 503, Software Engineering University of Washington 26 Apr 2004.
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.
Dr. Muhammed Al-Mulhem 1ICS ICS 535 Design and Implementation of Programming Languages Part 1 Fundamentals (Chapter 4) Axiomatic Semantics ICS 535.
Review: forward E { P } { P && E } TF { P && ! E } { P 1 } { P 2 } { P 1 || P 2 } x = E { P } { \exists … }
CS 330 Programming Languages 09 / 16 / 2008 Instructor: Michael Eckmann.
Review: forward E { P } { P && E } TF { P && ! E } { P 1 } { P 2 } { P 1 || P 2 } x = E { P } { \exists … }
Using Decision Procedures for Program Verification Christopher Lynch Clarkson University.
Describing Syntax and Semantics
Exam 2 Help Session Prepared by Stephen M. Thebaut, Ph.D. University of Florida Software Testing and Verification.
1 Inference Rules and Proofs (Z); Program Specification and Verification Inference Rules and Proofs (Z); Program Specification and Verification.
ISBN Chapter 3 Describing Semantics -Attribute Grammars -Dynamic Semantics.
CS 363 Comparative Programming Languages Semantics.
Reading and Writing Mathematical Proofs Spring 2015 Lecture 4: Beyond Basic Induction.
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.
Pre- and postconditions, Using assertions and exceptions 1 Pre- and postconditions Using assertions and exceptions.
COP4020 Programming Languages Introduction to Axiomatic Semantics Prof. Robert van Engelen.
CSE Winter 2008 Introduction to Program Verification for-loops; review.
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
C HAPTER 3 Describing Syntax and Semantics. D YNAMIC S EMANTICS Describing syntax is relatively simple There is no single widely acceptable notation or.
CORRECTNESS ISSUES AND LOOP INVARIANTS Lecture 8 CS2110 – Fall 2014.
Further with Hoare Logic Sections 6.12, 6.10, 6.13
Reasoning About Code.
Proving Loops Testing debugging and verification
CSE 331 Software Design & Implementation
Hoare-style program verification
Mathematical Structures for Computer Science Chapter 1
Predicate Transforms I
Reasoning About Code; Hoare Logic
Programming Languages and Compilers (CS 421)
Programming Languages 2nd edition Tucker and Noonan
Semantics In Text: Chapter 3.
Section 1: Code Reasoning
Predicate Transformers
Predicate Transforms I
Predicate Transforms II
The Zoo of Software Security Techniques
Program Verification with Hoare Logic
Programming Languages 2nd edition Tucker and Noonan
Programming Languages 2nd edition Tucker and Noonan
COP4020 Programming Languages
Presentation transcript:

ESC Java

Static Analysis Spectrum Power Cost Type checking Data-flow analysis Model checking Program verification AutomatedManual ESC

Is This Program Correct? int square(int n) { int k = 0, r = 0, s = 1; while(k != n) { r = r + s; s = s + 2; k = k + 1; } return r; } Type checking not enough to check this –Neither is data-flow analysis, nor model checking

Program Verification Program verification is the most powerful static analysis method –Can reason about all properties of programs Cannot fully automate But … –Can automate certain parts (ESC/Java) –Teaches how to reason about programs in a systematic way

Specifying Programs Before we check a program we must specify what it does We need formal specifications –English comments are not enough We use logic notation –Theory of pre- and post-conditions

State Predicates A predicate is a boolean expression on the program state (e.g., variables, object fields) Examples: –x == 8 –x < y –true –false –( 8 i. 0 = 0)

Using Predicates to Specify Programs We focus first on how to specify a statement Hoare triple for statement S { P } S { Q } Says that if S is started in a state that satisfies P, and S terminates, then it terminates in Q –This is the liberal version, which doesn’t care about termination –Strict version: if S is started in a state that satisfies P then S terminates in Q preconditionpostcondition

Hoare Triples. Examples. { true } x = 12 { x == 12 } { y >= 0 } x = 12 { x == 12 } { true } x = 12 { x >= 0 } (Programs satisfy many possible specifications) { x < 10 } x = x + 1 { x < 11 } { n >= 0 } x = fact(n) { x == n ! } { true } a = 0; if(x != 0) { a = 2 * x; } { a == 2*x }

Computing Hoare Triples We compute the triples using rules –One rule for each statement kind –Rules for composed statements

Assignment Assignment is the simplest operation and the trickiest one to reason about ! { y >= 2 } x = 5 { ? } { x == y } x = x + 1 { ? } { ? } x = 5 { x == y } { ? } x = x + 1 { x == y } { ? } x = x + 1 { x 2 + y 2 == z 2 } { x 2 + y 2 == z 2 } x = x + 1 { ? }

Assignment Rule Rule for assignment { Q[x := E] } x = E { Q} Examples: –{ 12 == 12 } x = 12 { x == 12 } –{ 12 >= 0 } x = 12 { x >= 0 } –{ ? } x = x + 1 { x >= 0 } –{ x >= 1 } x = x + 1 { ? } Q with x replaced by E x == 12 with x replaced by 12

Relaxing Specifications Consider { x >= 1 } x = x + 1 { x >= 2 } –It is very tight specification. We can relax it Example: { x >= 5 } x = x + 1 { x >= 2 } (since x >= 5 ) x + 1 >= 2) x = E { P } if P ) Q[x:=E] { Q }

Assignments: forward and backward Two ways to look at the rules: –Backward: given post-condition, what is pre- condition? –Forward: given pre-condition, what is post-condition? x = E { ??? } { Q } x = E { P } { ??? }

Assignments: forward and backward Two ways to look at the rules: –Backward: given post-condition, what is pre- condition? –Forward: given pre-condition, what is post-condition? x = E { Q [ x := E] } { Q } x = E { P } { ??? }

Assignments: forward and backward Two ways to look at the rules: –Backward: given post-condition, what is pre- condition? –Forward: given pre-condition, what is post-condition? x = E { Q [ x := E] } { Q } x = E { P } { }

Example of running it forward { x == y } x = x + 1 { ? }

Example of running it forward { x == y } x = x + 1 { ? }

Forward or Backward Forward reasoning –Know the precondition –Want to know what postconditon the code establishes Backward reasoning –Know what we want to code to establish –Must find in what precondition this happens Backward is used most often –Start with what you want to verify –Instead of verifying everything the code does

Weakest precondition wp(S, Q) is the weakest P such that { P } S { Q } –Order on predicates: Strong ) Weak –wp returns the “best” possible predicate wp(x := E, Q) = Q[x := E] In general: S { P } if P ) wp(S,Q) { Q }

Weakest precondition This points to a verification algorithm: –Given function body annotated with pre-condition P and post-condition Q: Compute wp of Q with respect to functon body Ask a theorem prover to show that P implies the wp The wp function we will use is liberal (P does not guarantee termination) –If using both strict and liberal in the same context, the usual notation is wlp the liberal version and wp for the strict one

Strongest precondition sp(S, P) is the strongest Q such that { P } S { Q } –Recall: Strong ) Weak –sp returns the “best” possible predicate sp(x := E, P) = … In general: S { P } { Q } if sp(S,P) ) Q

Strongest postcondition Strongest postcondition and weakest preconditions are symmetric This points to an equivalent verification algorithm: –Given function body annotated with pre-condition P and post-condition Q: Compute sp of P with respect to functon body Ask a theorem prover to show that the sp implies Q

Composing Specifications If { P } S 1 { R } and { R } S 2 { Q} then { P } S 1 ; S 2 { Q } Example: x = x - 1; y = y - 1 { x >= y }

Composing Specifications If { P } S 1 { R } and { R } S 2 { Q} then { P } S 1 ; S 2 { Q } Example: x = x - 1; y = y - 1 { x >= y }

In terms of wp and sp wp(S 1 ; S 2, Q) = wp(S 1,wp(S 2, Q)) sp(S 1 ; S 2, P) = sp(S 2,sp(S 1, P))

Conditionals Rule for the conditional (flow graph) Example: E { P } { P 1 } if P && E ) P 1 TF { P 2 } if P && ! E ) P 2 x == 0 { x >= 0 } TF { x == 0 } since x >= 0 && x == 0 ) x == 0 { x >= 1 } since x >= 0 && x != 0 ) x >= 1

Conditionals: Forward and Backward Recall: rule for the conditional Forward: given P, find P 1 and P 2 –pick P 1 to be P && E, and P 2 to be P && ! E Backward: given P 1 and P 2, find P –pick P to be (P 1 && E) || (P 2 && ! E) –Or pick P to be (E ) P 1 ) && (! E ) P 2 ) E { P } { P 1 } provided P && E ) P 1 T F { P 2 } provided P && ! E ) P 2

Joins Rule for the join: Forward: pick P to be P 1 || P 2 Backward: pick P 1, P 2 to be P { P 1 } { P 2 } { P } provided P 1 ) P and P 2 ) P

Review E { P } { P 1 } if P && E ) P 1 TF { P 2 } if P && ! E ) P 2 { P 1 } { P 2 } { P } if P 1 ) P and P 2 ) P x = E { P } { Q } if P ) Q[x:=E] Implication is always in the direction of the control flow

Review: forward E { P } { P && E } TF { P && ! E } { P 1 } { P 2 } { P 1 || P 2 } x = E { P } { \exists … }

Review: backward E {(E ) P 1 ) && (! E ) P 2 ) } { P 1 } TF { P 2 } { P } x = E {Q[x:=E] } { Q }

Example: Absolute value static int abs(int x) ensures \result >= 0 { if (x < 0) { x = -x; } if (c > 0) { c--; } return x; } x < 0 x = -x TF c > 0 c-- TF

Example: Absolute value x < 0 x = -x TF c > 0 c-- TF

Example: Absolute value x < 0 x = -x TF c > 0 c-- TF

In Simplify > (IMPLIES TRUE (AND (IMPLIES (< x 0) (AND (IMPLIES (> c 0) (>= (- 0 x) 0)) (IMPLIES ( = (- 0 x) 0)))) (IMPLIES (>= x 0) (AND (IMPLIES (> c 0) (>= x 0)) (IMPLIES ( = x 0)))))) 1: Valid. >

So far… Framework for checking pre and post conditions of computations without loops Suppose we want to check that some condition holds inside the computation, rather than at the end static int abs(int x) { if (x < 0) { x = -x; } if (c > 0) { c--; } return x; } Say we want to check that x > 0 here

Asserts { Q && E } assert(E) { Q } Backward: wp(assert(E), Q) = Q && E Forward: sp(assert(E), P) = ??? assert(E) Q Q && E assert(E) ??? P

Example: Absolute value with assert static int abs(int x) { if (x < 0) { x = -x; assert(x > 0); } if (c > 0) { c--; } return x; } x < 0 x = -x assert(x > 0) TF c > 0 c-- TF

Example: Absolute value with assert x < 0 x = -x assert(x > 0) TF c > 0 c-- TF

Example: Absolute value with assert x < 0 x = -x assert(x > 0) TF c > 0 c-- TF

Adding the postcondition back in x < 0 x = -x assert(x > 0) TF c > 0 c-- TF

Adding the postcondition back in x < 0 x = -x assert(x > 0) TF c > 0 c-- TF

Another Example: Double Locking “An attempt to re-acquire an acquired lock or release a released lock will cause a deadlock.” Calls to lock and unlock must alternate. lock unlock

Locking Rules We assume that the boolean predicate locked says if the lock is held or not { ! locked && P[locked := true] } lock { P } –lock behaves as assert(! locked); locked = true { locked && P[locked := false] } unlock { P } –unlock behaves as assert(locked); locked = false

Locking Example … lock … x==0 … unlock x==0 T T { ! L && P[L := true] } lock { P } { L && P[L := false] } unlock { P } { ! L }

Locking Example … lock … x==0 … unlock x==0 T T { ! L && P[L := true] } lock { P } { L && P[L := false] } unlock { P } { ! L }

Locking Example: forward direction … lock … x==0 … unlock { ! locked } { ! locked && x == 0 } { ! locked && x  0 } x==0 T T { ! locked && x == 0 } { locked && x == 0 } { locked = (x == 0) } { locked && x == 0 } { ! locked && (x == 0) } { ! locked && x  0 } { ! locked }