wip: Install with fsverity #935
Conversation
|
Needs a rebase, conflicts should be relatively straightforward to fix |
|
Can you explain some scenarios where we might want to have fs-verity disabled? Is it just on filesystems that can't support it? Because even without checking the verity data or anything, I find the "this inode is now immutable" thing to be extremely compelling, particularly in the presence of multiple hardlinks.... |
That's by far the biggest case. However, there is some generic overhead to having it...this isn't quite as relevant for bootc but it would be for taking fsverity in container runtimes in general. There are people that disable selinux to claw back like 1-2% of performance and fsverity is a bit like that, you just have this cost to paging in new code and doing cryptographic verification. But supporting deploying to filesystems without it is 94.3% of the rationale for bootc.
Definitely! Before composefs existed I was trying to push for fsverity in ostree just for this reason...but I struggled with tying it to a higher level integrity story. Thankfully we have that now! |
cgwalters
force-pushed
the
install-config-verity
branch
from
8379be7 to
d045510
Compare
cgwalters
force-pushed
the
install-config-verity
branch
3 times, most recently
from
280cbe6 to
b7cfe64
Compare
|
TODO: Also check for ostreedev/ostree#3354 - if that's set then we should key off it too. In fact, maybe that should be the sole interface for now. |
cgwalters
force-pushed
the
install-config-verity
branch
2 times, most recently
from
403be9a to
0cea6bc
Compare
cgwalters
force-pushed
the
install-config-verity
branch
from
0cea6bc to
d32c973
Compare
Signed-off-by: Colin Walters <[email protected]>
Prep for further work. Signed-off-by: Colin Walters <[email protected]>
Prep for using this to determine fsverity. Signed-off-by: Colin Walters <[email protected]>
In preparation for vendoring composefs-rs from git. Basically before, things work fine when we're just vendoring from crates.io, but fall over when we add a git dependency. The Fedora `cargo_prep` macro writes a hardcoded `.cargo/config.toml` which only has a replacement for `crates.io`, but we need the generated replacement for git too which is output by `cargo vendor-filterer` - which previously we were discarding. This was surprisingly difficult! - Capture the output of `vendor-filterer` - Work around a bug where it puts a broken `directory` path in the generated TOML - Insert that as a new `vendor-config.toml` in our source - Do use `cargo_prep` to init the RPM config in the spec, but re-inject our vendor config appended to that one. Signed-off-by: Colin Walters <[email protected]>
We require a newer Rust. TODO re-enable post 9.6 Signed-off-by: Colin Walters <[email protected]>
To match composefs-rs. Signed-off-by: Colin Walters <[email protected]>
And expose some fsverity helpers. This is just to get the ball rolling on integration. Signed-off-by: Colin Walters <[email protected]>
Key off the ostree prepare-root config to require fsverity on all objects. As part of this: - Add a dependency on composefs-rs just for the fsverity querying APIs, and as prep for further integration. - Add `bootc internals fsck`, which verifies the expected fsverity state. Signed-off-by: Colin Walters <[email protected]>
cgwalters
force-pushed
the
install-config-verity
branch
from
d32c973 to
cfad476
Compare
|
So this is getting closer, but I'm seeing an issue where some zero-sized objects (different ones due to different selinux labels) don't have fsverity enabled. It must be an ostree bug, but I wasn't able to reproduce in a quick test. |
The goal of this PR is to enable in an install config:
to hard require fsverity for
bootc install, and chain it to the ostree config. We're trying to hide the ostree configuration here though.