You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Initial support for fs-verity landed in #1959 - it's only useful for experimentation and as a starting point.
Using fs-verity is natural for OSTree because it's file-based,
as opposed to block based (like dm-verity). This only covers
files - not symlinks or directories. And we clearly need to
have integrity for the deployment directories at least.
The core idea is to split the tradeoffs between dual partition dm-verity and current ostree by having "pack files" (signed by vendor) that include the metadata plus small files, and files with nontrivial size are signed separately.
The storage would look like (using / to mean the physical /sysroot):
The verity/objects files are hardlinked to /ostree/verity/deploy/<deploycommit>.<serial>.
On boot, we do Secure Boot, then verify the initramfs. We mount the root storage device, then check that the signature on the target pack file, then unpack it into a tmpfs. We also need to check the signature on each separated file.
We then create an overlayfs using that as the top layer, and the verity deploydir as the underlying layer.
Advantages:
Disk space usage is still proportial to number of deployments (e.g. one deployment means only one copy of OS)
I don't think there's a way for an attacker to persist OS code
Disadvantages:
We're not sharing the metadata objects across deployments
Need to invent some new mechanism to do incremental downloads of these pack files most likely
Also I don't know if any of this will work - this is just a strawman proposal.
The text was updated successfully, but these errors were encountered:
One big topic related to this is...I feel like we could make some major cleanups if we effectively added a new libostree backend that hard-required fs-verity. But, everyone using it today shipped OSes that use the current format so some sort of hard transition won't fly really.
Initial support for fs-verity landed in #1959 - it's only useful for experimentation and as a starting point.
Using fs-verity is natural for OSTree because it's file-based,
as opposed to block based (like dm-verity). This only covers
files - not symlinks or directories. And we clearly need to
have integrity for the deployment directories at least.
More background on fs-verity:
Pack files + overlayfs
The core idea is to split the tradeoffs between dual partition dm-verity and current ostree by having "pack files" (signed by vendor) that include the metadata plus small files, and files with nontrivial size are signed separately.
The storage would look like (using
/
to mean the physical/sysroot
):The
verity/objects
files are hardlinked to/ostree/verity/deploy/<deploycommit>.<serial>
.On boot, we do Secure Boot, then verify the initramfs. We mount the root storage device, then check that the signature on the target pack file, then unpack it into a
tmpfs
. We also need to check the signature on each separated file.We then create an
overlayfs
using that as the top layer, and the verity deploydir as the underlying layer.Advantages:
Disadvantages:
Also I don't know if any of this will work - this is just a strawman proposal.
The text was updated successfully, but these errors were encountered: