5: The Hoare

I a to rigorously reason about the correctness of programs I usage to prove correctness “by hand” I difficult and error prone I doable for small algorithms I unfeasible for large programs I learning goals I learn the rules of Hoare Logic I apply them to tiny algorithms “by hand” I use a tool applying them for automatic verification (→ section on SPARK) I The goal behind the goals: I understand how tool-based program verification works (without knowing the HL, you could not reasonably use such tools).

–206– S. Lucks Security Engineering 5: Hoare Logic History

Floyd, 1967: Usage of asserts as a tool for proofs of correctness Hoare, 1969: Axiomatic definition of the program correctness via “Hoare-Triples”:

{Precond.} Program(-fragment) {Postcond.}

Distinction between partial and total correctness Dijkstra 1975: “Weakest precondition” as the foundation for automatically generated proofs – though not with using the computers available in 1975

–207– S. Lucks Security Engineering 5: Hoare Logic partial and total correctness

I Consider a program S, and assume its precondition is satisfied. Notation as a “Hoare Triple”:

{Precondition} S {Postcondition}.

I S is partially correct, if, when it delivers a result, the result satisfies the postcondition. S may not always deliver a result. I S is totally correct, if it s partially correct and it always terminates (without raising an exception – though Hoare didn’t consider exception in 1969). I What S does if its precondition is not satisfied, doesn’t affect correctness.

–208– S. Lucks Security Engineering 5: Hoare Logic Examples

Which of the examples is (a) totally correct, (b) partially but not totally correct, or (c) even partially incorrect?

1. {X = 1} null; {X = 0}. 2. {True} X := 1; {X = 0}. 3. {X = 1} null; {X = 1}. 4. {X = 1} loop null; end loop; {X = 0}. 5. {True} X := 1; {X = 1} 6. {False} X := 1; {X = 0}

–209– S. Lucks Security Engineering 5: Hoare Logic Mathematical Proofs

I New proofs are examined carefully when (and even before) they are published (“peer review”). I Sometimes, people find flaws in proofs published many years before.

–210– S. Lucks Security Engineering 5: Hoare Logic Proofs in Computer Science

I Proof of correctness for Algorithms and Communication Protocols: “peer review”, as in mathematics. I Proofs of correctness for software (implementation of algorithms): no “peer review”, hardly any incentive. I The proofs are often not more easy to understand than the source code. I If the computer can’t verify the proofs – who else will do?

–211– S. Lucks Security Engineering 5: Hoare Logic Correctness

{X ≥ 1} while X > 1 loop if X mod 2 = 0 then X := X / 2; else X := 3∗X + 1; end if; end loop; {X = 1}

I Partial correctness: Yes We Can! I Total correctness: Unsolved problem from mathematics. I Note: Our “Integers” are mathematical (elements of Z).

–212– S. Lucks Security Engineering 5: Hoare Logic Surprise?

I Given integers X and Y, search for statement(-sequence) S with

{True} S {Y = max(X,Y)}.

Which of these statement(-sequence)s are correct? I Y := X; I X := Y; I X := 0; I if X > Y then X := Y; end if; I if X > Y then Y := X; end if; I X := 0; Y := 0; Guess which solution is desired? ;-)

–213– S. Lucks Security Engineering 5: Hoare Logic The (perhaps) correct Specification

I Consider

{Xold = X ∧ Yold = Y} S {Y = max(Xold, Yold)}.

with S=”if X > Y then Y := X; end if;” I This is the excepted behaviour. Observe the “gnost variables”, such as X old and Y old that represent the “old” values of X and Y . I Also correct, S= “if X > Y then Y := X; else X := Y end if;” I The defense against changing X:

{Xold = X ∧ Yold = Y} S {X = Xold ∧ Y = max(Xold, Yold)}.

I Classical Hoare logic requires to specify all variables which didn’t change. This scales extremely bad for larger applications! I Tools avoid that need – e.g., SPARK’s data flow analysis.

–214– S. Lucks Security Engineering 5: Hoare Logic Case study: Sort array A[1..N]

I 1st idea: define S(A) = A[1] ≤ A[2] ≤ · · · A[N]. (S(A)= ”A is sorted”).

{True} Sort(A); {S(A)}

I This is too weak! (why?) What else do we need? I 2nd idea: P(Aold, A)= ”A is a permutation of Aold”;

{True} Sort(A); {S(A) ∧ P(Aold, A)} I This does what we want. But how shall we actually formalize P(Aold, A)?

–215– S. Lucks Security Engineering 5: Hoare Logic 5.1: Building Blocks and a Toy Language

I First order logic I Two and four other rules to define a “toy language” . . . but a real language can be derived from this I Logical deduction (application of rules and axioms) to define new rules – and to prove them!

–216– S. Lucks Security Engineering 5: Hoare Logic 5.1: Building Blocks Rule of Composition

P S1 P {P} S1 {R}, {R} S2 {Q} R S1 {P} S ; S ; {Q} R S2 1 2 S2 Q Q

Statements S1 and S2 can merge into S1; S2 if the postcondition of S1 is the same as the precondition for S2. Example:

I S1==={X ≥ 1}X := X + 1; {X ≥ 2}

I S2==={X ≥ 2}X := X/2; {X ≥ 1}

–217– S. Lucks Security Engineering 5: Hoare Logic 5.1: Building Blocks How all rules look like, in general

H1

H2 H1, H2,..., Hn C C

Hn

I “Conclusion” C

I “Hypothesis” H1 ∧ H2, ∧ · · · , ∧Hn

“”: A rule with (H1 ∧ H2, ∧ · · · , ∧Hn) = true.

–218– S. Lucks Security Engineering 5: Hoare Logic 5.1: Building Blocks Rule/Axiom 1: Empty Statement

P True null; {P}null; {P}

P

The axiom ensures that the null; statement doesn’t change the state of the program. Whatever holds true before null; also holds true afterwards, and vice versa.

–219– S. Lucks Security Engineering 5: Hoare Logic 5.1: Building Blocks Axiom 2: Assignment

P[E−>v] True v := E {P[Expr → v]} v := Expr; {P}

P

If P and Expr are expressions, “P[Expr → v]” denotes the expression where all “free” occurrences of v in P are replaced by Expr.

Example:

{2 ∗ X = A}X := 2 ∗ X; {X = A} P === X = A; v === X If the equation X = A shall hold after the assignment, Expr === 2 ∗ X then the equation 2 ∗ X = A must P[Expr → v] === 2 ∗ X = A hold before.

–220– S. Lucks Security Engineering 5: Hoare Logic 5.1: Building Blocks Rule 3: Composition (We have seen that before)

P S1 P {P} S1 {R}, {R} S2 {Q} R S1 {P} S ; S ; {Q} R S2 1 2 S2 Q Q

–221– S. Lucks Security Engineering 5: Hoare Logic 5.1: Building Blocks Rule 4: IF-THEN-ELSE

P

B no yes P ⋀¬ B P ⋀ B {P, B} S1 {Q}, {P, ¬B} S2 {Q} S2 S1 {P} if B then S1; else S2; end if ; {Q}

Q Q Q

–222– S. Lucks Security Engineering 5: Hoare Logic 5.1: Building Blocks Rule 5: WHILE

P ¬ B

P ⋀ B {P, B} S {P} S {P} while B loop S; end loop; {P, ¬B}

P P ⋀¬ B

–223– S. Lucks Security Engineering 5: Hoare Logic 5.1: Building Blocks Rule 6: Conclusion

P ⇒

P' P P ⇒ P0, {P0} S {Q0}, Q0 ⇒ Q S ⇒ S {P} S {Q} Q' Q ⇒

Q

–224– S. Lucks Security Engineering 5: Hoare Logic 5.1: Building Blocks Deriving new rules (1)

Conclusion: P ⇒ P0, {P0} S {Q0}, Q0 ⇒ Q {P} S {Q} Abstract Logic: P ⇒ P and Q0 ⇒ Q. Postcondition Weakening Precondition Strengthening

{P} S {Q0}, Q0 ⇒ Q P ⇒ P0, {P0} S {Q} {P} S {Q} {P} S {Q}

–225– S. Lucks Security Engineering 5: Hoare Logic 5.1: Building Blocks Deriving new rules (2)

Rule of Composition:

{P} S1 {R}, {R} S2 {Q} {P} S1; S2; {Q}

Conclusion: P ⇒ P0, {P0} S {Q0}, Q0 ⇒ Q {P} S {Q} extended Rule of Composition:

0 0 {P} S1 {R}, {R } S2 {Q}, R ⇒ R {P} S1; S2; {Q}

–226– S. Lucks Security Engineering 5: Hoare Logic 5.1: Building Blocks Our Toy Language

Ada-Code Fragments:

I variables of a (mathematical) integer type I expressions I integer I boolean I statements: I null; I assignment: variable := integer-expr I sequence of statements I control structures: I if boolean-expr then statement else statement end if; I while boolean-expr loop statement end loop

–227– S. Lucks Security Engineering 5: Hoare Logic 5.1: Building Blocks 5.2: The WHILE rule is special

{P, B} S {P} {P} whileB loop S; end loop ; {P, ¬B}

1. WHILE separates partial from complete correctness. Note that the language we currently have does not support (recursive) subprograms. 2. WHILE-loops are difficult to prove correct, both manually and (especially) automatically.

–228– S. Lucks Security Engineering 5: Hoare Logic 5.2: WHILE An important tool to analyze loops

P is an invariant of a loop, if it holds before and after each iteration of the loop.

Example:

{Y = 0} whileX > 0 loop Y := Y +1; X := X −1; end loop; {Y = Xold}

What invariant would you use?

–229– S. Lucks Security Engineering 5: Hoare Logic 5.2: WHILE Variant Another tool to analyze loops – for total correctness

An integer expression V is a variant of a loop, 1. if V ≥ 0 and 2. if V decreases during each iteration. Example:

{Y = 0} whileX > 0 loop Y := Y +1; X := X −1; end loop; {Y = Xold}

What is the variant of the loop?

–230– S. Lucks Security Engineering 5: Hoare Logic 5.2: WHILE While-Loop Proof

Example: How would you prove the following code correct? How would you prove it terminates?

while X > 0 loop Y := Y + 1; X := X − 1; end loop;

–231– S. Lucks Security Engineering 5: Hoare Logic 5.2: WHILE 5.3: Verifying Code Fragments

How would you prove the following claim?

{X = Xold, Y = Yold} T := X; X := Y ; Y := T ; {X = Yold, Y = Xold}

–232– S. Lucks Security Engineering 5: Hoare Logic 5.3: Verifying Code Recall the Rules Assignment, Composition, Postcondition Weakening

0 0 True {P} S1 {R}, {R} S2 {Q} {P} S {Q }, Q ⇒ Q {P[Expr→v]} v:=Expr; {P} {P} S1; S2; {Q} {P} S {Q}

The proof:

{X = Xold, Y = Yold} T := X; {T = Xold, X = Xold, Y = Yold}

{T = Xold, X = Xold, Y = Yold} X := Y ; {T = Xold, X = Yold, Y = Yold}

{T = Xold, X = Yold, Y = Yold} Y := T ; {T = Xold, X = Yold, Y = Xold}

{T = Xold, X = Yold, Y = Xold} =⇒ {X = Yold, Y = Xold}

–233– S. Lucks Security Engineering 5: Hoare Logic 5.3: Verifying Code Much Ado about Nothing?

I Much Ado, to prove a triviality. I Manual proofs are error-prone

–234– S. Lucks Security Engineering 5: Hoare Logic 5.3: Verifying Code Searching for possible proof strategies Something, a computer can do, (mostly) without human intervention

The claim {X = 5} X := 2 ∗ x; {X > 0} is correct, but not tight. I.e., we could replace the precondition by a weaker one, or the postcondition by a stronger one.

There are several weaker preconditions and several stronger postconditions. Which one should the computer choose? The two extreme cases are the following:

Weakest Precondition:X > 0 Strongest Postcondition:X = 10

–235– S. Lucks Security Engineering 5: Hoare Logic 5.3: Verifying Code Strongest Postcondition

Theorem: Let S be a program and P a precondition. Then there exists a unique Q∗ with I {P} S {Q∗} ∗ I and for all Qi with {P} S {Qi} it holds that Q ⇒ Qi.

Proof (Sketch): Assume Q1 and Q2 are both postconditions:

{P} S {Q1} and {P} S {Q2}.

Then Q0 = Q1 ∧ Q2 is also a postcondition:

{P} S {Q0}.

Furthermore, Q0 is at least as strong as either Q1 or Q2:

Q0 → Q1 and Q0 → Q2.

Definition:Q ∗ the strongest postcondition.

–236– S. Lucks Security Engineering 5: Hoare Logic 5.3: Verifying Code Weakest Precondition Theorem: Let S be a program amd Q a postcondition. there exists a unique P∗ with I {P∗} S {Q} ∗ I for all Pi with {Pi} S {Q} it holds that Pi ⇒ P . Proof: (similar to the strongest postcondition case)

Definition:P ∗ is the weakest precondition.

Remark 1: Though each of the strongest postcondition Q∗ and the weakest precondition P∗ is logically unique, but it can be represented by different expressions. E.g., the the following expressions are logically the same: “X ≥ 0”, “X = abs(X)”, and “X ≥ 1 ∨ X = 0”. Remark 2: In practice, the weakest precondition is preferred over the strongest postcondition.

–237– S. Lucks Security Engineering 5: Hoare Logic 5.3: Verifying Code Weakest precondition calculus For all (deterministic) programs S, the following rules/laws hold:

Miracles excluded: WP(S, False) = False Validity rule: WP(S, True) = True

Conjunction and disjunction:

WP(S, Q) ∧ WP(S, R) = WP(S, Q ∧ R)

WP(S, Q) ∨ WP(S, R) = WP(S, Q ∨ R)

Conclusions:

Fur¨ Q → R: WP(S, Q) → WP(S, R)

–238– S. Lucks Security Engineering 5: Hoare Logic 5.3: Verifying Code How the computer computes WP(·, ·)

Empty Statement: WP(null; , P) = P Assignment: WP(X := Expr; , Q) = Q[Expr → X] Composition: WP(S; T ; , Q) = WP(S, WP(T , Q)) IF-THEN-ELSE:

WP(ifB then S else T end if; , Q) = (B ⇒ WP(S,Q)) ∧ (¬B ⇒ WP(T,Q))

WHILE: WP(whileB loop S end while; , Q) = ???

–239– S. Lucks Security Engineering 5: Hoare Logic 5.3: Verifying Code The woe with WHILE

WP(whileB loop S end while; , Q) = ???

We write cnt(i) for “the loop is iterated exactly i times”, and cnt(∞) for “the loop runs forever”. Write Si for i repetions of S (e.g, S3 = S; S; S;). Then   _ i ??? = cnt(∞) ∨  (cnt(i) ∧ WP(S ; , Q)) i∈{0,1,2,3,4,...} This gives us the WP – but it is hardly useful for our purpose.

–240– S. Lucks Security Engineering 5: Hoare Logic 5.3: Verifying Code WHILE: What to do in practice Consider a loop

{P} whileB loop S end while {Q}

with a precondition {P} and a postcondition {Q}. We need “cut the loop” by a I. We require it to satisfy: 1.P ⇒ I (“I is true before the loop”), 2.I ∧ B → WP(S, I) (“I remains intact under iteration of the loop body”), and 3.I ∧¬ B → Q (“When I holds at loop termination, the postcondition holds”). People usually write a loop with an invariant as

{P} while {I} B loop S end while {Q}

But note that I must hold even if B is false from the beginning. It would be more clear to write {P}{I} whileB loop S {I} end while {Q}.

–241– S. Lucks Security Engineering 5: Hoare Logic 5.3: Verifying Code Examples Assignment, Composition, IF-THEN-ELSE Assignment:

WP(“c := a + b;00 , c = 6) = a + b = 6.

Composition:

WP(“b := a; c := a + b;00 , c = 6) = WP(“b := a;00 , a + b = 6) = a + a = 6.

(logically the same as a = 3).

IF-THEN-ELSE:

WP(“if X >= 0 then null else X := −X; end if;00 , X > 0) = ...

–242– S. Lucks Security Engineering 5: Hoare Logic 5.3: Verifying Code Example WHILE

{Nold = N > 0, M=M ≥ 0} R := 1; S := 0; {Invariant} whileS < M loop R := R ∗ N; S := S + 1; {Invariant} end loop; {Nold = N, Mold = M, R = NM}

–243– S. Lucks Security Engineering 5: Hoare Logic 5.3: Verifying Code How to find loop invariants?

{P, B} S {P} {P} while B loop S; end loop; {P, ¬B}

I The invariant P should hold before the loop, and after each loop iteration. I Informally, it describes that I what has been achieved by the loop iterations so far I together with what will be achieved by future loop iterations I will provide the claimed result.

–244– S. Lucks Security Engineering 5: Hoare Logic 5.3: Verifying Code Back to the example!

Rule of thumb: {Nold = N > 0, Mold = M ≥ 0} I Take the postcondition and R := 1; S := 0; I describe it as being dependent {Invariant} from the local variables (as whileS < M loop opposed from the input R := R ∗ N; parameters), S := S + 1; I such that when leaving the {Invariant} loop, the invariant is the same end loop; as the postcondition. {Nold = N, Mold = M, R = NM} I Here: Invariant := R = NS.

–245– S. Lucks Security Engineering 5: Hoare Logic 5.3: Verifying Code Continuing the example

{Nold = N > 0, Mold = M ≥ 0} R := 1; I Are we done? S := 0; Not quite. We leave the S I {R = N } while loop when while S < M loop ¬(S < M) holds. R := R ∗ N; This is equivalent to S := S + 1; I S ≥ M, but {R = NS} end loop; I we would need S = M. {Nold = N, Mold = M, R = NS, S ≥ M}

–246– S. Lucks Security Engineering 5: Hoare Logic 5.3: Verifying Code Finishing the example

I Are we done? old old {N = N > 0, M = M ≥ 0} I Not quite. We leave the R := 1; loop when ¬(S < M) S := 0; holds. {R = NS} I This is equivalent to while S < M loop S ≥ M, but R := R ∗ N; we actually need S := S + 1; I S = M. {R = NS} end loop; I The simplest way to do {Nold = N, Mold = M, R = NS, S = M} so is to write “while S 6= M”.

–247– S. Lucks Security Engineering 5: Hoare Logic 5.3: Verifying Code Two programs to compute the factorial. Which Invariants would you choose?

{X = N, Y = 1} {X = 0, Y = 1} while X 6= 0 loop while X < N loop Y := Y ∗ X; X := X + 1; X := X − 1; Y := Y ∗ X; end loop; end loop; {X = 0, Y = N!} {X ≥ N, Y = N!}

–248– S. Lucks Security Engineering 5: Hoare Logic 5.3: Verifying Code Total Correctness

I to claim total correctness, we write

[P] S [Q]

I this holds, if the partial correctness is given

{P} S {Q}

I and S always terminates (assuming P).

–249– S. Lucks Security Engineering 5: Hoare Logic 5.3: Verifying Code Rules for programs without loops No surprise!

I Replace “{...}” by “[...]” in all axioms and rules – except for WHILE. (We later will elaborate on the assignment axiom . . . ) I If S is without a WHILE loop, this trivially gives {P} S {Q} [P] S [Q]

–250– S. Lucks Security Engineering 5: Hoare Logic 5.3: Verifying Code WHILE

Consider the following proof: 1. {P} null; {P} (Axiom) 2. {P, P} null; {P} (Precondition Strengthening) 3. {P, P} whileP loop null ; end loop; {P, ¬P} (WHILE) Let us try the easy way: If we just replace “{...}” by “[...]”, we get a a contradition:

[P, P] whileP loop S end loop;[P, ¬P]

No suprise – our loop doesn’t terminate, and our replacement rule is plain wrong for WHILE loops!

–251– S. Lucks Security Engineering 5: Hoare Logic 5.3: Verifying Code WHILE (2)

To prove the termination of whileB loop S end loop; one proves the existence of an integer V ≥ 0, which decreases with every iteration of S. This integer V is the variant.

–252– S. Lucks Security Engineering 5: Hoare Logic 5.3: Verifying Code Back to the old example

{Nold = N > 0, Mold = M ≥ 0} R := 1; S := 0; {R = NS} while S < M loop I What could be the variant? R := R ∗ N; S := S + 1; {R = NS} end loop; {Nold = N, Mold = M, R = NS, S = M}

–253– S. Lucks Security Engineering 5: Hoare Logic 5.3: Verifying Code The assignment: take heed!

For the assignment, we simply replace “{...}” by “[...]”. I.e.,

{P[Expr → v]} v:=Expr; {P}

becomes

[P[Expr → v]] v:=Expr; [P]

which describes the expected behaviour well.

BUT: This assumes that the computation of “Expr” always terminates. For more general languages, which, e.g., allow to call recursive functions in expressions, this is plain wrong.

–254– S. Lucks Security Engineering 5: Hoare Logic 5.3: Verifying Code How to deal with errors e.g., when computing X/Y and Y = 0

1. Just ignore the problem I X/0 is an arbitrary number, who cares? I But then, why do you need a proof at all? 2. Raise an exception / an error I may be OK for partial but not for total correctness 3. Continue with some special value I X/0 may be “Not A Number”, I as will be (X/0) ∗ 0, (X/0) + A,... 4. Defend against such cases in advance I X/Y enforces Y 6= 0 as an additional precondition I (→ SPARK).

–255– S. Lucks Security Engineering 5: Hoare Logic 5.3: Verifying Code 5.4: Extending the Toy Language IF-THEN-(no-ELSE)

Syntax: I if B then S end if; Semantic: I if B then S else null; end if;

–256– S. Lucks Security Engineering 5: Hoare Logic 5.4: Extending Toy Language Justification

IF-THEN-ELSE:

{P, B} S1 {Q}, {P, ¬B} S2 {Q} {P} if B then S1 else S2 end if ; {Q}

Set S2 = null;:

{P, B} S1 {Q}, {P, ¬B} null; {Q} {P} if B then S1 else null; end if ; {Q} Empty Statement:

{P, B} S {Q} (P ∧¬ B) ⇒ Q {P} if B then S end if ; {Q}

Wow! That was really easy!

–257– S. Lucks Security Engineering 5: Hoare Logic 5.4: Extending Toy Language REPEAT-UNTIL

Syntax: I repeat S until B; (∗ this is Pascal ∗) Semantic: I S while (¬ B) loop S end loop; –– this is Ada

–258– S. Lucks Security Engineering 5: Hoare Logic 5.4: Extending Toy Language Justification

WHILE: {P, B} S {P} {P} while B loop S end loop; {P, ¬B} This gives {P} S {Q}, {Q, ¬B} S {Q} {P} repeat S until B; {Q, B}

–259– S. Lucks Security Engineering 5: Hoare Logic 5.4: Extending Toy Language FOR-loops

Syntax: for I in A .. B loop S end loop; Simple semantic for FOR-loops: I :=A; while I ≤ B loop S I := I + 1; end loop;

–260– S. Lucks Security Engineering 5: Hoare Logic 5.4: Extending Toy Language Semantic Problem – FOR-loops are Difficult There is a problem with our simple semantic: I FOR-loops should always terminate, unlike WHILE-loops. (There is an obvious variant . . . ). I But our simple semantic definition allows to write FOR-loops to runing forever. Example: {True} for I in 1 .. 1 loop I := I − 1; end loop; {2 = 1} ¸ I Note: This is the toy language and not Ada. For Ada the assignment to a loop parameter would produce a compiler error. I With a stricter definition and some constraints (e.g., prohibit assigning a value to the loop counter), the variant for for I in A .. B loop S; end loop; is just B − I + 1. I Many old programming languages (e.g., Algol-60) lack a sufficiently strict semantic for FOR-loops . . . I . . . and many new programming languages also (e.g., Java).

–261– S. Lucks Security Engineering 5: Hoare Logic 5.4: Extending Toy Language Arrays Now it gets even more difficult!

Recall the assignment rule:

{P[Expr → v]} v := Expr; {P}

For assignments related to an array A(...), we get

{P[Expr2 → A(Expr1)]} A(Expr1) := Expr2; {P}.

So where is the problem?

–262– S. Lucks Security Engineering 5: Hoare Logic 5.4: Extending Toy Language Aliasing Recall {P[Expr2 → A(Expr1)]} A(Expr1) := Expr2; {P}. and define I P as “(X = Y ) ∧ (A(Y ) = 0)”, I Expr1 as “X” and I Expr2 as “1”.

Then P[Expr2 → A(Expr1)] reduces to P[1 → A(X)]. and this is just P, since P contains no expression A(X). Thus: {X = Y,...} A(X) := 1; {A(Y) = 0}. Ouch! –263– S. Lucks Security Engineering 5: Hoare Logic 5.4: Extending Toy Language Aliasing

A(X) and A(Y ) are two different expressions, but can denote the same element of A. In that case, changing either actually changes the other one.

–264– S. Lucks Security Engineering 5: Hoare Logic 5.4: Extending Toy Language Hoare’s solution

An assignment A(Expr1) := Expr2 is treated as (Expr1) ← Expr2 A := A . (Expr1) ← Expr2 Here A denotes the array, which you get if you replace A(Expr1) by Expr2 and leave all other elements of A unchanged.

–265– S. Lucks Security Engineering 5: Hoare Logic 5.4: Extending Toy Language Two new axioms

New assignment axiom: (“A(Expr1) is replaced by”):

(Expr1) ← Expr2 A (Expr1) = Expr2.

Addional “Frame”-axiom (“the other elements of A remain unchanged”): IF Expr1 6= Expr3 THEN (Expr1) ← Expr2 A (Expr3) = A(Expr3).

–266– S. Lucks Security Engineering 5: Hoare Logic 5.4: Extending Toy Language Example: Swap A(X) and A(Y )

{A(X) = Xold, A(Y) = Yold} T := A(X); A(X) := A(Y ); A(Y ) := T ; {A(X) = Yold, A(Y) = Xold}

–267– S. Lucks Security Engineering 5: Hoare Logic 5.4: Extending Toy Language The proof

{A(X) = Xold, A(Y) = Yold} T := A(X); { A(Y) = Yold(!), T = Xold } (Y) ← T  (X) ← A(Y ) { A (X) = Yold, T = Xold }

A(X) := A(Y ); (Y) ← T { A (X) = Yold, T = Xold } (Y) ← T (Y) ← T { A (X) = Yold, A (Y) = Xold } A(Y ) := T ; {A(X) = Yold, A(Y) = Xold}

–268– S. Lucks Security Engineering 5: Hoare Logic 5.4: Extending Toy Language Still missing (!)

(Y) ← T  (X) ← A(Y ) A (X) = A(Y)

I Case 1: X 6= Y . (That is easy.) I Case 2: X = Y . (That is a bit tricky!)

–269– S. Lucks Security Engineering 5: Hoare Logic 5.4: Extending Toy Language Pointers / access types

I In principle, one can treat the heap like a huge array of storage places. I But if a program makes significant usage of heap-allocated data, proving properties becomes extremely difficult. I Current research issue, see, e.g.,: Bertrand Meyer, “The Theory and Calcus of Aliasing”: hhttp://bertrandmeyer.com/2010/01/21/ the-theory-and-calculus-of-aliasing/i

–270– S. Lucks Security Engineering 5: Hoare Logic 5.4: Extending Toy Language Parameterless procedures

Syntax:

I procedure P is begin S0; end Semantic:

I Whenever P is called, we actually execute S0. Rule for non-recursive parameterless procedures:

{P} S0; {Q} {P} P; {Q}

Nonrecursive procedures (and functions) with parameters, e.g.,

procedure P(X : ...) is S0 end P;

Calling P(Expr) is the same as assigning Expr to X then runing S0.

–271– S. Lucks Security Engineering 5: Hoare Logic 5.4: Extending Toy Language Functions / Prozedures in general

I Recursive procedures: I partial correcntess similar to the nonrecursive case I termination needs an upper bound (like the variant for WHILE-loops) for the recursion depth I Theorem: There is no complete∗ and sound∗∗ system for any language which combines I procedures with procedure-parameters (access procedure), I recursion, I statical scoping, I global variables, and I locally defined procedures as procedure-parameters. I This combination of features is supported by many languages, starting from Algol-60.

—————- ∗ complete: all correct statements are provable ∗∗ sound: no incorrect statements are provable

–272– S. Lucks Security Engineering 5: Hoare Logic 5.4: Extending Toy Language