On Tue, Dec 20, 2022 at 02:56:41PM -0500, Demi Marie Obenour wrote: > On 12/20/22 10:22, Ben Cotton 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. > > > > Main motivation for this move is to make the distro more robust and more secure. > > > > Switching the whole distro over to unified kernels quickly is not > > realistic though. Too many features are depending on the current > > workflow with a host-specific initrd (and host-specific kernel command > > line), which is fundamentally incompatible with unified kernels where > > everybody will have the same initrd and command line. Thats why there > > is 'Phase 1' in title, so we can have more Phases in future releases > > 😃 > > > > A host-specific initrd / command line is needed today for: > > > > * features needing optional dracut modules (initrd rebuild needed to > > enable them). > > * configuration / secrets baked into the initrd (booting from iscsi > > for example). > > * configuration being specified on the kernel command line. > > ** root filesystem being the most important one. > > [https://systemd.io/DISCOVERABLE_PARTITIONS/ Discoverable partitions] > > allow to remove this. > > > > Phase 1 goals (high priority): > > > > * Ship a unified kernel image as (optional) kernel sub-rpm. Users can > > opt-in to use that kernel by installing the sub-rpm. Initial focus is > > on booting virtual machines where we have a relatively small and well > > defined set of drivers / features needed. Supporting modern physical > > machines with standard setup (i.e. boot from local sata/nvme storage) > > too should be easy. > > * Update kernel install scripts so unified kernels are installed and > > updated properly. > > * Add bootloader support for unified kernel images. Add > > [https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-2-efi-unified-kernel-images > > unified kernel bls support] to grub2, or support using systemd-boot, > > or both. > > > > Phase 1 goals (lower priority, might move to Phase 2): > > > > * Add proper discoverable partitions support to installers (anaconda, > > image builder, ...). > > ** Temporary workaround possible: set types using sfdisk in %post script. > > ** When using btrfs: configure 'root' subvolume as default volume. > > * Add proper systemd-boot support to installers. > > ** Temporary workaround possible: run 'bootctl install' in %post script. > > * Better measurement and remote attestation support. > > ** store kernel + initrd hashes somewhere (kernel-hashes.rpm ?) to > > allow pre-calculate TPM PCR values. > > ** avoid using grub2 (measures every config file line executed which > > is next to impossible to pre-calculate). > > * Switch cloud images to use unified kernels. > > How do you plan to handle system recovery? For VMs this is much > less of a concern, but on bare metal there needs to be a way for > a local, authenticated administrator to obtain a root shell on > the system console even if the root filesystem cannot be mounted. > This has saved my system more than once. Note this proposal is only targetting making UKIs available as an optional feature for use with VMs. As such needs for a recovery root shell are minimal, and bare metal is not impacted wrt its featureset today. > Also, how will Xen be supported in this model? Will the hypervisor > be part of an alternate UKI? CCing Marek Marczykowski-Gorécki of > Qubes OS. Xen has only been considered from the POV of the guest, since this proposal is only targetting guest usage. The UKIs are proposed to include the Xen block driver in the initrd. Nothing is changing that impacts the Hypervisor side. 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
