Logo
ScienceStack
Table of Contents
Fetching ...
Sign In

Rollbaccine : Herd Immunity against Storage Rollback Attacks in TEEs [Technical Report]

David Chu, Aditya Balasubramanian, Dee Bao, Natacha Crooks, Heidi Howard, Lucky E. Katahanas, Soujanya Ponnapalli

TL;DR

Rollbaccine tackles the problem that TEEs protect in-memory data but not disk state, leaving applications vulnerable to disk rollback attacks. It uses a device-mapper that intercepts and replicates writes across a primary-backup setup to restore a disk state that could have occurred after a benign crash, thereby achieving general, automatic rollback resistance for unmodified applications. The approach formalizes block-device crash consistency, proves Rollbaccine preserves this property, and shows practical performance: overhead remains modest (generally around 19% with targeted cases higher for fsync-heavy workloads) while delivering rollback resistance comparable to or better than bespoke, manual solutions like Nimble. The system is implemented in the kernel, relies on standard Linux persistence flags, and uses fault-tolerant replication with Paxos/CCF for recovery, making it a viable drop-in defense for cloud TEEs and storage stacks with broad applicability.

Abstract

Today, users can "lift-and-shift" unmodified applications into modern, VM-based Trusted Execution Environments (TEEs) in order to gain hardware-based security guarantees. However, TEEs do not protect applications against disk rollback attacks, where persistent storage can be reverted to an earlier state after a crash; existing rollback resistance solutions either only support a subset of applications or require code modification. Our key insight is that restoring disk consistency after a rollback attack guarantees rollback resistance for any application. We present Rollbaccine, a device mapper that provides automatic rollback resistance for all applications by provably preserving disk consistency. Rollbaccine intercepts and replicates writes to disk, restores lost state from backups during recovery, and minimizes overheads by taking advantage of the weak, multi-threaded semantics of disk operations. Rollbaccine performs on-par with state-of-the-art, non-automatic rollback resistant solutions; in fact, across benchmarks over PostgreSQL, HDFS, and two file systems (ext4 and xfs), Rollbaccine adds only 19% overhead, except for the fsync-heavy Filebench Varmail.

Rollbaccine : Herd Immunity against Storage Rollback Attacks in TEEs [Technical Report]

TL;DR

Rollbaccine tackles the problem that TEEs protect in-memory data but not disk state, leaving applications vulnerable to disk rollback attacks. It uses a device-mapper that intercepts and replicates writes across a primary-backup setup to restore a disk state that could have occurred after a benign crash, thereby achieving general, automatic rollback resistance for unmodified applications. The approach formalizes block-device crash consistency, proves Rollbaccine preserves this property, and shows practical performance: overhead remains modest (generally around 19% with targeted cases higher for fsync-heavy workloads) while delivering rollback resistance comparable to or better than bespoke, manual solutions like Nimble. The system is implemented in the kernel, relies on standard Linux persistence flags, and uses fault-tolerant replication with Paxos/CCF for recovery, making it a viable drop-in defense for cloud TEEs and storage stacks with broad applicability.

Abstract

Today, users can "lift-and-shift" unmodified applications into modern, VM-based Trusted Execution Environments (TEEs) in order to gain hardware-based security guarantees. However, TEEs do not protect applications against disk rollback attacks, where persistent storage can be reverted to an earlier state after a crash; existing rollback resistance solutions either only support a subset of applications or require code modification. Our key insight is that restoring disk consistency after a rollback attack guarantees rollback resistance for any application. We present Rollbaccine, a device mapper that provides automatic rollback resistance for all applications by provably preserving disk consistency. Rollbaccine intercepts and replicates writes to disk, restores lost state from backups during recovery, and minimizes overheads by taking advantage of the weak, multi-threaded semantics of disk operations. Rollbaccine performs on-par with state-of-the-art, non-automatic rollback resistant solutions; in fact, across benchmarks over PostgreSQL, HDFS, and two file systems (ext4 and xfs), Rollbaccine adds only 19% overhead, except for the fsync-heavy Filebench Varmail.
Paper Structure (24 sections, 4 theorems, 8 figures, 1 table)

This paper contains 24 sections, 4 theorems, 8 figures, 1 table.

Table of Contents

  1. Introduction
  2. Motivation and Threat Model
  3. The Dangers of Rollbacks
  4. Threat Model and Guarantees
  5. Limitations
  6. Towards Rollbaccine
  7. Block Device Crash Consistency
  8. System Model
  9. Design
  10. Critical Path
  11. Asynchronous writes on the primary
  12. Asynchronous writes arriving at the backups
  13. Synchronous writes
  14. Reads
  15. Recovery
  16. ...and 9 more sections

Key Result

Theorem 1

All histories produced by Rollbaccine are block device crash consistent.

Figures (8)

  • Figure 1: The Linux storage stack. Block I/Os tagged with O_DIRECT bypass the page cache.
  • Figure 2: Rollbaccine on the critical path with $f = 1$.
  • Figure 3: Rollbaccine concurrency handling. "Pop" and "push" are operations over the pending queue, and "insert" and "remove" are operations over the invoked tree.
  • Figure 4: PostgreSQL TPC-C throughput-latency graph[ with 20, 30, 40, and 50 clients].
  • Figure 5: Performance results. [Each bar is labeled with the exact throughput on top.]
  • ...and 3 more figures

Theorems & Definitions (13)

  • Definition 2.1: Rollback attack
  • Definition 2.2: Rollback detection
  • Definition 2.3: Rollback resistance
  • Definition 4.1: Sequential history
  • Definition 4.2: Happens-before
  • Definition 4.3: Reads-see-writes
  • Definition 4.4: Linearizable history
  • Definition 4.5: Durable cut
  • Definition 4.6: Block device crash consistency
  • Theorem 1
  • ...and 3 more