On Wed, Sep 21, 2022 at 4:48 AM Gerd Hoffmann <kraxel(a)redhat.com> wrote:
Hi,
> > Should we have a Fedora feature page for unified kernel support?
>
> I'm not sure we especially want to publicise unified kernel images as
> a standalone thing to users, as it is more of just a building block.
>
> If we're going to show any "feature", I think it probably ought to be
> oriented around a higher level user solution, of which unified kernel
> images are just one piece of the puzzle.
Yes. Just the kernel package updates are not enough. The bare minimum
which I think makes sense as feature is:
(1) adding the unified kernel sub-rpm discussed here, and
(2) bootloader support (be that sd-boot or grub or both), and
(3) kernel install script support (so 'dnf update' kernel updates work).
With that in place it should be possible to install VMs using the
unified kernel sub-rpm and everything works as it did before, even when
it requires some hacks here and there, such as tagging partitions
manually or in kickstart %post for
https://systemd.io/DISCOVERABLE_PARTITIONS/
The above will already plug the initrd hole.
From a kernel standpoint, I am interested in this. We do need to
ensure that we are doing it in a way that is easily extensible to not
just cloud images in the future.
> eg I would see "Trusted boot for cloud images" as a
feature, by which
> I mean publishing cloud images capable of using SecureBoot and vTPM,
> to do attestable boot on UEFI, without the unsigned initrd hole present
> as today.
>
> So, this would mean uing unified kernel images, either directly launched
> from shim, or with sd-boot in there to provide a UI selection. Either
> way not grub, since it is impractical to do attestation with grub's use
> of PCRs. Also likely mean use of discoverable partitions.
Yep, that all makes sense, but I'd tend to not add that as 'required'
to the feature page. My list of nice-to-have optional stuff:
(4) attestable boot (i.e. no grub b/c PCR mess).
(5) provide pre-calculated PCRs (could be published as kernel-pcrs
sub-rpm).
(6) add discoverable partitions to anaconda (so we don't need %post
hacks).
(7) add discoverable partitions to image builder (and whatever else
generates cloud images).
(8) switch cloud images to unified kernels.
I think I've seen fedora feature pages with optional sub-goals before,
even though I can't find one right now, so I think it should be possible
to handle things that way.
> I know there's been some desire to move Fedora cloud images to be UEFI
> only, so it might dovetail with that to some degree.
Hack grub so it can pull out kernel + initrd out of a unified kernel
image and boot unified kernel images in bios mode that way should be
possible. Would allow to migrate cloud images to unified kernels without
requiring UEFI.
> It would likely
> touch kernel, anaconda, systemd and cloud images, so there's some
> coordination & discussion needed to agree on the big picture.
Sure. Having a feature page drawing that big picture would be helpful
for these discussions I think ...
Definitely a system wide change. While there are some logistics to
work out on the kernel side, most of the work is packaging. I would
guess timelines will need to be defined by the teams where code is
needed.
Justin
> take care,
> Gerd
> _______________________________________________
> kernel mailing list -- kernel(a)lists.fedoraproject.org
> To unsubscribe send an email to kernel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
> Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue