Design

We've decided to keep support for legacy pools. All operations but create will be available for legacy pools so no new legacy pools can be created. We've also decided to leave pool level metadata unencrypted.

The stacking is:

Thin pool/filesystems (format here unchanged)

Encryption layer

• Single crypt device
• Stratis token removed
  • No longer need Stratis tokens to identify devices as BDA is unencrypted
  • [FUTURE PLAN] Potential changes to statically assigned tokens so that multiple Clevis bindings can be added

Cache tier/cap device

• Cache tier unchanged other than encryption header has been removed from cache tier as encryption is now inherited from layer above
  • Discoverable by BDA (static header and MDA)
• Cap device is there in the non-cache case for support for re-encrypt (see above layer)
• [COMPLETE] Space reserved for crypt metadata to support changing from unencrypted to encrypted pool

Linear concatenation device/[FUTURE PLAN] RAID

• Concatenates all devices in the pool together in the non RAID case
• Otherwise RAID

[FUTURE PLAN] Integrity

• Should be relatively straightforward if space is reserved in data tier

Data tier

• We plan to leave space for RAID metadata in case we support conversion from no RAID to RAID in the future. At this time, we plan to only support RAID at pool creation time.
•  [CURRENT WORK] Add space for integrity metadata. Need to nail down a few design questions about accidental vs. malicious modification.

BDA (static header and MDA)

• Format unchanged, no longer encrypted, always discoverable at the beginning of the device

Encryption implementation

Encryption will sit on top of the cap device just below the thin pool. The benefits of this are:

1. The cache will be encrypted as a side effect of the new stacking with no need for special handling. All data that passes through the cache will be encrypted by the crypt layer sitting on top of it.
2. There is a single unlock operation that needs to be done per pool. Key generation is intentionally expensive so limiting passes through Argon/PBKDF by limiting the number of operations to 1 as opposed to scaling linearly with the number of devices in the pool will speed up encryption operations.
3. Adding RAID beneath the crypt device will yield much better performance than RAID on top of multiple crypt devices.
4. Easy support for changing from unencrypted to encrypted device through reencryption provided by cryptsetup.

Drawbacks:

1. Some users have expressed a desire for our pool level metadata to be encrypted.