the why krakatoa caduceus platform for deductive program
play

The Why/Krakatoa/Caduceus Platform for Deductive Program - PowerPoint PPT Presentation

Dec 04, 2023 •217 likes •2.04k views

The Why/Krakatoa/Caduceus Platform for Deductive Program Verification Jean-Christophe Filli atre CNRS Universit e Paris Sud TYPES Summer School August 30th, 2007 TYPES Summer School August 30th, 2007 Jean-Christophe Filli

  1. Annotations assert { p } ; e e { p } Examples: assert { x > 0 } ; 1 / x x := 0 { ! x = 0 } if ! x > ! y then ! x else ! y { result ≥ ! x ∧ result ≥ ! y } x := ! x + 1 { ! x > old ( ! x ) } TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  2. Annotations assert { p } ; e e { p } Examples: assert { x > 0 } ; 1 / x x := 0 { ! x = 0 } if ! x > ! y then ! x else ! y { result ≥ ! x ∧ result ≥ ! y } x := ! x + 1 { ! x > old ( ! x ) } TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  3. Annotations assert { p } ; e e { p } Examples: assert { x > 0 } ; 1 / x x := 0 { ! x = 0 } if ! x > ! y then ! x else ! y { result ≥ ! x ∧ result ≥ ! y } x := ! x + 1 { ! x > old ( ! x ) } TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  4. Annotations (cont’d) Loop invariant and variant while e 1 do { invariant p variant t } e 2 done Example: while ! x < N do { invariant ! x ≤ N variant N − ! x } x := ! x + 1 done TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  5. Annotations (cont’d) Loop invariant and variant while e 1 do { invariant p variant t } e 2 done Example: while ! x < N do { invariant ! x ≤ N variant N − ! x } x := ! x + 1 done TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  6. Auxiliary variables Used to denote the intermediate values of variables Example: . . . { ! x = X } . . . { ! x > X } . . . We will use labels instead new construct L : e new annotation at ( t , L ) Example: . . . L : while . . . do { invariant ! x ≥ at ( ! x , L ) . . . } . . . done TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  7. Auxiliary variables Used to denote the intermediate values of variables Example: . . . { ! x = X } . . . { ! x > X } . . . We will use labels instead new construct L : e new annotation at ( t , L ) Example: . . . L : while . . . do { invariant ! x ≥ at ( ! x , L ) . . . } . . . done TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  8. Auxiliary variables Used to denote the intermediate values of variables Example: . . . { ! x = X } . . . { ! x > X } . . . We will use labels instead new construct L : e new annotation at ( t , L ) Example: . . . L : while . . . do { invariant ! x ≥ at ( ! x , L ) . . . } . . . done TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  9. Auxiliary variables Used to denote the intermediate values of variables Example: . . . { ! x = X } . . . { ! x > X } . . . We will use labels instead new construct L : e new annotation at ( t , L ) Example: . . . L : while . . . do { invariant ! x ≥ at ( ! x , L ) . . . } . . . done TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  10. Functions A function declaration introduces a precondition fun ( x : τ ) → { p } e rec f ( x 1 : τ 1 ) . . . ( x n : τ n ) : β { variant t } = { p } e Example: fun ( x : int ref) → { ! x > 0 } x := ! x − 1 { ! x ≥ 0 } TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  11. Functions A function declaration introduces a precondition fun ( x : τ ) → { p } e rec f ( x 1 : τ 1 ) . . . ( x n : τ n ) : β { variant t } = { p } e Example: fun ( x : int ref) → { ! x > 0 } x := ! x − 1 { ! x ≥ 0 } TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  12. Functions A function declaration introduces a precondition fun ( x : τ ) → { p } e rec f ( x 1 : τ 1 ) . . . ( x n : τ n ) : β { variant t } = { p } e Example: fun ( x : int ref) → { ! x > 0 } x := ! x − 1 { ! x ≥ 0 } TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  13. Modularity A function declaration extends the ML function type with a precondition , an effect and a postcondition f : x : τ 1 → { p } τ 2 reads x 1 , . . . , x n writes y 1 , . . . , y m { q } Example: swap : x : int ref → y : int ref → {} unit writes x , y { ! x = old ( ! y ) ∧ ! y = old ( ! x ) } TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  14. Modularity A function declaration extends the ML function type with a precondition , an effect and a postcondition f : x : τ 1 → { p } τ 2 reads x 1 , . . . , x n writes y 1 , . . . , y m { q } Example: swap : x : int ref → y : int ref → {} unit writes x , y { ! x = old ( ! y ) ∧ ! y = old ( ! x ) } TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  15. Exceptions Finally, we introduce exceptions in our language a more realistic ML fragment to interpret abrupt statements like return , break or continue new constructs raise ( E e ) : τ try e 1 with E x → e 2 end TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  16. Exceptions Finally, we introduce exceptions in our language a more realistic ML fragment to interpret abrupt statements like return , break or continue new constructs raise ( E e ) : τ try e 1 with E x → e 2 end TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  17. Exceptions Finally, we introduce exceptions in our language a more realistic ML fragment to interpret abrupt statements like return , break or continue new constructs raise ( E e ) : τ try e 1 with E x → e 2 end TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  18. Exceptions The notion of postcondition is extended if x < 0 then raise Negative else sqrt x { result ≥ 0 | Negative ⇒ x < 0 } So is the notion of effect div : x : int → y : int → { . . . } int raises Negative { . . . } TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  19. Exceptions The notion of postcondition is extended if x < 0 then raise Negative else sqrt x { result ≥ 0 | Negative ⇒ x < 0 } So is the notion of effect div : x : int → y : int → { . . . } int raises Negative { . . . } TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  20. Loops and exceptions We can replace the while loop by an infinite loop loop e { invariant p variant t } and simulate the while loop using an exception while e 1 do { invariant p variant t } e 2 done ≡ try loop if e 1 then e 2 else raise Exit { invariant p variant t } with Exit -> void end simpler constructs ⇒ simpler typing and proof rules TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  21. Loops and exceptions We can replace the while loop by an infinite loop loop e { invariant p variant t } and simulate the while loop using an exception while e 1 do { invariant p variant t } e 2 done ≡ try loop if e 1 then e 2 else raise Exit { invariant p variant t } with Exit -> void end simpler constructs ⇒ simpler typing and proof rules TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  22. Loops and exceptions We can replace the while loop by an infinite loop loop e { invariant p variant t } and simulate the while loop using an exception while e 1 do { invariant p variant t } e 2 done ≡ try loop if e 1 then e 2 else raise Exit { invariant p variant t } with Exit -> void end simpler constructs ⇒ simpler typing and proof rules TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  23. Summary Types τ ::= β | β ref | ( x : τ ) → κ { p } τ ǫ { q } κ ::= q ::= p ; E ⇒ p ; . . . ; E ⇒ p ǫ ::= reads x , . . . , x writes x , . . . , x raises E , . . . , E Annotations c | x | ! x | φ ( t , . . . , t ) | old ( t ) | at ( t , L ) t ::= p ::= True | False | P ( t , . . . , t ) | p ⇒ p | p ∧ p | p ∨ p | ¬ p | ∀ x : β. p | ∃ x : β. p TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  24. Summary Types τ ::= β | β ref | ( x : τ ) → κ { p } τ ǫ { q } κ ::= q ::= p ; E ⇒ p ; . . . ; E ⇒ p ǫ ::= reads x , . . . , x writes x , . . . , x raises E , . . . , E Annotations c | x | ! x | φ ( t , . . . , t ) | old ( t ) | at ( t , L ) t ::= p ::= True | False | P ( t , . . . , t ) | p ⇒ p | p ∧ p | p ∨ p | ¬ p | ∀ x : β. p | ∃ x : β. p TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  25. Programs c | x | ! x | φ ( u , . . . , u ) u ::= e ::= u | x := e | let x = e in e | let x = ref e in e | if e then e else e | loop e { invariant p variant t } | L : e | raise ( E e ) : τ | try e with E x → e end | assert { p } ; e | e { q } | fun ( x : τ ) → { p } e | rec x ( x : τ ) . . . ( x : τ ) : β { variant t } = { p } e | e e TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  26. Typing A typing judgment Γ ⊢ e : ( τ, ǫ ) Rules given in the notes (page 24) The main purpose is to exclude aliases In particular, references can’t escape their scopes TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  27. Typing A typing judgment Γ ⊢ e : ( τ, ǫ ) Rules given in the notes (page 24) The main purpose is to exclude aliases In particular, references can’t escape their scopes TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  28. Semantics Call-by-value semantics, with left to right evalutation Big-step operational semantics given in the notes (page 26) TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  29. Proof Rules: Weakest Preconditions We define the predicate wp ( e , q ), called the weakest precondition for program e and postcondition q Property: If wp ( e , q ) holds, then e terminates and q holds at the end of execution (and all inner annotations are verified) The converse holds for the fragment without loops and functions The correctness of an annotated program e is thus wp ( e , True) TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  30. Proof Rules: Weakest Preconditions We define the predicate wp ( e , q ), called the weakest precondition for program e and postcondition q Property: If wp ( e , q ) holds, then e terminates and q holds at the end of execution (and all inner annotations are verified) The converse holds for the fragment without loops and functions The correctness of an annotated program e is thus wp ( e , True) TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  31. Proof Rules: Weakest Preconditions We define the predicate wp ( e , q ), called the weakest precondition for program e and postcondition q Property: If wp ( e , q ) holds, then e terminates and q holds at the end of execution (and all inner annotations are verified) The converse holds for the fragment without loops and functions The correctness of an annotated program e is thus wp ( e , True) TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  32. Proof Rules: Weakest Preconditions We define the predicate wp ( e , q ), called the weakest precondition for program e and postcondition q Property: If wp ( e , q ) holds, then e terminates and q holds at the end of execution (and all inner annotations are verified) The converse holds for the fragment without loops and functions The correctness of an annotated program e is thus wp ( e , True) TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  33. Definition of wp ( e , q ) We actually define wp ( e , q ; r ) where q is the “normal” postcondition r ≡ E 1 ⇒ q 1 ; . . . ; E n ⇒ q n is the set of “exceptional” post. TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  34. Basic constructs wp ( u , q ; r ) = q [ result ← u ] wp ( x := e , q ; r ) = wp ( e , q [ result ← void ; ! x ← result ]; r ) wp ( let x = e 1 in e 2 , q ; r ) = wp ( e 1 , wp ( e 2 , q ; r )[ x ← result ]; r ) wp ( let x = ref e 1 in e 2 , q ; r ) = wp ( e 1 , wp ( e 2 , q ; r )[ ! x ← result ]; r ) wp ( if e 1 then e 2 else e 3 , q ; r ) = wp ( e 1 , if result then wp ( e 2 , q ; r ) else wp ( e 3 , q ; r ); r ) wp ( L : e , q ; r ) = wp ( e , q ; r )[ at ( t , L ) ← t ] TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  35. Basic constructs wp ( u , q ; r ) = q [ result ← u ] wp ( x := e , q ; r ) = wp ( e , q [ result ← void ; ! x ← result ]; r ) wp ( let x = e 1 in e 2 , q ; r ) = wp ( e 1 , wp ( e 2 , q ; r )[ x ← result ]; r ) wp ( let x = ref e 1 in e 2 , q ; r ) = wp ( e 1 , wp ( e 2 , q ; r )[ ! x ← result ]; r ) wp ( if e 1 then e 2 else e 3 , q ; r ) = wp ( e 1 , if result then wp ( e 2 , q ; r ) else wp ( e 3 , q ; r ); r ) wp ( L : e , q ; r ) = wp ( e , q ; r )[ at ( t , L ) ← t ] TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  36. Basic constructs wp ( u , q ; r ) = q [ result ← u ] wp ( x := e , q ; r ) = wp ( e , q [ result ← void ; ! x ← result ]; r ) wp ( let x = e 1 in e 2 , q ; r ) = wp ( e 1 , wp ( e 2 , q ; r )[ x ← result ]; r ) wp ( let x = ref e 1 in e 2 , q ; r ) = wp ( e 1 , wp ( e 2 , q ; r )[ ! x ← result ]; r ) wp ( if e 1 then e 2 else e 3 , q ; r ) = wp ( e 1 , if result then wp ( e 2 , q ; r ) else wp ( e 3 , q ; r ); r ) wp ( L : e , q ; r ) = wp ( e , q ; r )[ at ( t , L ) ← t ] TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  37. Basic constructs wp ( u , q ; r ) = q [ result ← u ] wp ( x := e , q ; r ) = wp ( e , q [ result ← void ; ! x ← result ]; r ) wp ( let x = e 1 in e 2 , q ; r ) = wp ( e 1 , wp ( e 2 , q ; r )[ x ← result ]; r ) wp ( let x = ref e 1 in e 2 , q ; r ) = wp ( e 1 , wp ( e 2 , q ; r )[ ! x ← result ]; r ) wp ( if e 1 then e 2 else e 3 , q ; r ) = wp ( e 1 , if result then wp ( e 2 , q ; r ) else wp ( e 3 , q ; r ); r ) wp ( L : e , q ; r ) = wp ( e , q ; r )[ at ( t , L ) ← t ] TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  38. Basic constructs wp ( u , q ; r ) = q [ result ← u ] wp ( x := e , q ; r ) = wp ( e , q [ result ← void ; ! x ← result ]; r ) wp ( let x = e 1 in e 2 , q ; r ) = wp ( e 1 , wp ( e 2 , q ; r )[ x ← result ]; r ) wp ( let x = ref e 1 in e 2 , q ; r ) = wp ( e 1 , wp ( e 2 , q ; r )[ ! x ← result ]; r ) wp ( if e 1 then e 2 else e 3 , q ; r ) = wp ( e 1 , if result then wp ( e 2 , q ; r ) else wp ( e 3 , q ; r ); r ) wp ( L : e , q ; r ) = wp ( e , q ; r )[ at ( t , L ) ← t ] TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  39. Basic constructs wp ( u , q ; r ) = q [ result ← u ] wp ( x := e , q ; r ) = wp ( e , q [ result ← void ; ! x ← result ]; r ) wp ( let x = e 1 in e 2 , q ; r ) = wp ( e 1 , wp ( e 2 , q ; r )[ x ← result ]; r ) wp ( let x = ref e 1 in e 2 , q ; r ) = wp ( e 1 , wp ( e 2 , q ; r )[ ! x ← result ]; r ) wp ( if e 1 then e 2 else e 3 , q ; r ) = wp ( e 1 , if result then wp ( e 2 , q ; r ) else wp ( e 3 , q ; r ); r ) wp ( L : e , q ; r ) = wp ( e , q ; r )[ at ( t , L ) ← t ] TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  40. Traditional rules Assignment of a side-effects free expression wp ( x := u , q ) = q [ ! x ← u ] Exception-free sequence wp ( e 1 ; e 2 , q ) = wp ( e 1 , wp ( e 2 , q )) TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  41. Traditional rules Assignment of a side-effects free expression wp ( x := u , q ) = q [ ! x ← u ] Exception-free sequence wp ( e 1 ; e 2 , q ) = wp ( e 1 , wp ( e 2 , q )) TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  42. Exceptions wp ( raise ( E e ) : τ, q ; r ) = wp ( e , r E ; r ) wp ( try e 1 with E x → e 2 end , q ; r ) = wp ( e 1 , q ; E ⇒ wp ( e 2 , q ; r )[ x ← result ]; r ) TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  43. Exceptions wp ( raise ( E e ) : τ, q ; r ) = wp ( e , r E ; r ) wp ( try e 1 with E x → e 2 end , q ; r ) = wp ( e 1 , q ; E ⇒ wp ( e 2 , q ; r )[ x ← result ]; r ) TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  44. Annotations wp ( assert { p } ; e , q ; r ) = p ∧ wp ( e , q ; r ) = wp ( e , q ′ ∧ q ; r ′ ∧ r ) wp ( e { q ′ ; r ′ } , q ; r ) TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  45. Annotations wp ( assert { p } ; e , q ; r ) = p ∧ wp ( e , q ; r ) = wp ( e , q ′ ∧ q ; r ′ ∧ r ) wp ( e { q ′ ; r ′ } , q ; r ) TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  46. Loops wp ( loop e { invariant p variant t } , q ; r ) = p ∧ ∀ ω. p ⇒ wp ( L : e , p ∧ t < at ( t , L ); r ) where ω = the variables (possibly) modified by e Usual while loop wp ( while e 1 do { invariant p variant t } e 2 done , q ; r ) = p ∧ ∀ ω. p ⇒ wp ( L :if e 1 then e 2 else raise E , p ∧ t < at ( t , L ) , E ⇒ q ; r ) = p ∧ ∀ ω. p ⇒ wp ( e 1 , if result then wp ( e 2 , p ∧ t < at ( t , L )) else q , r )[ at ( x , L ) ← x ] TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  47. Loops wp ( loop e { invariant p variant t } , q ; r ) = p ∧ ∀ ω. p ⇒ wp ( L : e , p ∧ t < at ( t , L ); r ) where ω = the variables (possibly) modified by e Usual while loop wp ( while e 1 do { invariant p variant t } e 2 done , q ; r ) = p ∧ ∀ ω. p ⇒ wp ( L :if e 1 then e 2 else raise E , p ∧ t < at ( t , L ) , E ⇒ q ; r ) = p ∧ ∀ ω. p ⇒ wp ( e 1 , if result then wp ( e 2 , p ∧ t < at ( t , L )) else q , r )[ at ( x , L ) ← x ] TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  48. Loops wp ( loop e { invariant p variant t } , q ; r ) = p ∧ ∀ ω. p ⇒ wp ( L : e , p ∧ t < at ( t , L ); r ) where ω = the variables (possibly) modified by e Usual while loop wp ( while e 1 do { invariant p variant t } e 2 done , q ; r ) = p ∧ ∀ ω. p ⇒ wp ( L :if e 1 then e 2 else raise E , p ∧ t < at ( t , L ) , E ⇒ q ; r ) = p ∧ ∀ ω. p ⇒ wp ( e 1 , if result then wp ( e 2 , p ∧ t < at ( t , L )) else q , r )[ at ( x , L ) ← x ] TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  49. Loops wp ( loop e { invariant p variant t } , q ; r ) = p ∧ ∀ ω. p ⇒ wp ( L : e , p ∧ t < at ( t , L ); r ) where ω = the variables (possibly) modified by e Usual while loop wp ( while e 1 do { invariant p variant t } e 2 done , q ; r ) = p ∧ ∀ ω. p ⇒ wp ( L :if e 1 then e 2 else raise E , p ∧ t < at ( t , L ) , E ⇒ q ; r ) = p ∧ ∀ ω. p ⇒ wp ( e 1 , if result then wp ( e 2 , p ∧ t < at ( t , L )) else q , r )[ at ( x , L ) ← x ] TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  50. Functions wp ( fun ( x : τ ) → { p } e , q ; r ) = q ∧ ∀ x . ∀ ρ. p ⇒ wp ( e , True) wp ( rec f ( x 1 : τ 1 ) . . . ( x n : τ n ) : τ { variant t } = { p } e , q ; r ) = q ∧ ∀ x 1 . . . . ∀ x n . ∀ ρ. p ⇒ wp ( L : e , True) when computing wp ( L : e , True), f is assumed to have type ( x 1 : τ 1 ) → · · · → ( x n : τ n ) → { p ∧ t < at ( t , L ) } τ ǫ { q } TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  51. Functions wp ( fun ( x : τ ) → { p } e , q ; r ) = q ∧ ∀ x . ∀ ρ. p ⇒ wp ( e , True) wp ( rec f ( x 1 : τ 1 ) . . . ( x n : τ n ) : τ { variant t } = { p } e , q ; r ) = q ∧ ∀ x 1 . . . . ∀ x n . ∀ ρ. p ⇒ wp ( L : e , True) when computing wp ( L : e , True), f is assumed to have type ( x 1 : τ 1 ) → · · · → ( x n : τ n ) → { p ∧ t < at ( t , L ) } τ ǫ { q } TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  52. Function call Simplified using e 1 e 2 ≡ let x 1 = e 1 in let x 2 = e 2 in x 1 x 2 Assuming x 1 : ( x : τ ) → { p ′ } τ ′ ǫ { q ′ } we define wp ( x 1 x 2 , q ) = p ′ [ x ← x 2 ] ∧ ∀ ω. ∀ result . ( q ′ [ x ← x 2 ] ⇒ q )[ old ( t ) ← t ] TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  53. Function call Simplified using e 1 e 2 ≡ let x 1 = e 1 in let x 2 = e 2 in x 1 x 2 Assuming x 1 : ( x : τ ) → { p ′ } τ ′ ǫ { q ′ } we define wp ( x 1 x 2 , q ) = p ′ [ x ← x 2 ] ∧ ∀ ω. ∀ result . ( q ′ [ x ← x 2 ] ⇒ q )[ old ( t ) ← t ] TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  54. Outline 1 An intermediate language for program verification syntax, typing, semantics, proof rules 1 the Why tool 2 multi-prover approach 3 2 Verifying C and Java programs specification languages 1 models of program execution 2 3 A challenging case study TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  55. The Why Tool This intermediate language is implemented in the Why tool input = polymorphic first-order logic declarations + programs output = logical declarations + goals, in the syntax of the selected prover TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  56. Logical Declarations type t logic zero : t logic succ : t -> t logic le : t, t -> prop axiom a : forall x:t. le(zero,x) goal g : le(zero, succ(zero)) TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  57. Programs parameter x : int ref parameter g : b:t -> { x>=0 } t writes x { result=succ(b) and x=x@+1 } let h (a:int) (b:t) = { x>=0 } if !x = a then x := 0; g (succ b) { result=succ(succ(b)) } exception E exception F of int TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  58. Usage it is a compiler: why --coq f.why to produce a re-editable Coq file f why.v why --simplify f.why to produce a Simplify script f why.sx etc. the following provers/formats are supported: Coq, PVS, Isabelle/HOL, HOL-light, HOL4, Mizar Simplify, Ergo, SMT (Yices, CVC3, etc.), CVC-Lite, haRVey, Zenon there is a graphical user interface, gwhy TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  59. Example: Dijkstra’s Dutch national flag Goal: to sort an array where elements only have three different values (blue, white and red) TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  60. Algorithm 0 b i r n . . . to do. . . BLUE WHITE RED flag ( t , n ) ≡ b ← 0 i ← 0 r ← n while i < r case t [ i ] BLUE : swap t [ b ] and t [ i ]; b ← b + 1; i ← i + 1 WHITE : i ← i + 1 RED : r ← r − 1; swap t [ r ] and t [ i ] TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  61. Correctness proof we want to prove termination absence of runtime error = no array access out of bounds behavioral correctness = the final array is sorted and contains the same elements as the initial array TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  62. Modelization We model colors using an abstract datatype arrays using references containing functional arrays TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  63. An abstract type for colors type color logic blue : color logic white : color logic red : color predicate is color(c:color) = c=blue or c=white or c=red parameter eq color : c1:color -> c2:color -> {} bool { if result then c1=c2 else c1<>c2 } TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  64. Functional arrays type color array logic acc : color array, int -> color logic upd : color array, int, color -> color array axiom acc upd eq : forall a:color array. forall i:int. forall c:color. acc(upd(a,i,c),i) = c axiom acc upd neq : forall a:color array. forall i,j:int. forall c:color. i <> j -> acc(upd(a,j,c),i) = acc(a,i) TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  65. Array bounds logic length : color array -> int axiom length update : forall a:color array. forall i:int. forall c:color. length(upd(a,i,c)) = length(a) parameter get : t:color array ref -> i:int -> { 0<=i<length(t) } color reads t { result=acc(t,i) } parameter set : t:color array ref -> i:int -> c:color -> { 0<=i<length(t) } unit writes t { t=upd(t@,i,c) } TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  66. Array bounds logic length : color array -> int axiom length update : forall a:color array. forall i:int. forall c:color. length(upd(a,i,c)) = length(a) parameter get : t:color array ref -> i:int -> { 0<=i<length(t) } color reads t { result=acc(t,i) } parameter set : t:color array ref -> i:int -> c:color -> { 0<=i<length(t) } unit writes t { t=upd(t@,i,c) } TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  67. The swap function let swap (t:color array ref) (i:int) (j:int) = { 0 <= i < length(t) and 0 <= j < length(t) } let u = get t i in set t i (get t j); set t j u { t = upd(upd(t@,i,acc(t@,j)), j, acc(t@,i)) } 5 proofs obligations 3 automatically discharged by Why 2 left to the user (and automatically discharged by Simplify) TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  68. The swap function let swap (t:color array ref) (i:int) (j:int) = { 0 <= i < length(t) and 0 <= j < length(t) } let u = get t i in set t i (get t j); set t j u { t = upd(upd(t@,i,acc(t@,j)), j, acc(t@,i)) } 5 proofs obligations 3 automatically discharged by Why 2 left to the user (and automatically discharged by Simplify) TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  69. Function code let dutch flag (t:color array ref) (n:int) = let b = ref 0 in let i = ref 0 in let r = ref n in while !i < !r do if eq color (get t !i) blue then begin swap t !b !i; b := !b + 1; i := !i + 1 end else if eq color (get t !i) white then i := !i + 1 else begin r := !r - 1; swap t !r !i end done TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  70. Function specification let dutch flag (t:color array ref) (n:int) = { 0 <= n and length(t) = n and forall k:int. 0 <= k < n -> is color(acc(t,k)) } . . . { (exists b:int. exists r:int. monochrome(t,0,b,blue) and monochrome(t,b,r,white) and monochrome(t,r,n,red)) and permutation(t,t@,0,n-1) } TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  71. The monochrome property predicate monochrome(t:color array,i:int,j:int,c:color) = forall k:int. i<=k<j -> acc(t,k)=c TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  72. The permutation property logic permutation : color array, color array, int, int -> prop axiom permut refl : forall t:color array. forall l,r:int. permutation(t,t,l,r) axiom permut sym : forall t1,t2:color array. forall l,r:int. permutation(t1,t2,l,r) -> permutation(t2,t1,l,r) axiom permut trans : forall t1,t2,t3:color array. forall l,r:int. permutation(t1,t2,l,r) -> permutation(t2,t3,l,r) -> permutation(t1,t3,l,r) axiom permut swap : forall t:color array. forall l,r,i,j:int. l <= i <= r -> l <= j <= r -> permutation(t, upd(upd(t,i,acc(t,j)), j, acc(t,i)), l, r) TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  73. The permutation property logic permutation : color array, color array, int, int -> prop axiom permut refl : forall t:color array. forall l,r:int. permutation(t,t,l,r) axiom permut sym : forall t1,t2:color array. forall l,r:int. permutation(t1,t2,l,r) -> permutation(t2,t1,l,r) axiom permut trans : forall t1,t2,t3:color array. forall l,r:int. permutation(t1,t2,l,r) -> permutation(t2,t3,l,r) -> permutation(t1,t3,l,r) axiom permut swap : forall t:color array. forall l,r,i,j:int. l <= i <= r -> l <= j <= r -> permutation(t, upd(upd(t,i,acc(t,j)), j, acc(t,i)), l, r) TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  74. Loop invariant . . . init: while !i < !r do { invariant 0 <= b <= i and i <= r <= n and monochrome(t,0,b,blue) and monochrome(t,b,i,white) and monochrome(t,r,n,red) and length(t) = n and (forall k:int. 0 <= k < n -> is color(acc(t,k))) and permutation(t,t@init,0,n-1) variant r - i } . . . done TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

  75. Proof obligations 11 proof obligations loop invariant holds initially loop invariant is preserved and variant decreases (3 cases) swap precondition (twice) array access within bounds (twice) postcondition holds at the end of function execution All automatically discharged by Simplify! TYPES Summer School – August 30th, 2007 Jean-Christophe Filliˆ atre Why/Krakatoa/Caduceus

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend

Deductive Verification of Java programs Introduction with Algebraic Modeling and Multi-Prover

Deductive Verification of Java programs Introduction with Algebraic Modeling and Multi-Prover

Krakatoa Deductive Verification of Java programs Introduction with Algebraic Modeling and Multi-Prover Overview of Krakatoa Algebraic models Backend: the Why/Krakatoa platform Conclusions Claude March e Christine Paulin Jean-Christophe

636 views • 31 slides
Queens on a Chessboard an exercise in program verification Jean-Christophe Filli atre

Queens on a Chessboard an exercise in program verification Jean-Christophe Filli atre

Queens on a Chessboard an exercise in program verification Jean-Christophe Filli atre Krakatoa/Caduceus working group December 15th, 2006 Jean-Christophe Filli atre Queens on a Chessboard Krakatoa/Caduceus WG Introduction challenge for

569 views • 35 slides
Why3 What is why3? A platform for deductive program verification What is why3? A platform

Why3 What is why3? A platform for deductive program verification What is why3? A platform

Why3 What is why3? A platform for deductive program verification What is why3? A platform for deductive program verification Made by: Franois Bobot Martin Clochard Lon Gondelman Jean-Christophe Fillitre Claude

98 views • 9 slides
ROYAL SIGNALS LEADERS IN A DIGITAL AGE The CADUCEUS Programme A Corps for the 21 st Century

ROYAL SIGNALS LEADERS IN A DIGITAL AGE The CADUCEUS Programme A Corps for the 21 st Century

ROYAL SIGNALS LEADERS IN A DIGITAL AGE The CADUCEUS Programme A Corps for the 21 st Century Burning Platform 1 The Future Operating Environment Burning Platform 2 Information, not networks, is key Burning Platform 3 The STEM Environment The

353 views • 18 slides
Deductive Program Verification with W HY 3 Andrei Paskevich LRI, Universit Paris-Sud

Deductive Program Verification with W HY 3 Andrei Paskevich LRI, Universit Paris-Sud

Deductive Program Verification with W HY 3 Andrei Paskevich LRI, Universit Paris-Sud Toccata, Inria Saclay JCP 2016 1. A short look back 2 / 100 Introduction Software is hard. D ONALD K NUTH ... 1996: Ariane 5 explosion an

1.13k views • 100 slides
The Deductive Spreadsheet Iliano Cervesato Deductive Solutions iliano@deductivesolutions.com

The Deductive Spreadsheet Iliano Cervesato Deductive Solutions iliano@deductivesolutions.com

Carnegie Mellon University Pittsburgh, PA 6 July 2006 The Deductive Spreadsheet Iliano Cervesato Deductive Solutions iliano@deductivesolutions.com Preliminaries Requirements Model Functionalities Interface Experiments The

704 views • 45 slides
Deductive Program Verification with W HY 3 Andrei Paskevich LRI, Universit Paris-Sud

Deductive Program Verification with W HY 3 Andrei Paskevich LRI, Universit Paris-Sud

Deductive Program Verification with W HY 3 Andrei Paskevich LRI, Universit Paris-Sud Toccata, Inria Saclay http://why3.lri.fr/ejcp-2019 JCP 2019 Software is hard. D ONALD K NUTH 2 / 171 Ensure the absence of bugs Several

2k views • 171 slides
Logic as a Tool Chapter 2: Deductive Reasoning in Propositional Logic 2.1 Logical Deductive

Logic as a Tool Chapter 2: Deductive Reasoning in Propositional Logic 2.1 Logical Deductive

Logic as a Tool Chapter 2: Deductive Reasoning in Propositional Logic 2.1 Logical Deductive Systems: an overview Valentin Goranko Stockholm University October 2016 Goranko Deductive systems Goranko Deductive systems Logical consequence:

1.16k views • 28 slides
Deductive Program Verification Jean-Christophe Filli atre STOP r = 1 v = u s = 1 u

Deductive Program Verification Jean-Christophe Filli atre STOP r = 1 v = u s = 1 u

Deductive Program Verification Jean-Christophe Filli atre STOP r = 1 v = u s = 1 u = u + v s = s + 1 TEST r n u = 1 r = r + 1 TEST s r A Definition program mathematical + proof statement correctness

823 views • 56 slides
Logic as a Tool Chapter 2: Deductive Reasoning in Propositional Logic 2.1 Logical Deductive

Logic as a Tool Chapter 2: Deductive Reasoning in Propositional Logic 2.1 Logical Deductive

Logic as a Tool Chapter 2: Deductive Reasoning in Propositional Logic 2.1 Logical Deductive Systems: an overview Valentin Goranko Stockholm University October 2016 Goranko Deductive systems Logical consequence: A 1 , . . . , A n C

70 views • 5 slides
Efficient Deductive Methods for Program Analysis Harald Ganzinger Max-Planck-Institut f ur

Efficient Deductive Methods for Program Analysis Harald Ganzinger Max-Planck-Institut f ur

Efficient Deductive Methods for Program Analysis Harald Ganzinger Max-Planck-Institut f ur Informatik Introduction 2 program analysis from high-level inference rules complexity analysis through general meta-complexity theorems

451 views • 33 slides
An Introduction to Deductive Program Verification Jean-Christophe Filli atre CNRS Sixth

An Introduction to Deductive Program Verification Jean-Christophe Filli atre CNRS Sixth

An Introduction to Deductive Program Verification Jean-Christophe Filli atre CNRS Sixth Summer School on Formal Techniques May 2016 http://why3.lri.fr/ssft-16/ 1 / 145 Software is hard. Don Knuth why? wrong interpretation of

1.97k views • 145 slides
Deductive Program Verification Jean-Christophe Filli atre CNRS ITP 2018 Oxford, UK July 12,

Deductive Program Verification Jean-Christophe Filli atre CNRS ITP 2018 Oxford, UK July 12,

Deductive Program Verification Jean-Christophe Filli atre CNRS ITP 2018 Oxford, UK July 12, 2018 1 / 32 joint work with Fran cois Bobot Claude March e Guillaume Melquiond Andrei Paskevich 2 / 32 a question for programmers

991 views • 80 slides
Enhancing Automated Program Repair With Deductive Verification Xuan Bach D. Le 1 , Quang-Loc Le 2

Enhancing Automated Program Repair With Deductive Verification Xuan Bach D. Le 1 , Quang-Loc Le 2

Enhancing Automated Program Repair With Deductive Verification Xuan Bach D. Le 1 , Quang-Loc Le 2 , David Lo 1 , Claire Le Goues 3 1 Singapore Management University 2 Singapore University of Technology and Design 3 Carnegie Mellon University 1

368 views • 20 slides
Deductive Program Verification with Why3 Jean-Christophe Filli atre CNRS Tallinn January 15,

Deductive Program Verification with Why3 Jean-Christophe Filli atre CNRS Tallinn January 15,

Deductive Program Verification with Why3 Jean-Christophe Filli atre CNRS Tallinn January 15, 2013 http://why3.lri.fr/tallinn-2013/ 1 / 101 definition program verification + proof conditions specification 2 / 101 this is not new

1.18k views • 101 slides
An Improved Rule for While Loops in Deductive Program Verification Bernhard Beckert 1 Steffen

An Improved Rule for While Loops in Deductive Program Verification Bernhard Beckert 1 Steffen

An Improved Rule for While Loops in Deductive Program Verification Bernhard Beckert 1 Steffen Schlager 2 Peter H. Schmitt 2 1 Universit at Koblenz-Landau 2 Universit at Karlsruhe ICFEM 2005, Manchester Beckert, Schlager, Schmitt (

989 views • 56 slides
Formal Verification of Floating-Point programs Sylvie Boldo and Jean-Christophe Filli atre

Formal Verification of Floating-Point programs Sylvie Boldo and Jean-Christophe Filli atre

Formal Verification of Floating-Point programs Sylvie Boldo and Jean-Christophe Filli atre Montpellier June, 26th 2007 INRIA Futurs CNRS, LRI Existing tools Model and specification of FP numbers Examples Conclusion Motivations

410 views • 39 slides
t r ts t

t r ts t

trt ts tss ss s t r ts t

805 views • 59 slides
CSE 527 Computational Biology http://www.cs.washington.edu/527 Lecture 1: Overview &amp; Bio

CSE 527 Computational Biology http://www.cs.washington.edu/527 Lecture 1: Overview &amp; Bio

CSE 527 Computational Biology http://www.cs.washington.edu/527 Lecture 1: Overview &amp; Bio Review Autumn 2004 Larry Ruzzo He who asks is a fool for five minutes, but he who does not ask remains a fool forever. -- Chinese Proverb Related

525 views • 25 slides
Easy Software-Installation on Linux, Solaris, NetBSD, etc. using pkgsrc Hubert Feyrer &lt;

Easy Software-Installation on Linux, Solaris, NetBSD, etc. using pkgsrc Hubert Feyrer &lt;

Easy Software-Installation on Linux, Solaris, NetBSD, etc. using pkgsrc Hubert Feyrer &lt; hubertf@pkgsrc.org &gt; Easy Software-Installation on Linux, Solaris and NetBSD using pkgsrc p.1/34 Problems Installation of Open Source software on

550 views • 34 slides
Proof Technology for High-Assurance Runtime Systems Andrew Tolmach, Andrew McCreight, and the

Proof Technology for High-Assurance Runtime Systems Andrew Tolmach, Andrew McCreight, and the

Proof Technology for High-Assurance Runtime Systems Andrew Tolmach, Andrew McCreight, and the Programatica team WG2.8 08 1 Functional Languages for High- Assurance Applications Goal: rely on properties of functional languages to

774 views • 59 slides
Towards Secure Things, or How to Verify IoT Software with Frama-C Tutorial at ZINC 2018 Allan

Towards Secure Things, or How to Verify IoT Software with Frama-C Tutorial at ZINC 2018 Allan

Towards Secure Things, or How to Verify IoT Software with Frama-C Tutorial at ZINC 2018 Allan Blanchard, Nikolai Kosmatov, Fr ed eric Loulergue some slides authored by Julien Signoles Email: allan.blanchard@inria.fr,

1.79k views • 151 slides
Ownership, Pointer Arithmetic and Memory Separation Romain Bardou INRIA Saclay, France

Ownership, Pointer Arithmetic and Memory Separation Romain Bardou INRIA Saclay, France

Ownership, Pointer Arithmetic and Memory Separation Romain Bardou INRIA Saclay, France FTfJP2008 Ownership, Pointer Arithmetic, and Memory Separation 1 / 32 Introduction Jessie Ownership and Invariants Problems Our Approach Core Language

497 views • 32 slides
Formal proof of SCHUR conjugate function Toumazet Objectives and tools SCHUR Micaela Mayero 1

Formal proof of SCHUR conjugate function Toumazet Objectives and tools SCHUR Micaela Mayero 1

Formal Proof of conjugate function Butelle Hivert Mayero Formal proof of SCHUR conjugate function Toumazet Objectives and tools SCHUR Micaela Mayero 1 Frama-C Franck Butelle 1 Florent Hivert 2 Some combi- Frdric Toumazet 3 natorial

403 views • 28 slides

More recommend