Re: Fixing rpmostree_finalize_kernel hack
- From: Jonathan Lebon <jlebon redhat com>
- To: Jonathan Dickinson <oss jonathan dickinson id>
- Cc: ostree-list <ostree-list gnome org>
- Subject: Re: Fixing rpmostree_finalize_kernel hack
- Date: Thu, 31 Mar 2022 10:03:56 -0400
On Wed, Mar 30, 2022 at 11:23 PM Jonathan Dickinson
<oss jonathan dickinson id> wrote:
Hi everyone,
I am interested in fixing the hack that can currently be found on line 426 of rpm-ostree-kernel.cxx
<https://github.com/coreos/rpm-ostree/blob/86070c18996fd43c4a2d04012edfe2c9ad15dafb/src/libpriv/rpmostree-kernel.cxx#L426>.
I have never worked with this codebase before, but I'm happy to give it a try.
Background
The current behavior prevents the installation of custom kernels authored by "rmnscnce" on COPR
<https://copr.fedorainfracloud.org/coprs/rmnscnce/kernel-xanmod/>, because the .vmlinuz.hmac file contains
an entry along the lines of `/lib/modules/5.16.12-xm1.4.fc35.x86_64/vmlinuz`. This arises because the .spec
calls sha256sum directly on that file. These custom kernels install fine on many other RPM-based distros.
These kernels are extremely popular for scenarios such as waydroid and gaming.
Looking at the stock kernel, the two hmac files are identical (both containing `/boot/...`). This means
that `rpmostree_finalize_kernel` treats them both the same way and essentially ends up performing a
basename on the path contained the hmac file.
I have informed "rmnscnce" about a workaround. Even if they go ahead and use the workaround, this is a
difference in behavior and it should probably be addressed.
Proposal
Given that a basename is the current emergent behavior, I propose formalizing that. Any thoughts on this?
Hi!
It depends what you mean by "that". :)
As mentioned in a comment block above the one to which you linked, I
think ideally kernel packages should stop encoding a full path to the
image. It's distro/variant-specific where the kernel is placed in
`/boot` and no assumptions should be baked into the package (having it
be `/usr/lib/modules/...` is another variant I hadn't seen; that
sounds even more problematic for early boot validation before the
rootfs is mounted).
The dracut FIPS code at least has already been adapted to deal with
relative paths:
https://github.com/dracutdevs/dracut/commit/ba813779bf3d613b841fef2e127b2605fafbaa0c
It's possible that other things which care about the HMAC file will
need a similar tweak.
But if by "that" you mean enhancing rpm-ostree so that it rewrites the
path as just its basename instead of special-casing `/boot`, that
sounds OK to me too short-term (but it still remains a hack :) ).
[
Date Prev][Date Next] [
Thread Prev][Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]