Enabling fsverity on the initial ostree deployment

[rborn-tx]

I'm working with integrating composefs into our distro (Torizon OS) and a question came up that I couldn't figure out by looking at the current docs/code/issues (including #2867) so I was hoping someone could help me here.

Just to explain our use case, we use the Yocto/OpenEmbedded layer meta-updater which, as part of the build process, commits the whole directory tree representing the rootfs of the system into a "long-lived" ostree repository and then produces a new sysroot, populates it with the same commit (by pulling from the former repo) and generates a new deployment in that sysroot; the resulting sysroot is then packed into a tarball that becomes part of an installer image.

Later, a installer executed on a target device creates a partition on the storage device, formats it with the proper fs (and fs options) and populates it by unpacking the tarball from the installer image.

In the composefs use case, I was wondering what would be the proper process for enabling fsverity on the composefs image belonging to this initial deployment that was produced on a build machine. For new deployments produced on the device, I see that ostree already carries out the enabling at deployment time which seems the best thing to do. But, for the initial deployment at least in our use case where the pack/unpack the sysroot the verity information would be lost anyway (even if it existed on the repo on the build machine).

Considering the above I imagined some possibilities:

1. verity could be enabled by the OS installer.
2. verity could be enabled by some process on the ramdisk before executing ostree-prepare-root.
3. verity could be enabled by ostree-prepare-root itself.

For me it seems option (3) would be the easiest for integrating ostree+composefs into our solution but checking the code it doesn't look like ostree-prepare-root is trying to enable verity on the cfs image; it seems to only perform the fsverity "measure" operation when mounting the image.

Finally my questions:

• Have you guys considered this initial deployment where verity might not be enabled?
• Are there recommendations on where to enable fsverity on the composefs image?
• Would there be any concerns (maybe security related) with enabling verity in ostree-prepare-root?

Thanks in advance for any help!

[cgwalters]

The #3094 command was motivated by this problem of a disk image building tool being unaware of fsverity. If you need to stick with the "unpack a tarball" flow, then you'll need to do something like that.

Another option is to switch from tar to a custom format which is aware of fsverity. (I am not aware of one, but it wouldn't be really hard)

I personally think the best option is to have the ostree CLI directly write to the disk image, but I understand why in some cross-compilation environments that may be difficult.

Would there be any concerns (maybe security related) with enabling verity in ostree-prepare-root?

This one I think is just a bad idea, not just from a security PoV but also it would add nontrivial firstboot latency.