Argosy: verifying layered storage systems with recovery refinement

Abstract

Storage systems make persistence guarantees even if the system crashes at any time, which they achieve using recovery procedures that run after a crash. We present Argosy, a framework for machine-checked proofs of storage systems that supports layered recovery implementations with modular proofs. Reasoning about layered recovery procedures is especially challenging because the system can crash in the middle of a more abstract layer's recovery procedure and must start over with the lowest-level recovery procedure.This paper introduces recovery refinement, a set of conditions that ensure proper implementation of an interface with a recovery procedure. Argosy includes a proof that recovery refinements compose, using Kleene algebra for concise definitions and metatheory. We implemented Crash Hoare Logic, the program logic used by FSCQ [8], to prove recovery refinement, and demonstrated the whole system by verifying an example of layered recovery featuring a write-ahead log running on top of a disk replication system. The metatheory of the framework, the soundness of the program logic, and these examples are all verified in the Coq proof assistant.

Separation Logic-Based Verification Atop a Binary-Compatible Filesystem Model

“…Two tangentially related systems with similar aims to AbsFAT are the work of Koh et al [16] towards verifying the operating system components involved in a networked server, and the work of Chajed et al [4] on Argosy, a verified system for stacking storage layers. While these systems are executable, they do not offer the sort of support for constructing and simplifying proofs about filesystem clients that AbsFAT does.…”

Verifying concurrent, crash-safe systems with Perennial

“…Verified crash safety. Recently several verification frameworks have tackled the problem of crash safety of sequential systems, including verified file systems [5,7,10,34]. These systems address many issues, including handling crashes during recovery and giving an abstract specification that covers non-crashing and crashing execution separately.…”

“…This requirement is enforced in two ways: first, the crash invariant is also a crash invariant for recovery, as specified by CrashInv ; and second, the idempotence condition requires that the crash invariant be itself crash invariant by only referring to durable resources. The requirement that recovery maintain a crash invariant corresponds to the idempotence principle identified in previous sequential verification systems [5,7,31,34].…”

“…Several existing verified storage systems address many aspects of crash safety [5,7,10,34], but they support only sequential execution. There has also been great progress in verifying concurrent systems [4,13,14,20,23,41], but none support crash safety reasoning.…”

“…Our prototypes of Perennial and Goose have some limitations. Perennial does not currently support composing layers of abstraction; we believe that extending multilayered frameworks like CertiKOS [13] and Argosy [5] to the concurrent crash setting is feasible. Perennial proofs only cover safety properties and not liveness, as is typical in concurrent verification.…”