Weakest Precondition of Unstructured Programs

1. Weakest Precondition of Unstructured Programs Short Presentation

2. Preliminaries • Program verification systems typically transform a program into a logical expression which is then sent to a theorem prover

3. Preliminaries • Program verification systems typically transform a program into a logical expression which is then sent to a theorem prover • The logical expression represents the weakest precondition of the program relative to its specification • when and if the theorem prover is able to prove the expression, then the program is considered correct

4. Preliminaries • Program verification systems typically transform a program into a logical expression which is then sent to a theorem prover • The logical expression represents the weakest precondition of the program relative to its specification • when and if the theorem prover is able to prove the expression, then the program is considered correct • computing such a logical expression for an imperative, structured program is straightforward • there are issues having to do with loops and the efficiency both of the computation and of the complexity of the formula with respect to the theorem prover

5. Preliminaries • Program verification systems typically transform a program into a logical expression which is then sent to a theorem prover • The logical expression represents the weakest precondition of the program relative to its specification • when and if the theorem prover is able to prove the expression, then the program is considered correct • computing such a logical expression for an imperative, structured program is straightforward • there are issues having to do with loops and the efficiency both of the computation and of the complexity of the formula with respect to the theorem prover • in the followings, it is presented a novel approach for computing the weakest precondition of an unstructured program that is sound even in the presence of loops

6. Static Program Verifier • the typical architecture of a static program verifier takes as input a program and its specification, generates from these a verification condition – a first-order logical formula whose validity implies that the program meets the specification and then passes the verification condition to a theorem prover

7. Static Program Verifier • the typical architecture of a static program verifier takes as input a program and its specification, generates from these a verification condition – a first-order logical formula whose validity implies that the program meets the specification and then passes the verification condition to a theorem prover • the engineering of the verification condition has a large impact on the proving task presented to the theorem prover (the formula shouldn’t be larger than it needs to be) • Spec# is a programming environment that relies on a static program verifier (the framework is developed at Microsoft Research)

8. Static Program Verifier • the typical architecture of a static program verifier takes as input a program and its specification, generates from these a verification condition – a first-order logical formula whose validity implies that the program meets the specification and then passes the verification condition to a theorem prover • the engineering of the verification condition has a large impact on the proving task presented to the theorem prover (the formula shouldn’t be larger than it needs to be) • Spec# is a programming environment that relies on a static program verifier (the framework is developed at Microsoft Research) • the verification condition generation in Spec# proceed in stages, as well • the starting point is a general control-flow graph (natural choice since Spec# static program verifier uses as its input language the intermediate language of the .NET virtual machine, whose branch instructions can give rise to any control flow)

9. Spec# Environment • Spec# (developed at Microsoft Research) has a static program verifier • Spec# • - an extension of C# with preconditions, postconditions, non-null types, checked exceptions, loop invariants, object invariants and other reliability features • - accompanied by a compiler that emits runtime checks • - accompanied by a static program verifier backed by an automatic theorem prover

10. Spec# Environment • Spec# (developed at Microsoft Research) has a static program verifier • Spec# • - an extension of C# with preconditions, postconditions, non-null types, checked exceptions, loop invariants, object invariants and other reliability features • - accompanied by a compiler that emits runtime checks • - accompanied by a static program verifier backed by an automatic theorem prover • the program verifier works by translating the Spec# source code into a guarded commands program, which is then further translated into verification conditions that are passed to the theorem prover • now, back to the verification condition generation in Spec#

11. Generation of VC in Spec# • - The verification condition generation in Spec# proceed in stages, as well • the starting point is a general control-flow graph (natural choice since Spec# static program verifier uses as its input language the intermediate language of the .NET virtual machine, whose branch instructions can give rise to any control flow)

12. Generation of VC in Spec# • - The verification condition generation in Spec# proceed in stages, as well • the starting point is a general control-flow graph (natural choice since Spec# static program verifier uses as its input language the intermediate language of the .NET virtual machine, whose branch instructions can give rise to any control flow • using standard compilation techniques that duplicate instructions to eliminate multiple entry points to loops, the general control-flow graph is transformed into a reducible one

13. Generation of VC in Spec# • - The verification condition generation in Spec# proceed in stages, as well • the starting point is a general control-flow graph (natural choice since Spec# static program verifier uses as its input language the intermediate language of the .NET virtual machine, whose branch instructions can give rise to any control flow • using standard compilation techniques that duplicate instructions to eliminate multiple entry points to loops, the general control-flow graph is transformed into a reducible one • the loops are eliminated, producing an acyclic control-flow graph that is correct if the original program is correct

14. Generation of VC in Spec# • - The verification condition generation in Spec# proceed in stages, as well • the starting point is a general control-flow graph (natural choice since Spec# static program verifier uses as its input language the intermediate language of the .NET virtual machine, whose branch instructions can give rise to any control flow • using standard compilation techniques that duplicate instructions to eliminate multiple entry points to loops, the general control-flow graph is transformed into a reducible one • the loops are eliminated, producing an acyclic control-flow graph that is correct if the original program is correct • a single-assignment transformation to the acyclic program turns it into a passive program (changing the assignments statements into assume statements)

15. Generation of VC in Spec# • - The verification condition generation in Spec# proceed in stages, as well • the starting point is a general control-flow graph (natural choice since Spec# static program verifier uses as its input language the intermediate language of the .NET virtual machine, whose branch instructions can give rise to any control flow • using standard compilation techniques that duplicate instructions to eliminate multiple entry points to loops, the general control-flow graph is transformed into a reducible one • the loops are eliminated, producing an acyclic control-flow graph that is correct if the original program is correct • a single-assignment transformation to the acyclic program turns it into a passive program (changing the assignments statements into assume statements) • finally, we apply the weakest precondition and we generate the verification condition!!!

16. Programs and Correctness • Program : a chunk of code that is to be verified • Language : follows the following grammar • Some constructs : • assert C : statement causes an error to be reported if the condition C cannot be shown to always hold • assume C : statement causes the verifier to consider only those program executions which either do not reach this statement or satisfy the condition C • havoc x : statement assigns an arbitrary value to the variable

17. Programs and Correctness • A program gives rise to a set of execution traces (sequences of program states) • A trace is either infinite, or it ends in termination or ends in error or ends in infeasibility • in other words: the trace ends in termination if there are no successors to choose from, ends in error if an assert statements evaluates to false, and ends in infeasibility if an assume statements evaluates to false

18. Programs and Correctness • A program gives rise to a set of execution traces (sequences of program states) • A trace is either infinite, or it ends in termination or ends in error or ends in infeasibility • in other words: the trace ends in termination if there are no successors to choose from, ends in error if an assert statements evaluates to false, and ends in infeasibility if an assume statements evaluates to false • A program is correct if none of its traces ends in error • the definition does not say anything about the final state of terminating executions • a correct program can have traces that end in infeasibility • a correct program can include neverending executions

19. Example in Spec# • Let us consider the following Spec# source program:

20. Example in Spec# • The control-flow graph corresponding to this method is encoded as follows, where we have used a variable r to denote the result value:

21. Generation of VC in Spec# • - Getting back to the verification condition generation in Spec#: • the starting point is a general control-flow graph (natural choice since Spec# static program verifier uses as its input language the intermediate language of the .NET virtual machine, whose branch instructions can give rise to any control flow • using standard compilation techniques that duplicate instructions to eliminate multiple entry points to loops, the general control-flow graph is transformed into a reducible one • the loops are eliminated, producing an acyclic control-flow graph that is correct if the original program is correct • a single-assignment transformation to the acyclic program turns it into a passive program (changing the assignments statements into assume statements) • finally, we apply the weakest precondition and we generate the verification condition!!!

22. Elimination of Loops • The third step in VC generation is the transformation from a reducible control-flow graph into an acyclic control-flow graph • a reducible control-flow graph is one where it is possible to identify a unique loop head for each loop

23. Elimination of Loops • The third step in VC generation is the transformation from a reducible control-flow graph into an acyclic control-flow graph • a reducible control-flow graph is one where it is possible to identify a unique loop head for each loop • In order to identify the loops, we begin by finding all of the back edges • it is the existence of a back edge that uniquely identifies a loop • a back-edge is an edge in the control-flow graph whose tail (target) dominates its head (source), with one node dominating another node when all paths to the latter pass through the former • the loop header L for a back edge B is the target of the edge • each natural loop is identified by the pair (L, B)

24. Elimination of Loops • In order to identify the loops, we begin by finding all of the back edges • we remove all back edges to cut the loops, thus transforming the graph into an acyclic one • but in order for a loop body to represent an arbitrary loop iteration, we must make sure that the values of any variables modified within the loop have a value that they might hold on any iteration of the loop • for each natural loop (L, B), we collect into a set H(L, B) the variables that are updated by any statement in any block in the loop • for each loop target in H(L, B), we introduce a havoc statement and insert it at the beginning of L, before any of the existing statements in that block

25. Elimination of Loops • In order to identify the loops, we begin by finding all of the back edges • we remove all back edges to cut the loops, thus transforming the graph into an acyclic one • but in order for a loop body to represent an arbitrary loop iteration, we must make sure that the values of any variables modified within the loop have a value that they might hold on any iteration of the loop • for each natural loop (L, B), we collect into a set H(L, B) the variables that are updated by any statement in any block in the loop • for each loop target variable in H(L, B), we introduce a havoc statement and insert it at the beginning of L, before any of the existing statements in that block • wiping out all knowledge of the value a variable might hold may cause the theorem prover to be unable to prove the verification condition (induces an overapproximation of the original program and loses too much precision) • therefore, each loop will have a loop invariant…

26. Elimination of Loops • Loop invariants are encoded as a prefix of assert statements at the beginning of the loop header’s code block (the assert cannot be validated if any of the variables they mention are in H(L,B) • instead, we introduce a copy of this sequence of statements into each predecessor node of L (including the node that is the source of the back edge) • since the assertions are now checked just before the jump to the loop header, we change the statements into assume statements in L itself • we process loop invariants in this way before adding the havoc statements and cutting the back edges • the resulting havoc followed by the assume statements have the effect of retaining, about the loop targets, the information in the loop invariant • This is a conservative approximation: it increases the code size (when introducing a copy of some code at the source of each edge instead of having a single copy at its target), but the correctness of the program is not affected

27. Elimination of Loops • for example, starting with the following control-flow graph (previously introduced program): • after cutting back edges, the loop free program is:

28. Elimination of Loops • the loop free program:

29. Generation of VC in Spec# • - Getting back to the verification condition generation in Spec#: • the starting point is a general control-flow graph (natural choice since Spec# static program verifier uses as its input language the intermediate language of the .NET virtual machine, whose branch instructions can give rise to any control flow • using standard compilation techniques that duplicate instructions to eliminate multiple entry points to loops, the general control-flow graph is transformed into a reducible one • the loops are eliminated, producing an acyclic control-flow graph that is correct if the original program is correct • a single-assignment transformation to the acyclic program turns it into a passive program (changing the assignments statements into assume statements) • finally, we apply the weakest precondition and we generate the verification condition!!!

30. Passification • The loop free program is transformed into a passive program in two stages: • the program is rewriting into a single-assignment form • the program’s assignments are removed

31. Passification - DSA • Step 1: single assignment form (DSA) • we convert a loop-free program into DSA form by noting that after each update to a variable, its value must be understood relative to the newly updated state by identifying each updated value as a new incarnation of the variable • for instance: the assignment • is replaced with the assignment

32. Passification - DSA • Step 1: single assignment form (DSA) • we convert a loop-free program into DSA form by noting that after each update to a variable, its value must be understood relative to the newly updated state by identifying each updated value as a new incarnation of the variable • for instance: the assignment • is replaced with the assignment • All variables read by the statement are replaced by their current incarnation • At the beginning of the program, an initial incarnation is created for each program variable • the algorithm that perform all these replacements, processes the graph in a topologically sorted order

33. Passification - DSA • Step 1: single assignment form (DSA) • for straight-line code, it is simple to iterate over the sequence of statements, replacing all of the variables with their current incarnations

34. Passification - DSA • Step 1: single assignment form (DSA) • for straight-line code, it is simple to iterate over the sequence of statements, replacing all of the variables with their current incarnations • problems arise at join points: a node may be “inheriting” conflicting incarnations (see the example with a if-then-else block) • solved with a new incarnation, for both then and else blocks • a new incarnation is potentially created for each variable at every join point (leading to more incarnations than strictly necessary) <- solved by reusing predecessors’ incarnations

35. Passification - DSA • Step 1: single assignment form (DSA) • for straight-line code, it is simple to iterate over the sequence of statements, replacing all of the variables with their current incarnations • problems arise at join points: a node may be “inheriting” conflicting incarnations (see the example with a if-then-else block) • solved with a new incarnation, for both then and else blocks • a new incarnation is potentially created for each variable at every join point (leading to more incarnations than strictly necessary) <- solved by reusing predecessors’ incarnations • due to this solution, we use DSA and not SSA

36. Passification - assume • Step 2 : replace all assignment statements by assume statements • The assignment : • is replaced with • - This is possible because the value of xi is not used prior to its definition (so xi had the desired value all along)

37. Passification • the loop free program: • is transformed into the passive program:

38. Passification • the passive form of the program:

39. Generation of VC in Spec# • - Getting back to the verification condition generation in Spec#: • the starting point is a general control-flow graph (natural choice since Spec# static program verifier uses as its input language the intermediate language of the .NET virtual machine, whose branch instructions can give rise to any control flow • using standard compilation techniques that duplicate instructions to eliminate multiple entry points to loops, the general control-flow graph is transformed into a reducible one • the loops are eliminated, producing an acyclic control-flow graph that is correct if the original program is correct • a single-assignment transformation to the acyclic program turns it into a passive program (changing the assignments statements into assume statements) • finally, we apply the weakest precondition and we generate the verification condition!!!

40. Weakest Precondition • we apply weakest precondition to the passive form of the program and get the verification condition • By definition, for any statement S and predicate Q on the post-state of S, the weakest precondition of S with respect to Q, written wp(S,Q) is a predicate that characterizes all pre-states of S from which no execution will go wrong and from which every terminating execution ends in a state satisfying Q

41. Weakest Precondition • we apply weakest precondition to the passive form of the program and get the verification condition • By definition, for any statement S and predicate Q on the post-state of S, the weakest precondition of S with respect to Q, written wp(S,Q) is a predicate that characterizes all pre-states of S from which no execution will go wrong and from which every terminating execution ends in a state satisfying Q • for our (passive) language constructs, the weakest precondition is defined as follows:

42. Weakest Precondition • in a structured program, the central problem to be overcome in computing weakest preconditions is that of the choice statement (arbitrarily choosing to execute S or T): • the problem is that the duplication of Q in the right-hand side introduces redundancy (the theorem prover would need to process Q twice)

43. Weakest Precondition • in a structured program, the central problem to be overcome in computing weakest preconditions is that of the choice statement (arbitrarily choosing to execute S or T): • the problem is that the duplication of Q in the right-hand side introduces redundancy (the theorem prover would need to process Q twice) • passive programs satisfy a property that lets this wp equation be formulated in a way that significantly reduces redundancy • this alternate form is called weak liberal precondition (wlp) and produces verification condition whose size is quadratic in the size of the passive programs • wlp applies to structured programs, so to extend it for unstructured programs, there will be some preprocessing steps

44. Weakest Precondition • the unstructured programs do not have the structured choice statement (they have goto statements) and the control-flow graph explodes into a tree (and lose all the sharing that the control-flow graph representation affords) • therefore, for every goto block, it is introduced an auxiliary variable that is true it the program is in a state from which all executions beginning from that block are correct • where Succ(A) denotes the set of successors of A so that the second argument to wp is the conjunction of B_ok for each block B in that set • - For example…

45. Weakest Precondition • for the program (if-then-else statement, actually): • The block equation for Then is: • Each block contributes one block equation, call their conjunction R, and the program’s verification condition is:

46. Weakest Precondition • the passive form of the program: • computing the wp, the set of block equations are:

47. Weakest Precondition • the block equations : • finally the verification condition is: