---
# System prepended metadata

title: TDX disk design

---

# TDX disk design

Disk == Block storage device

## Goals

- Persistence
  - Persists on reboots
  - Able to migrate to a new machine by copying a few files
- Confidentiality
  - Only the TD can see what is stored in plaintext
- Integrity
  - TD can verify if a unit of storage (not ALL!!) is what it set and not garbage values
- Spatial consistency
  - Reading different parts of the disk return values from the same version
  - Tied to atomicity in writes
- Temporal consistency
  - Reads and writes of a block happen as if laid out in the sequence they were issued and completed
  - Primarily means completed writes always reflect in subsequent reads

## Iffy Assumptions

- Memory is spatially and temporally consistent
  - Not actually true!!
  - Physical attacks can rollback arbitrary memory regions
  - Nevertheless, assume for the sake of analysis

## On temporal consistency

- Likely the hardest guarantee to provide
  - Enclaves are stateless and have to rely on external sources for ordering across reboots
- Strong consistency - As we have defined above
  - Only possible with a trusted external source of state between reboots
- Weak consistency - Consistency after a reboot given an initial root of trust
  - Rely on memory being consistent
  - Memory becomes the holder of root of trust after initial load
  - Do disk consistency checks against root of trust in memory
  - If the root of trust can be verified through external sources, it reduces to the strong form

## LUKS

- Linux Unified Key Setup
- Standard for full-disk encryption in Linux
- Works on a block by block basis
- Immediate verification on read

Analysis:
- Immediate verification on read
- Provides confidentiality
- Provides integrity
- NO consistency
  - Spatial - Individual blocks can trivially return values from any version
  - Temporal - Individual blocks can trivially be rolled forward/backward to any version

## dm-verity

- Device mapper, verity
- Computes a merkle tree over the blocks and stores root in memory
- Does merkle checks to verify blocks
- Immediate verification on read

Analysis:
- Provides integrity
- Provides spatial consistency
    - trivially, there is only one version
- Provides temporal consistency
    - trivially, there are no writes
- Read only
- NO confidentiality
  - Storage is in plaintext

## dm-integrity

- Device mapper, integrity
- Computes an integrity tag and stores it with data
- Immediate verification on read

Analysis:
- Provides integrity
- NO consistency
  - Spatial - Individual blocks can trivially return values from any version
  - Temporal - Individual blocks can trivially be rolled forward/backward to any version
- NO confidentiality
  - Storage is in plaintext

dm-integrity seems to be built for a world with random errors like power failure, not a BFT world with targeted attacks.

## Layering

- Above solutions are not exclusive of each other
- E.g. can layer dm-integrity over a LUKS encrypted disk

## Setup 1: dm-verity over LUKS

- Use case: Provide encrypted data to an enclave whose root hash is known
- More or less giving the enclave an encrypted file
- Better than a simple encrypted file since data can accessed on a block level without needing the whole file decrypted

## What is missing?

- NO solutions that provide writability with consistency
- Ideally we want a writable version of dm-verity over LUKS
- Don't see any reason this cannot exist on a block device level

## BTRFS

- Moving up the stack, to the filesystem level
- Hierarchical merkle tree like structure with root loaded to memory initially
- Immediate verification on read

Analysis:
- Provides integrity
- Provides spatial consistency
- Provides weak temporal consistency
- NO confidentiality
  - Storage is in plaintext
- NO choice of filesystem, enforcing BTRFS on users

## Setup 2: BTRFS over LUKS

- Use case: General purpose authenticated encrypted writable disk
- Enforcing a file system
- BTRFS might not be very bulletproof
- ZFS is a similar option, licensing restrictions unclear

## What next?

Are better designs possible for
- No disk enclave? 
    - ramdisk
- Disk with a single block? Simple file?
    - For persisting small state like configs or secrets