Re: Fixing rpmostree_finalize_kernel hack



Thanks for the feedback!

I have implemented the new hack: https://github.com/coreos/rpm-ostree/pull/3563. It passes the kola test suite. I also checked that the problematic kernel installs on Core-OS and Silverblue 36 with this patch applied.

On Thu, Mar 31, 2022 at 10:04 AM Jonathan Lebon <jlebon redhat com> wrote:
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]