Formal Verification with Ada 2012A Very Simple Case Study

Didier Willame

Ada DevRoom, FOSEDM 2014

February 1, 2014

Content

The ToyA Sandpile Simulator

A Quick ReminderFloyd-Hoare LogicDesign by Contract

Tool Suite by AdaCoreOverviewInstallationGet Started

Conclusion

References

Iconography

IntroductionDefinitions

I verificationI dynamic verification

I testing

I static verificationI manual reviewI formal verification - act of proving or disproving

the correctness of implemented algorithms with respectto given formal properties and using formal methodsof logic

1

The ToyA Sandpile Simulator - Overview

Figure 1: a flow on a sand dune

2

The ToyA Sandpile Simulator - Overview

Figure 2: a sandpile

3

The ToyA Sandpile Simulator - Physics

I open system - model in which sand grains enter regularly bya unique source (center of the ceiling) and drop out by the sides.

I conservative law - there is no spontaneous generation of sandgrains nor spontaneous annihilation.

I gravity force - each sand grain spontaneousely falls from topto bottom (vertical move).

I pressure - the stability of each sand grain, in contact directly ornot with the ground, is proportional to the number of grains justabove it.

I break - an horizontal move into a neighbour cell is possible,if this neighbour cell is empty, and if the pressure is high enough(toppling and cascade).

4

The ToyA Sandpile Simulator - Concepts

I model of sandpiles

I physics of granular materialsI dynamical systems displaying self-organized criticality

I applications

I models for avanchesI models for earthquakesI models for forest-firesI etc.

I simulator

I 2-D cellular automatonI update of cell state

I synchronousI depends of state of the neighboring cells (Von

Neumann of indeterminate range)I race conditions solved by random decision

5

The ToyA Sandpile Simulator - 1-to-2 race

I 1-to-2 race - possible horizontal move of 1 grainof sand, in the contiguous empty cells

I example:

Figure 3: an 1-to-2 race and falls

6

The ToyA Sandpile Simulator - 2-to-1 race

I 2-to-1 race - possible horizontal moves of 2 grainsof sand, in the same empty cell

I example:

Figure 4: a 2-to-1 race, falls and an horizontal move

7

The ToyA Sandpile Simulator - Conventions

Convention 1 (cell states)

I A = {0, 1, g, v}

I 0 - emptyI 1 - settled (by a grain of sand)I g - groundI v - vacuum

Convention 2 (neighborhood)

I [ left neighborhood ; current column ; right neighborhood ]

I neighborhood (N) ::= N column | column N | ε

I column ::=upper column

Alower column

| columnA | A

column| ε

8

The ToyA Sandpile Simulator - Rules

Rule 1 (no move)

I

[1 ; 1 ; 1

{1, g}

]→

[; 1 ;

]

Rule 2 (fall)

I

[; 1 ;

0

]→

[; 0 ;

1

]

9

The ToyA Sandpile Simulator - Rules

Rule 3 (left move)

I

1

0...

0 ; 1 ;...

{1, g}

· · ·>

1 ; 0 ;

Rule 4 (right move)

I

1... 0

; 1 ; 0...

{1, g}

· · ·>

; 0 ; 1

10

The ToyA Sandpile Simulator - Definitions

Definition 1 (state transitions)

I → deterministic transition (always occurs)

I · · ·> possible transitionI time dependency - during a computation loop,

the neighborhood can change (race issue)

I fragility - probability of breaking

σ( T (Pi,j) ) ≥ θ

I σ - sigmoid map (shift, slope)I T - triangular density function (width)I Pi,j - pressure on the celli,jI θ - threshold

11

The ToyA Sandpile Simulator - Definitions

Definition 2 (sigmoid map)

σ : R→ [−1, 1] : x 7→ x√1 + x2

Figure 5: the algebraic sigmoid (shift = 0.0 and slope = 1.0)

12

The ToyA Sandpile Simulator - Definitions

Definition 3 (triangular density function)

T : R→ [0, 1] : x 7→

1 + x if x ∈ [−1, 0[1− x if x ∈ [0, 1]0 else

F : R→ [0, 1] : x 7→

0 if x < −1

(1+x)2

2 if x ∈ [−1, 0[

1− (1−x)22 if x ∈ [0, 1]

1 if x > 1

F−1 : [0, 1]→ R : x 7→

{ √2x− 1 if x ∈ [0, 0.5[

1−√

2(1− x) if x ∈ [0.5, 1]

13

The ToyA Sandpile Simulator - Design

1 procedure Agit Main i s23 −− to beat out the rhythm ( the computing c y c l e s )4 Next Time : Time ;56 begin7 Agit Cel lu lar Automaton . Sta r t ;89 loop

10 Next Time := Clock + 0 . 2 ; −− to r e s t a r t the t imer1112 Agit Cel lu lar Automaton . Add A Grain ;13 Agit Cel lu lar Automaton . Next ;14 Agit Cel lu lar Automaton . Show ;1516 de lay u n t i l Next Time ;17 end loop ;1819 Agit Cel lu lar Automaton . Stop ;20 end Agit Main ;

Listing 1: The “main” procedure

14

The ToyA Sandpile Simulator - Design

1 type State Type i s new Natural range 0 . . 1 ;2 −− ’ empty ’ or ’ s e t t l e d ’34 protec t ed type Pro tec t ed Sta t e i s5 entry Set ( State : in State Type ) ;6 func t i on Get re turn State Type ;78 p r i v a t e9 Current State : State Type ;

10 Not Busy : Boolean := True ; −− the guard11 end Protec t ed Sta t e ;1213 Sta t e s : array ( X Coordinate ’ range , Y Coordinate ’ range )14 o f Pro t e c t ed Sta t e ;

Listing 2: The specification of the array of states

15

The ToyA Sandpile Simulator - Design

1 task type Ce l l i s2 entry Star t (X : in X Coordinate ;3 Y : in Y Coordinate ) ;4 entry Stop ;5 entry Drive Out Fal l And Break ;6 entry Make Fall ;7 end Ce l l ;89 type Ce l l Acce s s i s a c c e s s Ce l l ;

1011 Automaton : array ( X Coordinate ’ range ,12 Y Coordinate ’ range ) o f Ce l l Acc e s s ;

Listing 3: The specification of the array of cells

16

The ToyA Sandpile Simulator - Design

1 type Hor izonta l Move Side i s ( NO HORIZONTAL MOVE,2 LEFT,3 RIGHT ) ;4 type Horizontal Move Type i s5 record6 X : X Coordinate ;7 Y : Y Coordinate ; −− cur rent c e l l ( s e t t l e d )8 Side : Hor izonta l Move Side ;9 end record ;

1011 protec ted Pos s ib l e Break i s12 entry I n s e r t (Key : Sigmoid Type ;13 Horizontal Move : Horizontal Move Type ) ;14 procedure Reset ;15 procedure Make Breaks ;1617 p r i v a t e18 Horizontal Move Map : Poss ib le Break Package .Map;19 Not Busy : Boolean := True ; −− the guard20 end Poss ib l e Break ;

Listing 4: The specification of the list of break events

17

The ToyA Sandpile Simulator - Design

1 procedure Next i s2 begin3 Automaton Rendezvous . Reset ;4 f o r J in Y Coordinate ’ range loop5 f o r I in X Coordinate ’ range loop6 Automaton ( I , J ) . Drive Out Fal l And Break ;7 end loop ;8 end loop ;9 Wait Until End Of Computation ;

1011 Automaton Rendezvous . Reset ;12 f o r J in Y Coordinate ’ range loop13 f o r I in X Coordinate ’ range loop14 Automaton ( I , J ) . Make Fall ; −− v e r t i c a l move15 end loop ;16 end loop ;17 Wait Until End Of Computation ;1819 Pos s ib l e Break . Make Breaks ; −− h o r i z o n t a l moves20 end Next ;

Listing 5: The “next” procedure

18

A Quick ReminderFloyd-Hoare Logic - The Pioneers

Figure 6: Alan Mathison Turing (1912 - 1954)

I “Checking a Large Routine”, 1949 [4] (the first proofof a program)

19

A Quick ReminderFloyd-Hoare Logic - The Pioneers

Figure 7: Robert W. Floyd (1936 - 2001)

I “Assigning Meaning to Programs”, 1967 [2] (use oflogical assertions on flowcharts)

20

A Quick ReminderFloyd-Hoare Logic - The Pioneers

Figure 8: Sir Charles Antony Richard Hoare (1934 -)

I “An Axiomatic Basis for Computer Programming”,1969 [3] (set of inference rules)

21

A Quick ReminderFloyd-Hoare Logic - The Pioneers

Figure 9: Edsger Wybe Dijkstra (1930 - 2002)

I “Guarded Commands, Nondeterminacy and FormalDerivation of Programs”, 1975 [1] (total correctness)

22

A Quick ReminderFloyd-Hoare Logic - A Program Language

I imperative programming - flow of statements thatchange the program state (how to do)

I syntaxe ::= n | x | e op e

‘n’ denotes an integer constant‘x’ denotes a variable identifier

op ::= + | − | ∗ | = | 6= | < | > | and | or

s ::= skip |x := e |s;s |if e then s else s |while e loop s

in the conditional and the loop structures,

‘e’ denotes

{true when e 6= 0false when e = 0

23

A Quick ReminderFloyd-Hoare Logic - A Program Language

I semantics

I Σ - current program state

I Σ(x) - current value of the variable x

I [[e]]Σ - evaluation

I Σ, s Σ′, s′ - execution of the next step of s

I Σ, s ∗ Σ′, s′ - execution reaches Σ′ and remains s′

I Σ, s ∗ Σ′, skip - terminating execution (if Σ′ exists)

24

A Quick ReminderFloyd-Hoare Logic - Propositions about Programs (declarative programming)

I declarative programming - description of the desired results(what to do)

I syntax (FOL)

I P ::= true | false |e |P ∧ P | P ∨ P | ¬P | P ⇒ P |∀x, P | ∃x, P

‘e’ denotes an assertion written inthe imperative language

I semantics

I [[P ]]Σ - evaluation (valid or not)

I [[e]]Σ - defined by [[e]]Σ 6= 0

I Σ |= P - formula [[P ]]Σ is valid (Σ satisfies P )

I |= P - denotes that Σ |= P holds, for any state Σ25

A Quick ReminderFloyd-Hoare Logic - Inference Rules

I Hoare triple

{P}s{Q}

I validity - {P}s{Q} is valid, if s is executedin a state satisfying its precondition {P}, andif it terminates, then the resulting state satisfiesits post-condition {Q}.

{P}s{Q} is valid

iff

∀ Σ,Σ′, (Σ |= P ∧ Σ, s ∗ Σ′, skip)⇒ (Σ′ |= Q)

26

A Quick ReminderFloyd-Hoare Logic - Inference Rules

Rule 1 (empty statement axiom schema)

{P} skip {P}

27

A Quick ReminderFloyd-Hoare Logic - Inference Rules

Rule 2 (assignment axiom schema)

{P [x← e]} x:=e {P}

I P [x← e] denotes the assertion P in which each freeoccurrence of x has been replaced by the expression E

I {x+ 1 = 43} y := x+ 1 {y = 43} is valid

28

A Quick ReminderFloyd-Hoare Logic - Inference Rules

Rule 3 (composition rule)

{P}s1{Q} , {Q}s2{R}{P} s1;s2 {R}

29

A Quick ReminderFloyd-Hoare Logic - Inference Rules

Rule 4 (conditional rule)

{P ∧ (e 6= 0)}s1{Q} , {P ∧ (e = 0)}s2{Q}{P} if (e 6= 0) then s1 else s2 {Q}

30

A Quick ReminderFloyd-Hoare Logic - Inference Rules

Rule 5 (consequence rule)

P1 ⇒ P2 , {P2}s{Q2} , Q2 ⇒ Q1

{P1} s {Q1}

I This rule allows to strengthen the precondition {P2}and/or to weaken the postcondition {Q2}

31

A Quick ReminderFloyd-Hoare Logic - Inference Rules

Rule 6 (while rule for partial correctness)

{I ∧ (e 6= 0)}s{I}{I} while (e 6= 0) loop s {I ∧ (e = 0)}

I I is a loop invariant

32

A Quick ReminderFloyd-Hoare Logic - Inference Rules

Rule 7 (while rule for total correctness)

wf(≺) , {I ∧ (e 6= 0) ∧ (v = ξ)}s{I ∧ (v ≺ ξ)}{I} while (e 6= 0) loop s {I ∧ (e = 0)}

I wf(≺) is a well-founded order relation

I v is a loop variant

33

A Quick ReminderFloyd-Hoare Logic - Case Study (addition by incrementation)

Figure 10: a geometric interpretation of the addition

34

A Quick ReminderFloyd-Hoare Logic - Case Study (addition by incrementation)

1 module Incrementa lAddit ion23 use import i n t . Int4 use import r e f . Ref56 l e t a d d I t e r a t i v e ( x : i n t ) ( y : i n t ) : i n t7 r e q u i r e s { x >= 0 /\ y >= 0 }8 ensure s { r e s u l t = x + y }9 =

10 l e t s = r e f x in (∗ the sum ∗)11 l e t r = r e f y in (∗ the r e s t to add ∗)12 whi l e ! r > 0 do13 i n v a r i a n t { ! r >= 0 /\ ! s + ! r = x + y }14 (∗ the d i s c r e t e l i n e L : := r = ( x+y ) − s ∗)15 var i an t { ! r }16 (∗ the move on L must be downward ∗)17 s := ! s + 1 ;18 r := ! r − 119 done ;20 ! s21 end

Listing 6: The why3 proof of the incremental addition.35

A Quick ReminderFloyd-Hoare Logic - Why3

I why3 (INRIA, LRI and CNRS)

I http://why3.lri.fr (see the gallery of verified programs)I a platform for verification of algorithms, based on the

Floyd-Hoare LogicI IVC - Intermediate Verification Language (stepping

stone between source languages and reasoning engines- e.g., Alt-Ergo or Coq)

I VC - Verification Condition (e.g., precondition,postcondition, loop invariant or loop variant)

36

A Quick ReminderDesign by Contract

I Design by Contract (DbC)

I design approach requiring the definition of formal,precise and verifiable specifications, usingverification conditions

I mastering Floyd-Hoare logic helps develop relevantVC (what means correctness?)

37

Tool Suite by AdaCoreOverview

Figure 11: why3, a chain link

38

Tool Suite by AdaCoreOverview

Figure 12: gratprove, an integrated tool

39

Tool Suite by AdaCoreInstallation - Linux

1. dowload the packages from http://libre.adacore.com

I select the platformI x86 64-linux

I select the packagesI GNAT 2013 (development environment)I SPARK-HiLite GPL 2013 (proof environment)

2. install the packages (Makefile)I /usr/gnat

3. set enrironment variablesI PATH=$PATH:/usr/gnat/bin

40

Tool Suite by AdaCoreGet Started - Documentation

I Various Projects and Technical DocumentsI http://www.open-do.org/projects/hi-lite

I http://libre.adacore.com/developers/technical-papers-single

I SPARK 2014I http://www.spark-2014.org

I http://docs.adacore.com/spark2014-docs/html/ug/index.html

I GNATproveI http://hi-lite.forge.open-do.org/gpl-2012/html/ug/index.html

I http://docs.adacore.com/spark2014-docs/html/ug/gnatprove.html

41

Tool Suite by AdaCoreGet Started - Case Study (addition by incrementation)

1 package Incremental Add i s23 func t i on Incremental Add ( X, Y : Natural )4 re turn Natural5 with6 Pre => ( Y <= Natural ’ Last − X ) ,7 Post => ( Incremental Add ’ Result = X+Y ) ;89 end Incremental Add ;

Listing 7: “incremental add.ads” (the specifications)

42

Tool Suite by AdaCoreGet Started - Case Study (addition by incrementation)

1 package body Incremental Add i s2 func t i on Incremental Add ( X, Y : Natural )3 re turn Natural i s45 S : Natural := X; −− the sum6 R : Natural := Y; −− the r e s t to add7 begin89 whi l e ( R > 0 ) loop

10 pragma Loop Invar iant ( (R>=0) and (S+R=X+Y) ) ;11 pragma Loop Variant ( Decreases => R ) ;1213 S := S + 1 ;14 R := R − 1 ;15 end loop ;1617 re turn S ;1819 end Incremental Add ;20 end Incremental Add ;

Listing 8: “incremental add.adb” (the body)

43

Tool Suite by AdaCoreGet Started - Case Study (addition by incrementation)

1 with Incremental Add ;23 with Ada . Text IO , Ada . Integer Text IO ;4 use Ada . Text IO , Ada . Integer Text IO ;56 procedure Add i s7 X : Natural ;8 Y : Natural ;9 Result : Natural ;

10 begin11 put ( ”X: ” ) ; get ( X ) ;12 put ( ”Y: ” ) ; get ( Y ) ;1314 Result := Incremental Add . Incremental Add ( X, Y ) ;15 Put ( ”X + Y =” ) ;16 Put Line ( Natural ’ Image ( Result ) ) ;1718 except ion19 when Cons t ra in t Er ro r =>20 Put Line ( ” over f l ow ! ” ) ;21 end Add ;

Listing 9: “add.adb” (the main unit)44

Tool Suite by AdaCoreGet Started - Case Study (addition by incrementation)

1 p r o j e c t Add i s23 f o r Source Di r s use ( ”add/ s r c /∗∗” ) ;45 f o r S o u r c e F i l e s use ( ” incrementa l add . adb” ,6 ” incrementa l add . ads” ,7 ”add . adb” ) ;89 f o r Object Dir use ” . / add/ obj /” ;

10 f o r Exec Dir use ” . / add/ bin /” ;11 f o r Main use ( ”add . adb” ) ;1213 package Compiler i s14 f o r De fau l t Swi t che s ( ”ada” ) use ( ”−gnat12 ” ) ;15 end Compiler ;1617 end Add ;

Listing 10: “add.gpr” (the GPS script)

45

Tool Suite by AdaCoreGet Started - Case Study (addition by incrementation)

I the gnatprove invocation

> gnatprove -Padd.gpr --report=all

I the output (the phases)

Phase 1 of 3: frame condition computation ...

Phase 2 of 3: translation to intermediate language ...

Statistics logged in ./add/obj/gnatprove/gnatprove.out

(detailed info can be found in ./add/obj/gnatprove/*.alfa)

Phase 3 of 3: generation and proof of VCs ...

46

Tool Suite by AdaCoreGet Started - Case Study (addition by incrementation)

I the output (the analysis)

analyzing Incremental_Add.Incremental_Add, 9 checks

incremental_add.adb:10:10: info: loop invariant initialization proved

incremental_add.adb:10:10: info: loop invariant preservation proved

incremental_add.adb:10:47: info: overflow check proved

incremental_add.adb:10:51: info: overflow check proved

incremental_add.adb:11:10: info: loop variant proved

incremental_add.adb:13:17: info: overflow check proved

incremental_add.adb:14:17: info: range check proved

incremental_add.ads:7:14: info: postcondition proved

incremental_add.ads:7:42: info: overflow check proved

analyzing precondition for Incremental_Add.Incremental_Add, 1 checks

incremental_add.ads:6:34: info: overflow check proved

47

Tool Suite by AdaCoreGet Started - Case Study (addition by incrementation)

I the “gnatprove.out” file

Subprograms in SPARK : 50% (1/2)

... already supported : 50% (1/2)

... not yet supported : 0% (0/2)

Subprograms not in SPARK : 50% (1/2)

Subprograms not in SPARK due to (possibly more than one reason):

exception : 50% (1/2)

Subprograms not yet supported due to (possibly more than one reason):

(none)

Units with the largest number of subprograms in SPARK:

incremental_add : 100% (1/1)

Units with the largest number of subprograms not in SPARK:

add : 100% (1/1)

48

Conclusion

I current statusI theoretical basis to develop relevant VCI complex and funny enough toy to make exciting

exercises

I next stepsI make available on the internet the toy’s source codeI complete the source code of the toy with relevant VCI start a blog to discuss the relevance of the used VCI use and/or develop with Jacob Sparre Andersen,

the Jacob’s tutorial about the design by contract

49

Thanks!

Any questions?

References

[1] Edsger W. Dijkstra, Guarded commands, nondeterminacy andformal derivation of programs, Commun. ACM 18 (1975), no. 8,pp. 453–457.

[2] Robert W. Floyd, Assigning meaning to programs, Proceedings ofSymposium on Applied Mathematics Mathematical Aspects ofComputer Science (1967), no. 19, pp. 19–32.

[3] C. A. R. Hoare, An axiomatic basis for computer programming,Commun. ACM 12 (1969), no. 10, pp. 576–580.

[4] A. M. Turing, Checking a large routine, EDSAC InauguralConference, Report of a Conference on High Speed AutomaticCalculating machines, Mathematical Laboratory, Cambridge, 24June 1949, pp. 67–69.

Iconography

fig. 1 : John K. Nakata (Landslides in art part 11)fig. 6 : faetopia.comfig. 7 : www-cs.stanford.edufig. 8 : Rama (en.wikipedia.org)fig. 9 : Hamilton Richards (en.wikipedia.org)fig. 11 : Jean-Christophe Filliatre (Deductive Program

Verification with Why3, 2013)fig. 12 : Hi-Lite (project description, 2013)fig. 13 : Yale Babylonian Collectionfig. 14 : University of Pennsylvaniafig. 2, 3, 4, 5 and 10 : Didier Willame (Argonauts-IT Ltd)

Figure 13: Old Babylonian clay tablet (circa 1800 - 1600 BCE),showing a computation of

√2

Figure 14: fragment of Euclid’s Elements (Oxyrhynchuspapyrus I 29, circa 75 - 125 A.D.), showing a sketch of the proofof the pythagorean theorem