1. A Theory of Termination via Indirection Robert Dockins and Aquinas Hobor (Princeton University) (NUS) TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.: A A

2. Goal Use step-indexed models to prove program termination in the presence of certain (approximated) recursive domain equations Testbed: soundness of a logic of total correctness for a language with 1.Function pointers 2.Semantic assertions (assert truth of a (classical) logical formula at the current program point) 2

3. Goal Use step-indexed models to prove program termination in the presence of certain (approximated) recursive domain equations Testbed: soundness of a logic of total correctness for a language with 1.Function pointers 2.Semantic assertions (assert truth of a (classical) logical formula at the current program point) 3

4. A very simple language 4

5. Simple semantic definitions 5

6. 6 Uh oh…

7. We detail our predicates/assertions informally and refer to the paper for formal construction 7

8. We detail our predicates/assertions informally and refer to the paper for formal construction 8

9. We detail our predicates/assertions informally and refer to the paper for formal construction 9

10. We detail our predicates/assertions informally and refer to the paper for formal construction 10

11. What does funptr l t [ P ] [ Q ] mean? 11 1.The program has some code c at address l. (This is why we want predicates to be able to judge programs.) 2.When c is called with some initial store ½, if t( ½ ) is defined then c makes at most t( ½ ) function calls before returning to its caller. 3. P and Q are actually functions from some function-specific type A to predicates. If t( ½ ) is defined then for all a, if P ( a ) holds before the call then Q ( a ) will hold afterwards.

12. Why it was (considered) hard Certain people who will remain anonymous (some in this room, some elsewhere, e.g., Princeton, NJ) thought step-indexed models were inapplicable to liveness problems We have discussed the difficulty of statements like, “method X cannot be used to prove Y” 12

13. Why it was (considered) hard Certain people who will remain anonymous (some in this room, some elsewhere, e.g., Princeton, NJ) thought step-indexed models were inapplicable to liveness problems We have discussed the difficulty of statements like, “method X cannot be used to prove Y” 13

14. Why it was (considered) hard But if you asked, such people said: 1.Step-indexed models have an outer “forall n” that quantifies (universally) over the number of steps; this works well for safety properties but very poorly for liveness properties 2.While “safe” is hereditary/monotonic/closed under approximation, “halts” is not (actually, this is related to point 1, too…) 3.It’s never been done and termination is hard 14

15. Why it was (considered) hard But if you asked, such people said: 1.Step-indexed models have an outer “forall n” that quantifies (universally) over the number of steps; this works well for safety properties but very poorly for liveness properties 2.While “safe” is hereditary/monotonic/closed under approximation, “halts” is not (actually, this is related to point 1, too…) 3.It’s never been done and termination is hard 15

16. Why it was (considered) hard But if you asked, such people said: 1.Step-indexed models have an outer “forall n” that quantifies (universally) over the number of steps; this works well for safety properties but very poorly for liveness properties 2.While “safe” is hereditary/monotonic/closed under approximation, “halts” is not (actually, this is related to point 1, too…) 3.It’s never been done and termination is hard 16

17. Why it’s actually not that hard 1.It turns out that the outside quantification can just as easily be existential if we can only find the right value to instantiate it… – This is exactly what a termination proof gives us! – “P terminates” a.k.a. “exists n. P reaches halt in n steps” 17

18. Why it’s actually not that hard 1.It turns out that the outside quantification can just as easily be existential if we can only find the right value to instantiate it… – This is exactly what a termination proof gives us! – “exists n. prog reaches halt in n steps” 18

19. Hoare Judgment Our Hoare Judgment looks a bit complex: ¡, R ` n { P } c { Q } ¡ contains function pointer assertions and R is the postcondition of the current function n is an upper bound on the number of function calls c makes before it terminates 19

20. Hoare Rules, 1 20

21. Hoare Rules, 1 21

22. Hoare Rules, 2 22

23. Hoare Rules, 2 23

24. Hoare Rules, 3 24

25. Hoare Rules, 3 25

26. The Call Rule The interesting rule is for call… and it’s not too bad: 26

27. The Call Rule The interesting rule is for call… and it’s not too bad: 1. x must evaluate to a label l 27

28. The Call Rule The interesting rule is for call… and it’s not too bad: 2. l must be a pointer to a function with termination measure t, precondition P l and postcondition Q l 28

29. The Call Rule The interesting rule is for call… and it’s not too bad: 3. The termination measure t must evaluate to some n on the current store 29

30. The Call Rule The interesting rule is for call… and it’s not too bad: 3. The termination measure t must evaluate to some n on the current store… and so this call will take no more than n +1 calls. 30

31. The Call Rule The interesting rule is for call… and it’s not too bad: 4. We require the (parameterized) precondition to be true at call, and guarantee the (parameterized) postcondition will be true on return. 31

32. So, not too bad… Most of these rules are really nothing to get excited about… even the call rule is pretty simple when you understand the parts… (This is a virtue, of course…) But we’re not done. We’ve only shown the rule for using the funptr, not the rules for verifying that a function actually terminates 32

33. Verifying function bodies Verifying function bodies, while very important, is not part of the main line of this talk – why proving termination with a step- indexed model isn’t so bad. We can verify functions in many interesting cases – recursive, mutually recursive, higher- order (we can handle map of map), etc. If you want, ask me about this at the end. (I have 35 slides as backup!) 33

34. Why it’s actually not that hard 2.The second reason people thought that termination was really hard with step- indexed models was that “halting” is not hereditary/monotonic/downward closed. A.What is hereditary? B.Why is halting not hereditary? 34

35. Why it’s actually not that hard 2.P hereditary ´ (w ² P Æ w à w’) ! w’ ² P Here à is the “age” or “approximate” operation on step-indexed worlds. We can only approximate a finite number of times before we “hit bottom”. The step relation approximates w during function call. 35

36. Why it’s actually not that hard 2.The standard definition: w ² halts( ¾ ) ´ 9 w h. (w, ¾ )  * (w h, []) Let w à w’. The problem is that the  relation approximates the world (at function call), so w’ might not have enough “time” left to actually reach the halting state []. 36

37. Why it’s actually not that hard 2.Our definition: w ² halts n ( ¾ ) ´ |w| > n ! ( 9 w h. (|w|-|w h | · n) Æ (w, ¾ )  * (w h, []) ) This is actually very similar to the basic definition. 37

38. Why it’s actually not that hard 2.Our definition: w ² halts n ( ¾ ) ´ |w| > n ! ( 9 w h. (|w|-|w h | · n) Æ (w, ¾ )  * (w h, []) ) Here is the exists and requirement that we step to the halt state. 38

39. Why it’s actually not that hard 2.Our definition: w ² halts n ( ¾ ) ´ |w| > n ! ( 9 w h. (|w|-|w h | · n) Æ (w, ¾ )  * (w h, []) ) This is the key “trick” – if the amount of time left in w is not enough, then we become true (and thus hereditary) trivially. 39

40. Why it’s actually not that hard 2.Our definition: w ² halts n ( ¾ ) ´ |w| > n ! ( 9 w h. (|w|-|w h | · n) Æ (w, ¾ )  * (w h, []) ) We must be sure that n is really a bound on the number of steps required to halt. (Alternative: see paper’s Coq development.) 40

41. Why it’s actually not that hard 2.Our definition: w ² halts n ( ¾ ) ´ |w| > n ! ( 9 w h. (|w|-|w h | · n) Æ (w, ¾ )  * (w h, []) ) So, really not that bad. This is the “fundamental” trick that makes everything else possible. 41

42. Why it’s actually not that hard 2.See the paper (and/or Coq development) for details on how to use this definition to build up the definition for the Hoare tuple, etc. Actually I have presented a slightly modified version (we continue to tinker), but feel free to ask us for the latest version. 42

43. Why it’s actually not that hard 3.The third objection is that termination is tricky and have never been done with step- indexing before. We observe the following: Our top-level “erased” theorems are stated in absolutely standard form: if a program is verified in our logic, then it terminates. No indirection theory in statement of (erased) top-level theorem. 43

44. Why it’s actually not that hard 3.The third objection is that termination is tricky and have never been done with step- indexing before. We observe the following: All our proofs are machine checked in Coq. Our core proofs are quite compact. 44

45. Compact Proofs The main file is 826 lines long, and contains: A.Semantic model of the terminating function pointer, Hoare judgment, whole-program verification judgment B.10+ Hoare rules and soundness proofs C.3 whole-program rules and soundness proofs D.Top-level theorems (if P is verified, then it halts) Really quite short… 45

46. 46

47. V-rules We need another judgment, written ª : ¡, that says that program ª contains functions verified to “funptr” specifications in ¡. We will verify functions one at a time (or in the case of mutually-recursive groups, as a group). The “base case” is an easy rule: 47

48. The “Vsimple” rule So this looks pretty bad, but we can take it apart: 48

49. The “Vsimple” rule 49 So this looks pretty bad, but we can take it apart: 1. We have verified part of ª to specification ¡

50. The “Vsimple” rule 50 So this looks pretty bad, but we can take it apart: 2. We want to add this specification for l

51. The “Vsimple” rule 51 So this looks pretty bad, but we can take it apart: 3. We must have verified the code for l

52. The “Vsimple” rule 52 So this looks pretty bad, but we can take it apart: 4. When the precondition P (a) holds

53. The “Vsimple” rule 53 So this looks pretty bad, but we can take it apart: 4. When the precondition P ( a ) holds and the termination measure is equal to some n.

54. The “Vsimple” rule 54 So this looks pretty bad, but we can take it apart: 5. This n is also an upper bound on the number of calls this function makes.

55. The “Vsimple” rule 55 So this looks pretty bad, but we can take it apart: 6. The postcondition is just ? : you can’t fall out the bottom

56. The “Vsimple” rule 56 So this looks pretty bad, but we can take it apart: 6. The postcondition is just ? : you can’t fall out the bottom, but the return condition is Q (a).

57. The “Vsimple” rule 57 So this looks pretty bad, but we can take it apart: 7. We can assume every funptr we have previously verified, and…

58. The “Vsimple” rule 58 So this looks pretty bad, but we can take it apart: 8. We can call ourselves using a modified function specification precondition: t has decreased.

59. The “Vsimple” rule 59 Here are the critical uses for t. If we assume the termination measure is equal to n at the function start, then we can make no more than n calls and can recurse only when t < n.

60. Using Vsimple We will verify the unary addition function Our language, while Turing-complete, is extremely painful to program in; this is not fundamental but it does mean that our examples are somewhat “lame”. Expanding the result to a more programmable language would not be very difficult now. 60

61. Using Vsimple: naturals as lists listnat(0,0) listnat( n, v ) \Rightarrow listnat( n +1, (0, v )) 00 1(0, 0) 2(0, (0, 0)) 3(0, (0, (0, 0))) …… 61

62. Precondition, postcondition, termination measure addP(n,m) ´ 9 v 1, v 2. (r 1  v 1 ) Æ (r 2  v 2 ) Æ listnat(n,v 1 ) Æ listnat(m,v 2 ) addQ(n,m) ´ 9 v 2. (r 2  v 2 ) Æ listnat(n+m,v 2 ) addt( ½ ) ´ the unique n s.t. 9 v 1. ( ½ (r 1 ) = v 1 ) and listnat(n,v 1 ) 62

63. Code (stored at label 1) 63

64. The verification Actually, using the Hoare rules is very easy. 64

65. The verification Actually, using the Hoare rules is very easy. But very tedious. We won’t bore you. The more interesting question is, what does the verification obligation generated from Vsimple look like? 65

66. Verification obligation from Vsimple xxx 66 n ¡n,¡n,

67. Vsimple, in a nutshell The Vsimple rule is fine for most functions, but it can only verify, well, simple recursive functions (as well as calls to both simple and complex functions previously verified). If we want “the goodies” (mutual recursion, polymorphic termination arguments, etc.) then we need to call in Vsimple’s big brother… 67

68. This is moderately horrible. We have (at least): 68 The “Vfull” rule

69. This is moderately horrible. We have (at least): 1. A set © of funptr specifications in the goal as well as the assumptions 69 The “Vfull” rule

70. This is moderately horrible. We have (at least): 2. The same basic termination measure trick 70 The “Vfull” rule

71. This is moderately horrible. We have (at least): 3. A parameter b used for higher-order functions 71 The “Vfull” rule

72. This is moderately horrible. We have (at least): 3. There can be a strong dependency between b and the other factors (e.g., the type of a ) 72 The “Vfull” rule

73. The Vsimple rule is just a special case of Vfull. 73 The “Vfull” rule

74. Using Vfull We are going to verify the simplest nontrivial higher order function we can, “apply”. It takes as an argument a pair of a function f and an argument v and just applies f to v. The “interesting” part is how the polymorphism is verified as opposed to the function behavior. 74

75. Defining a calling convention To specify the “apply” function, we must define a calling convention for the sub-function 75

76. Defining a calling convention The registers r 1 – r 4 are callee-saves; registers from r 5 ! 1 registers are caller-saves 76

77. Defining a calling convention A stdfun’s precondition, postcondition, and termination measure only depend on r 0. 77

78. Apply’s precondition, postcondition, and termination measure 78

79. Apply’s precondition, postcondition, and termination measure These look “obvious” until you realize that P, Q, and t seem free in the definition. We will see how the Vfull rule “pipes” these in. 79

80. Apply’s precondition, postcondition, and termination measure Notice that we can use the called function’s termination measure to build our own 80

81. 81 The code is simple, although the verification is a bit cluttered…

82. 82 If you’ve got it, flaunt it: we toss in a higher- order assert for fun…

83. 83 Notice how we track the termination measure

84. The verification obligation from Vfull 84 This is somewhat large (thank goodness for machine-checking!). There are a few points of particular interest.

85. The verification obligation from Vfull 85 1. We can check this function first, — i.e., ¡ = > That is, we verify this function before we verify the functions we will pass to it.

86. The verification obligation from Vfull 86 2. The Vfull rule “pipes in” t, P, and Q – in fact, the triple ( t, P, Q ) is the “ b ” from Vfull.

87. The verification obligation from Vfull 87 3. As before, we thread the termination argument into the verification required.

88. “Stacking” apply As it happens, the apply function, itself, is a standard function (r 1 – r 4 are preserved, argument passed in r 0, return in r 0 ). In fact, we can pass “apply” to itself without difficulty. The rules will prevent us from unbounded recursion. We can “apply (apply (apply … (apply (f))))” but the function f “at the bottom” must terminate “on its own”. 88

89. More examples… We could go on to map, map of map, etc., but maybe it would be better here to just refer to the paper and mechanized development. Are there questions? 89