Modular verification of assembly code with stack-based control abstractions

Abstract

Runtime stacks are critical components of any modern softwarethey are used to implement powerful control structures such as function call/return, stack cutting and unwinding, coroutines, and thread context switch. Stack operations, however, are very hard to reason about: there are no known formal specifications for certifying C-style setjmp/longjmp, stack cutting and unwinding, or weak continuations (in C--). In many proof-carrying code (PCC) systems, return code pointers and exception handlers are treated as general first-class functions (as in continuation-passing style) even though both should have more limited scopes.In this paper we show that stack-based control abstractions follow a much simpler pattern than general first-class code pointers. We present a simple but flexible Hoare-style framework for modular verification of assembly code with all kinds of stackbased control abstractions, including function call/return, tail call, setjmp/longjmp, weak continuation, stack cutting, stack unwinding, multi-return function call, coroutines, and thread context switch. Instead of presenting a specific logic for each control structure, we develop all reasoning systems as instances of a generic framework. This allows program modules and their proofs developed in different PCC systems to be linked together. Our system is fully mechanized. We give the complete soundness proof and a full verification of several examples in the Coq proof assistant.

Formal Reasoning About Lazy-STM Programs

“…The atomicity and isolation properties of transaction can also be formally verified in our framework. We introduce a local guarantee g for each thread, as in SCAP [23] , describing valid memory updates -it is safe for the current transaction to roll back only after make a memory update allowed by g. So when a transaction rolls back, it guarantees that the memory in the current thread state is consistent with the memory at the beginning of the transaction, just as nothing has been done. The isolation is enforced by CSL, in status act the shared memory is required to be unchanged due to that the transaction may roll back, so only in status cmt the memory updates can be visible to other threads.…”

Certification of Thread Context Switching

“…As mentioned in Subsection 1.4, our approach follows the second methodology, which is also used in SCAP [9] and previous work [7][8] . In SCAP, a code specification consists of a precondition p and an action g, rather than using the methodology reasoning about first-class code pointers, to support modular certification of function call, especially the last return instruction of a function.…”

“…In our framework, a code specification θ is a triple, consisting of a precondition p, an action g and a tag b. The precondition p and action g are like the notations used in original SCAP [9] but they have two extra arguments, t and X, as we explained in Section 3. In a code specification θ, precondition p specifies the precondition before machine executes an instruction.…”

“…Feng et al proposed the CAP-CR program logic [9] , which supports reasoning about coroutines modularly. Compared to our framework, their code specifications of threads are in the forms of (p, g, g t , g r ).…”

Certifying assembly programs with trails

“…1, note that the infinite loop of the first path never exits the current function, so the end points should be "a4" and "b1". This method needs a logical function stack to be maintained and complicates the program logic system [8].…”