-
Notifications
You must be signed in to change notification settings - Fork 297
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
deploy: Don't recompute verity checksums if not enabled #3326
Conversation
7829003
to
67e81fd
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have a good high-level picture of what this code is trying to do, but I have some C/GVariant-related comments.
This fixes a truly horrific performance bug when composefs is enabled, but fsverity is not supported by the filesystem. We'd fall back to doing *userspace* checksumming of all files at deployment time which was absolutely not expected or required. There's really an immense amount of technical debt here, such as the confusion between `ex-integity.composefs` vs the prepare-root config, how we handle "torn" states where some objects don't have verity enabled but some do, etc. The ostree composefs state has two modes: - signed: We need to enforce fsverity - unsigned: Best effort resilience So we fix this by making the deploy path to make verity "opportunistic" - if the ioctl gives us the data, then we add it to the composefs. However, this code path is also invoked when we're computing the expected composefs digest to inject as commit metadata, and *that* API must work regardless of whether the target repo has fsverity enabled as it may operate on a build server. One lucky thing in all of this: When I went to add the "checkout composefs" API I added a stub `GVariant` for options extensibility, which we now use. Signed-off-by: Colin Walters <walters@verbum.org>
67e81fd
to
a6d07b6
Compare
One possible followup in #3327 |
Re this code alex wrote most of it originally... @alexlarsson mind giving this a quick skim from a high level? But we can't always get his time. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
@allisonkarlitskaya you need to at least change your review status from "changes requested" to "approve" |
This effectively reverts coreos@c115600 I was wrong, if we don't have fsverity today on the repo (a common case) then this entails a full read of all files. For more information see ostreedev/ostree#3326
This effectively reverts coreos@c115600 I was wrong, if we don't have fsverity today on the repo (a common case) then this entails a full read of all files. For more information see ostreedev/ostree#3326 Signed-off-by: Colin Walters <walters@verbum.org>
This fixes a truly horrific performance bug when
composefs is enabled, but fsverity is not supported by the filesystem. We'd fall back to doing userspace checksumming of all files at deployment time which was absolutely not expected or required.
There's really an immense amount of technical debt here, such as the confusion between
ex-integity.composefs
vs the prepare-root config, how we handle "torn" states where some objects don't have verity enabled but some do, etc.The ostree composefs state has two modes:
So we fix this by making the deploy path to make verity "opportunistic" - if the ioctl gives us the data, then we add it to the composefs.
However, this code path is also invoked when we're computing the expected composefs digest to inject
as commit metadata, and that API must work regardless of whether the target repo has fsverity enabled as it may operate on a build server.
One lucky thing in all of this: When I went to add the "checkout composefs" API I added a stub
GVariant
for options extensibility, which we now use.