container: Move .vmlinuz.hmac along with the kernel in split-kernel-and-rootfs - #2499
cgwalters-bot wants to merge 1 commit into
Conversation
| /// | ||
| /// ostree and kernel-install copy this next to the kernel when installing it, | ||
| /// so it must travel with the kernel. | ||
| pub(crate) const VMLINUZ_HMAC: &str = ".vmlinuz.hmac"; |
There was a problem hiding this comment.
This is AFAIK only implemented by Fedora (and really RHEL in FIPS mode) derivatives.
We should call that out.
I wonder if we want a more generalizable "list of vmlinuz-associated-files" that various OSes/distributions may have invented?
There was a problem hiding this comment.
Agreed; reworked it into a documented KERNEL_COMPANION_FILES list, which split_kernel moves next to vmlinuz when present. The docs, man page and commit message now say the HMAC is a Fedora/RHEL thing (FIPS).
The list has one entry, .vmlinuz.hmac, because that's the only per-kernel companion I found in /usr/lib/modules/<kver>/. Debian/Ubuntu kernels live in /boot, and Arch only adds pkgbase there. openSUSE's usrmerged spec also seems to put a .vmlinuz.hmac there, which this would pick up. ostree's other inputs from that directory (devicetree/dtb/, aboot.img) are separate boot inputs rather than companions of the kernel binary. config/System.map/symvers are userspace metadata, so they stay in the rootfs, and the data-driven test checks that. If you'd rather dtb/ travel too for aarch64 UKIs, it would be a one-line addition.
Squashed into the PR's single commit, now 8cf8eba. It no longer carries your Signed-off-by: the bot can't re-add it with you as committer, which the DCO check needs, so please re-run dco-signoff (or approve here for bot-pr signoff).
Generated-by: https://github.com/cgwalters/#llms
43b9a99 to
8cf8eba
Compare
8cf8eba to
4c030e7
Compare
…nd-rootfs Fedora and RHEL derivatives ship the kernel's FIPS HMAC as /usr/lib/modules/<kver>/.vmlinuz.hmac, which ostree and kernel-install copy next to vmlinuz when installing it. split-kernel-and-rootfs moved vmlinuz and the initramfs out but left the HMAC behind, orphaned in the rootfs of a sealed image. Keep a small documented list of files that belong to the kernel binary and move them into the output directory next to vmlinuz, under the same names, so they go wherever the kernel goes. The HMAC is the only entry today: Debian, Ubuntu and Arch ship no such companion there, and the other files ostree takes from this directory (devicetree, dtb/, aboot.img) are separate boot inputs, while config and System.map are userspace metadata that should stay in the rootfs. While here, move the logic into kernel.rs as a cap-std based function so it can be unit tested. Generated-by: AI Signed-off-by: Colin Walters <walters@verbum.org>
|
Rebased onto main; 1 commit, no content change. Generated-by: https://github.com/cgwalters/#llms |
4c030e7 to
fb790a0
Compare
bootc container split-kernel-and-rootfsmovesvmlinuzandinitramfs.imgout of/usr/lib/modules/<kver>/, but it left the kernel's FIPS HMAC (.vmlinuz.hmac) behind, orphaned in the rootfs of a sealed image. This moves it into<output>/<kver>/next tovmlinuz, under the same name, matching where ostree looks for it next to the kernel inusr/lib/modules/<kver>/(ostree installs it as.vmlinuz-<kver>.hmacbeside the kernel in its boot directory). The split logic moves intokernel.rsso it can be unit tested.Found while building the rhel-bootc-examples sealing example.
Testing, on a 16-core devspace:
just unit-testspassed, including the newkernel::tests::test_split_kernel{,_uki};just validateandjust buildpassed.bootc container ukify --kernel-dirin a tools stage, following the rhel-bootc-examples sealing Containerfile). With the stock bootc 1.16.13,/usr/lib/modules/6.12.0-269.el10.x86_64/.vmlinuz.hmacstayed in the final image. With this change it lands in/kernel/<kver>/next tovmlinuz, nothing is left in/usr/lib/modules, and ukify still builds the UKI.Caveat: in a UKI boot, dracut's FIPS check looks for
/boot/EFI/Linux/*-$(uname -r).efiand its.hmac, which doesn't match bootc'sEFI/Linux/bootc/UKI naming, so FIPS on sealed images needs separate design work; this PR only keeps the rootfs clean.The
Signed-off-by: Colin Walters <walters@verbum.org>on these commits was added on cgwalters's approval of the review draft: cgwalters-forge#21 (review)Generated-by: https://github.com/cgwalters/#llms