Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Dec 20, 2022 at 04:38:37PM +0100, Dan Horák wrote:
> On Tue, 20 Dec 2022 10:22:03 -0500
> Ben Cotton <bcotton@xxxxxxxxxx> wrote:
> 
> > https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1
> > 
> > This document represents a proposed Change. As part of the Changes
> > process, proposals are publicly announced in order to receive
> > community feedback. This proposal will only be implemented if approved
> > by the Fedora Engineering Steering Committee.
> > 
> > 
> > == Summary ==
> > Add support for unified kernels images to Fedora.
> > 
> > == Owner ==
> > * Name: [[User:kraxel| Gerd Hoffmann]]
> > * Email: kraxel@xxxxxxxxxx
> > 
> > 
> > == Detailed Description ==
> > The goal is to move away from initrd images being generated on the
> > installed machine.  They are generated while building the kernel
> > package instead, then shipped as part of a unified kernel image.
> > 
> > A unified kernel image is an all-in-one efi binary containing kernel,
> > initrd, cmdline and signature.  The secure boot signature covers
> > everything, specifically the initrd is included which is not the case
> > when the initrd gets loaded as separate file from /boot.
> 
> What platforms are going to be affected? Is it x86-64 only or does it
> include aarch64 (as it's also using UEFI)? Are ppc64le and s390x out of
> the current scope?

This change proposal would only be x86_64, since that's the platform
where we need to solve the unsigned initrd problem with SecureBoot
with EDK2/QEMU (and more generally with bare metal, but this change
is limited scope to VMs to make it tractable to pre-built initrds
with a fixed set of kmods).

While aarch64 uses UEFI, there's no viable SecureBoot support for
it in EDK2/QEMU yet. If and when that appears, then it could be
extended to aarch64 at that time.

There's no plans for ppc64le / s390x.

NB, I'm talking from the POV of what we require to address as
virtualization platform maintainers. There might be other use cases
for UKIs from other teams TBD.


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux