Verification Techniques for Object Invariants Peter Mller - - PowerPoint PPT Presentation

verification techniques for
SMART_READER_LITE
LIVE PREVIEW

Verification Techniques for Object Invariants Peter Mller - - PowerPoint PPT Presentation

A Unified Framework for Verification Techniques for Object Invariants Peter Mller Microsoft Research Joint work with Sophia Drossopoulou and Adrian Francalanza 2 Object Invariants Express consistency criteria of objects Support


slide-1
SLIDE 1

A Unified Framework for Verification Techniques for Object Invariants

Peter Müller

Microsoft Research Joint work with Sophia Drossopoulou and Adrian Francalanza

slide-2
SLIDE 2

Object Invariants

  • Express consistency criteria of objects
  • Support induction scheme
  • Established by constructors
  • Preserved by all methods
  • Potentially broken within method body
  • Challenges
  • Call-backs
  • Multi-object invariants
  • Subclass invariants

Peter Müller – FOOL 2008

2

slide-3
SLIDE 3

Textbook Solution

class C { int a, b; invariant 0 ≤ a < b; C( ) { a := 0; b := 3; } void m( ) { int k := 10 / ( b – a ); a := a + 3; n( ); b := ( k + 4 ) * b; } n( ) { m( ); } }

3

Peter Müller – FOOL 2008

class Client { C c; invariant c.a ≤ 10; } class Sub extends C { invariant a ≤ 10; } Prove invariant of C and its subclasses Assume invariant class Client { void set(C c) { c.a := -1; } }

slide-4
SLIDE 4

Verification Techniques Differ in

  • Invariant semantics
  • When are which invariants expected to hold?
  • Admissible invariants
  • Which objects may an invariant depend on
  • Proof obligations
  • What has to be proven when?
  • Program restrictions
  • Which objects may receive method calls or field updates?
  • Type systems

4

Peter Müller – FOOL 2008

slide-5
SLIDE 5

Approach

  • Develop formal framework
  • Independent of type system and verification logic
  • Characterize techniques in terms of 7 framework

parameters

  • Define soundness
  • Identify 5 criteria on framework parameters that are

sufficient for soundness

  • Instantiate framework
  • Obtain six techniques from the literature

Peter Müller – FOOL 2008

5

slide-6
SLIDE 6

Areas and Regions

  • Object areas
  • Describe sets of objects
  • Assume (do not define) interpretation
  • Invariant regions
  • Describe sets of object-class pairs
  • Assume (do not define) interpretation

Peter Müller – FOOL 2008

6

[[ r ]]h,o  { (o’, C) | class(o’) <: C } [[ a ]]h,o  dom( h )

slide-7
SLIDE 7

Areas and Regions: Example

  • Areas
  • Regions

7

Peter Müller – FOOL 2008

a ::= self | any

[[ self ]]h,o = { o } [[ any ]]h,o = dom( h )

r ::= emp | self | any

[[ emp ]]h,o = { } [[[ self ]]h,o = { (o, C) | class(o) <: C } [[ any ]]h,o = { (o’, C) | class(o’) <: C }

slide-8
SLIDE 8

Framework Parameters

  • Invariant semantics
  • X(C)

Invariants expected at visible states of C.m

  • V(C)

Invariants possibly violated by C.m

  • Admissible invariants
  • D(C)

Invariants depending on C fields

  • Proof obligations
  • P(C,a)

Proof obligation for C.m before calls in a

  • E(C)

Proof obligation C.m before end

  • Program restrictions
  • U(C,D)

Objects whose D-fields may be updated by C.m

  • C(C,D)

Objects whose D-methods may be called from C.m

8

Peter Müller – FOOL 2008

slide-9
SLIDE 9

invariant 0 ≤ this.a < this.b; void m( ) { int k := 10 / ( b – a ); this.a := this.a + 3; this.n( ); this.b := ( k + 4 ) * this.b; } invariant 0 ≤ this.a < this.b; // check (this,C) is in D void m( ) { int k := 10 / ( b – a ); this.a := this.a + 3; this.n( ); this.b := ( k + 4 ) * this.b; } invariant 0 ≤ this.a < this.b; // check (this,C) is in D void m( ) { int k := 10 / ( b – a ); this.a := this.a + 3; // check this is in U this.n( ); // check this is in C this.b := ( k + 4 ) * this.b; // check this is in U } invariant 0 ≤ this.a < this.b; // check (this,C) is in D void m( ) { // assume X int k := 10 / ( b – a ); this.a := this.a + 3; // check this is in U this.n( ); // check this is in C this.b := ( k + 4 ) * this.b; // check this is in U // assume X } invariant 0 ≤ this.a < this.b; // check (this,C) is in D void m( ) { // assume X int k := 10 / ( b – a ); this.a := this.a + 3; // check this is in U // prove P this.n( ); // check this is in C this.b := ( k + 4 ) * this.b; // check this is in U // prove E // assume X }

Meaning of Parameters: Example

9

Peter Müller – FOOL 2008

X \ V holds

slide-10
SLIDE 10

Parameters: Textbook Invariants

Textbook X(C) any V(C) self D(C) self P(C,a) emp E(C) self U(C,D) self C(C,D) any

10

Peter Müller – FOOL 2008

slide-11
SLIDE 11

Programming Language

  • Expressions and types
  • Runtime expressions
  • Assume judgment:
  • Assume (do not define) type system
  • Main judgment
  • Make requirements (soundness, etc.)

Peter Müller – FOOL 2008

11

e ::= this | x | … | e&prove r t ::= C a e ::= o| s∙e | … | FatalExc | VerifExc h╞ o,C ├ e : C a

slide-12
SLIDE 12

Invariant Semantics

  • Method calls
  • Method termination
  • Proof obligation

Peter Müller – FOOL 2008

12

h╞ [[ X ]]h,s(this) s∙call e,h → s∙ret e,h h╞ [[ X ]]h,s(this) s∙ret v,h → v,h h╞ [[ X ]]h,s(this) s∙call e,h → FatalExc,h h╞ [[ X ]]h,s(this) s∙ret v,h → FatalExc,h h╞ [[ r ]]h,s(this) s∙v&prove r,h → v,h h╞ [[ r ]]h,s(this) s∙v&prove r,h → VerifExc,h

slide-13
SLIDE 13

Verified Programs

  • Field updates: check area
  • Method calls: check area, verify invariants

Peter Müller – FOOL 2008

13

├ e : C a

a  U(class(),C’)

C has field f defined in C’ … ├vf e.f := e’ ├ e : C a

a  C(class(),C’)

C inherits m from C’ … ├vf e.m(e’&prove P(C’,a))

slide-14
SLIDE 14

Soundness

  • A verification technique is sound if the

following properties hold for each well-typed, verified program P:

  • Execution of P does not lead to FatalExc
  • In each execution state  of P, the following

properties hold for each stack frame for a method C.m:

  • The invariants in X(C) \ V(C) hold
  • If  is a visible state of m, the invariants in X(C) hold

Peter Müller – FOOL 2008

14

slide-15
SLIDE 15

Soundness Criteria

S1: S2: S3: S4: S5:

Peter Müller – FOOL 2008

15

a  C(C,D)  (a  X(D)) \ (X(C) \ V(C))  P(C,a)

V(C)  X(C)  E(C) C(C,D)  ( V(D) \ X(D) )  V(C) U(C,D)  D(D)  V(C) X(C)  X(D) V(C) \ X(C)  V(D) \ X(D) C <: D 

slide-16
SLIDE 16

Soundness Theorem

16

Peter Müller – FOOL 2008

A verification technique that satisfies S1 – S5 is sound

slide-17
SLIDE 17

a  C(C,D)  (a  X(D)) \ (X(C) \ V(C))  P(C,a) any \ (X(C) \ V(C))  P(C,a) any \ (any \ self)  emp

Soundness: Textbook Invariants

17

Peter Müller – FOOL 2008

X(C) any V(C) self D(C) self P(C,a) emp E(C) self U(C,D) self C(C,D) any

V(C)  X(C)  E(C) C(C,D)  ( V(D) \ X(D) )  V(C) U(C,D)  D(D)  V(C) X(C)  X(D) V(C) \ X(C)  V(D) \ X(D) C <: D 

self  any  self any  (self \ any)  self self  self  self any  any self \ any  self \ any C <: D 

slide-18
SLIDE 18

Summary

  • Parametric w.r.t. underlying type system and

verification logic

  • Abstract explanation how technique works
  • Criteria for comparisons
  • Guidelines for the development of further

techniques

  • Instantiation for six techniques from the

literature, found one unsoundness

Peter Müller – FOOL 2008

18