# 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