Feature request: Subvol-verity

[Winterhuman]

It would be incredibly useful to have BTRFS support per-subvolume dm-verity style root hashes which can be used as a replacement for dm-verity, BTRFS already implements checksums for integrity (and fs-verity), however, there's no roothash option that can be specified like with dm-verity. Here's the proposal:

• Implement a verity flag that can be toggled per-subvolume. When enabled, btrfs subvolume show will display the subvol's root hash which is calculated periodically (or on write or some other trigger).
• Require verity subvol's to be mounted with mount -o subvol=veritysubvol,subvolhash=... similar to how roothash is needed for mounting verity partitions.

Related: https://github.com/kdave/btrfs-progs/issues/452#issue-1169868223

[kdave]

The keyed hashes mentioned in #452 may be used as a building block, but I don't have a clear picture for the subvolume-only keyed hash. The fsverity also does not apply here.

Let's say we have a keyed hash that's otherwise the checksum of the subvolume tree represented by its first metadata block. That hash could be also used for the roothash, it's accessible and can be printed from 'subvolume show'. Should the subvolume be read-write or read-only? For RO it's clear as there won't be any change so the root hash would stay and can be stored on a separate filesystem and used for mount. If the subvolume should also be RW, the initial mount will verify the hash but after any write the hash needs to be updated again before next mount. Here I'd need some more detailed description about the usecase.

I'm not sure if the simple check of the root hash as mount opiton and in the metadata block is sufficient. Any corruption or out-of-band change to data or metadata will be detected at the time the data are needed, which may be way after the mount. Is that sufficient? Full scan of the subvolume tree metadata would potentially take a lot of time during mount.

[Winterhuman]

I think assuming the subvolume is read-only when the hash is calculated would be the right decision, taking care of read-write would probably complicate things as you said (toggling the RO state, or creating a snapshot, would take care of RW most likely).

As for handling out-of-band writes, I think it's fine if it gets detected after mounting for now, this seems like something that can be improved at a later point when other features come into play perhaps. Or maybe doing a slow, full check could be a separate optional mount option?

My use-case for this feature is to create a RO usr subvolume, with a subvolhash mount option stated in the cmdline of an .efi file (signed).