1. Extension of Separation Logic for Stack Reasoning Jiang Xinyu

2. Motivation  Stacks are special  Continuous  Ordered  Stack reasoning is important  Proof about stacks is usually more than proof about heaps  Mainly for function calls and local variables

3. Problems of Our Previous Proof  Excessive use of arithmetic of natural numbers  Unnecessary shape matching  Over-used symmetry law of “*”  Repeated proof about the stack’s unused space  Too much care taken to the address of each local variable

4. Arithmetic  For the formula  We know that  These equations can be automatically proved, but must be proved separately

5. Shape Matching  This is a common pattern of proof  For stack, the proof is unnecessary  This kind of goals comes from the permutation of *-conjuncted logic assertions

6. Symmetry Law  If we know  And we want to know  We should do proof like

7. Unused Stack Space  Another common pattern  We should prove these sub goals

8. Too much labels  See this  Or worse?

9. Solution?  Some of them can be alleviated  Arithmetic proof can be reduced by using hex numbers  Some can be eliminated by changing a machine model  Abstract over the unused space  Or treat the stack as a different data structure  Works for higher-level code, but kernel code requires that stacks behave like normal memory

10. Solution…  Should not assume a higher-level machine model  Also  Should not prohibit reasoning about code that operates on stacks like on heaps  Should work well with heap reasoning(separation logic)

11. Solution!  Extending separation logic  For any piece of heap, if it’s like a stack, and we say it’s a stack, then it’s a stack!  For any stack, if we want to say that it’s a heap, no problem!

12. Where Does all Those Problem Come From?  Separation logic is general, but a little too general  Memory may have holes, so its every slice should have a label  Merging of memories are irrelevant to the order  We introduce a more restrictive, but terser “sublanguage”

13. Adjacency Conjunction  We first define adjacent heaps  And the adjacent union of heaps  The adjacent conjunction is defined like the separation conjunction

14. Properties Shared with Separation Conjunction  Association  Monotonicity  Introduce and elimination of Emp and True  But no symmetry property!

15. A New Property  For any Memory M, if  Then  So either l1 or l2 is abundant

16. Reducing Labels  Another basic assertion: has  We can prove that

17. Is It Really a Solution?  Let’s review our problems  Excessive use of arithmetic of natural numbers  Unnecessary shape matching  Over-used symmetry law  Repeated proof about the stack’s unused space  Too much care taken to the address of each local variable

18. Arithmetic  The original  Becomes  Doing arithmetic when really necessary

19. Shape Matching  This is now trivial to prove  Adjacent conjunction does not allow permutation, so the order must be the same

20. Symmetry Law  We haven’t any!  Then how to prove the following goal?  We move labels

21. Unused Space  Not totally solved  But at least we have a lemma to do this  The definition of free is also simplified

22. Too much labels  Only one label  And you can insert the label if it’s valid

23. It Is a Solution…  For Lower-level machine code verification  Where the stack are taken as a part of the heap  And all heap operations are valid on stacks  Which works well with separation logic  It is just an extension  No original definitions or rules are changed  Separation conjunction and adjacency conjunction can be freely mixed

24. Tactics for the Extension  Finding labels  Moving labels  Splitting and merging unused stack space

25. Expected Tactics  find_label: a special example  And more general

26. Expected Tactics  label_move_left, label_move_right

27. Expected Tactics  Stack Splitting and Merging

28. Related Work  Stack Typing  Has similar adjacent conjunction  For TAL  Specification language differs  No efforts to hide labels