Path toward having a measurable dom0

[tlaurion]

Torward measuring templates integrity between updates dom0 is now separated from vm-pool

If going with measurable dom0, I'd simply put it outside of LVM thin pool, as a static LVM volume. That would have other benefits as well, like safety against filling up thin pool. The downside is wasting some of disk space - you need an extra space in dom0 that is rarely used (unpacking templates, temporary storage for backups etc) - with static LVM volume, you can't reuse it for running VMs. But if going for R/O dom0, that would need to be elsewhere anyway, so it shouldn't be an issue.

Then, having measured dom0, you can leave measuring templates to that dom0.

Originally posted by @marmarek in linuxboot/heads#202 (comment)

But how to reach the goal of being able to measure dom0 from the bootloader?

PoC and original discussion https://groups.google.com/g/qubes-devel/c/hG93VcwWtRY

[asharp]

If you're using grub with tpm support (#9165 ), then you would have measurement up to the initramfs. From there, you could have two boot options:

1. Boot dom0 with an overlayfs of a dm-verity'd / and an ephemeral scratch, so you'd start every boot at a known state or
2. Boot dom0 with a raw / which you could then change/update. You'd then have a script to rebuild the verity hashes and reseal the tpm .

On a similar note, you could split the / of templates to be some overlay of a dm verity'd base /, signed by the upstream template provider, and a local changes lv that should be small, easy to reset and simpler to verify.

[DemiMarie]

I think are two different ways to use measured boot:

1. Secure unlock of the dom0 storage: This verifies that the dom0 storage was produced by a trusted system, because an untrusted system would not have been able to generate the image. This does not protect against persistance, but does (hopefully) protect against evil-maid and similar attacks.

   To protect against replay attacks, it is necessary to have trusted nonvolatile storage. Partial protection can be provided by writing the replay token at shutdown and after system upgrades. Full protection requires a hardware token that can be written to on every fsync(), which likely requires custom hardware (such as a future version of Fobnail) with battery-backed SRAM.

   Integrity requires dm-X (out of tree) or encrypted bcachefs (experimental, has nonce reuse problems).

2. Verified boot of dom0, preventing persistence. This requires at a minimum dm-verity.