Add initial composefs integration #2640

This parses keys like yes/no/maybe. The introduced OtTristate type is compatible with the existing _OstreeFeatureSupport type.

This code signs a fsverity digest (using openssl) such that the resulting signature can be used with the FS_IOC_ENABLE_VERITY ioctl.

The composefs code will need this.

This supports checking out a commit into a tree which is then converted into a composefs image containing fs-verity digests for all the regular files, and payloads that are relative to a the `repo/objects` directory of a bare ostree repo. Some specal files are always created in the image. This ensures that various directories (usr, etc, boot, var, sysroot) exists in the created image, even if they were not in the source commit. These are needed (as bindmount targets) if you want to boot from the image. In the non-composefs case these are just created as needed in the checked out deploydir, but we can't do that here. This is all controlled by the new ex-integrity config section, which has the following layout: ``` [ex-integrity] fsverity=yes/no/maybe composefs=yes/no/maybe composefs-apply-sig=yes/no composefs-add-metadata=yes/no composefs-keyfiile=/a/path composefs-certfile=/a/path ``` The `fsverity` key overrides the old `ex-fsverity` section if specified. The default for all these is for the new behaviour to be disabled. Additionally, enabling composefs implies fsverity defaults to `maybe`, to avoid having to set both.

If `composefs-apply-sig` is enabled (default no) we add an ostree.composefs digest to the commit metadata. This can be verified on deploy. This is a separate option from the generic `composefs` option which controls whether composefs is used during deploy. It is separate because we want to not have to force use of fs-verity, etc during the build. If the `composefs-certfile` and `composefs-keyfile` keys in the ex-integrity group are set, then the commit metadata also gets a ostree.composefs-sig containing the signature of the composefs file.

This can be used as a composefs source for the root fs instead of the checkout by pointing the basedir to /ostree/repo/objects. We only write the file is `composefs` is enabled. We enable ensure_rootfs_dirs when building the image which adds the required root dirs to the image. In particular, this includes /etc which often isn't in ostree commits in use. We also create an (empty) .ostree.mnt directory, where composefs will mount the erofs image that will be used as overlayfs lowerdir for the root overlayfs mount. This way we can find the deploy dir from the root overlayfs mount options. If the commit has composefs digests recorded we verify those with the created file. It also applies the fs-verity signature if it is recorded, unless this is disabled with the ex-integrity.composefs-apply-sign=false option.

In many cases, such as when using osbuild, we are not preparing the final deployment but rather a rootfs tree that will eventually be copied to the final location. In that case we don't want to apply the signature directly but when the deployment is copied in place. To make this situateion workable we also write the signature to a file next to the composefs image file. Then whatever mechanism that does the final copy can apply the signature.

This changes it into read_proc_cmdline_key(), as this will later be used to read additional keys.

This changes ostree-prepare-root to use the .ostree.cfs image as a composefs filesystem, instead of the checkout. By default, composefs is used if support is built in and the .ostree.cfs file exists in the deploy dir, otherwise we fall back to the old method. However, if the ot-composefs kernel option is specified this can be tweaked as per: * off: Never use composefsz * maybe: Use if possible * on: Fail if not possible * signed: Fail if the cfs image is not fs-verity signed with a key in the keyring. * digest=....: Fail if the cfs image does not match the specified digest. The final layout when composefs is active is: / ro overlayfs mount for composefs /sysroot "real" root /etc rw bind mount to $deploydir/etc /var rw bind mount to $vardir We also specify the $deploydir/.ostree-mnt directory as the (internal) mountpoint for the erofs mount for composefs. This can be used to map the root fs back to the deploy id/dir in use, A further note: I didn't test the .usr-ovl-work overlayfs case, but a comment mentions that you can't mount overlayfs on top of a readonly mount. That seems incompatible with composefs. If this is needed we have to merge that with the overlayfs that composefs itself sets up, which is possible with the libcomposefs APIs.

In the case of composefs, we cannot compare the devino of the rootfs and the deploy dir, because the root is the composefs mount, not a bind mount. Instead we check the devino of the etc subdir of the deploy, because this is a bind mount even when using composefs.

When using composefs the root fs will always be read-only, but in this case we should still continue remounting /sysroot. So, we record a /run/ostree-composefs-root.stamp file in ostree-prepare-root if composefs is used, and then react to it in ostree-remount.

Instead of using pkg-config, etc we just include composefs. In the end the library is just 5 c source files, and it is set up to be easy to use as a submodule. For now, composefs support is disabled by default.

This enables --with-composefs on: * Fedora Latest * Debian Testing * Ubuntu Latest These all should have new enough version of dependencies.

We can't safely apply the fs-verity with signature until we have booted with the new initrd, because the public key that matches the signature is loaded from it. So, instead we save the .sig file next to the compoosefs, and on the first boot we detect that it is there, and the composefs file isn't fs-verity, so we apply it. Things get a bit more complex due to having to temporarily make /sysroot read-write for the fsverity operation too.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add initial composefs integration #2640

Add initial composefs integration #2640

Commits on May 31, 2023