>From the point of view of the workstation experience (with a laptop), I see no discussion on how this may impact hibernation. Currently, I have secure boot disabled essentially because I want my laptop to automatically hibernate (and recover from that state) whenever it is suspended for a number of hours. I would like to see a path forward here with secure boot enabled. Thanks, Iñaki On Tue, 20 Dec 2022 at 16:22, 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. > > 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. > > Phase 2/3 goals (longer-term stuff which is not realistic to complete for F38). > > * Move away from using the kernel command line for configuration. > * Move away from storing secrets in the initrd. > * Handle dracut optional modules in a different way. > > systemd has some building blocks which can be used, although none of > them are used by fedora today. > [https://www.freedesktop.org/software/systemd/man/systemd-creds.html > systemd credentials] can be used for secrets (also for configuration). > The [https://www.freedesktop.org/software/systemd/man/systemd-stub.html > unified kernel stub] can load credentials from the ESP. > > The unified kernel stub can also load > [https://www.freedesktop.org/software/systemd/man/systemd-sysext.html > extensions] from the ESP, which can possibly be used to replace > optional dracut modules. > > == Feedback == > > > == Benefit to Fedora == > * Better secure boot support (specifically the initrd is covered by > the signature). > * Better confidential computing support (measurements are much more > useful if we know what hashes to expect for the initrd). > * More robust boot process (generating the initrd on the installed > system is fragile, root cause for kernel bugs reported is simply a > broken initrd sometimes). > > == Scope == > * Proposal owners: > ** Update kernel build to create unified kernel sub-package. > *** part one: [https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2179 > PR#2179] > *** part two: (wip) > [https://gitlab.com/kraxel/kernel-ark/-/commits/unified/ > https://gitlab.com/kraxel/kernel-ark/-/commits/unified/] > > * Other developers: > ** grub2: add unified kernel support > *** wip code at [https://github.com/osteffenrh/grub2/ > https://github.com/osteffenrh/grub2/] > ** installer(s): add support for discoverable partitions. > *** [https://bugzilla.redhat.com/show_bug.cgi?id=1075288 Bug#1075288] > > * Release engineering: [https://pagure.io/releng/issues #Releng issue number] > * Policies and guidelines: N/A (not needed for this Change) > * Trademark approval: N/A (not needed for this Change) > * Alignment with Objectives: > > > == Upgrade/compatibility impact == > > None (using unified kernel is opt-in for Phase 1). > > == How To Test == > Try on a existing (uefi) system: > * make sure you are running fedora 37 or rawhide. > * make sure your root filesystem has type "Linux root (x86-64)" (use > `fdisk -l` to check). > ** should that not be the case use the fdisk tag command ('t') to > change the partition type. > * when using btrfs: make sure the 'root' subvolume is set as default volume. > * `dnf copr enable kraxel/unified.kernel` > * `dnf update "grub2*"` > * `dnf install kernel-unified-virt` > * `reboot` > You should find two entries in the grub2 boot menu, one for classing > kernel with separate initrd and one for the unified kernel image. > Both should boot fine. > > The https://gitlab.com/kraxel/fedora-uki project has kickstart files > and helper scripts for generating virtual machine images. > * image using grub2-efi: > https://gitlab.com/kraxel/fedora-uki/-/raw/master/kickstart/fedora-uki-grub2.ks > * image using systemd-boot: > https://gitlab.com/kraxel/fedora-uki/-/raw/master/kickstart/fedora-uki-sdboot.ks > > Prebuilt virtual machine images are available from > https://www.kraxel.org/fedora-uki/. > > == User Experience == > > > == Dependencies == > > > == Contingency Plan == > * Contingency mechanism: > ** Probably none (unified kernel images are opt-in for Phase 1). > ** In case we tried switching the cloud images to unified kernels: > revert the kickstart config changes. > * Contingency deadline: > * Blocks release? No > > == Documentation == > > > == Release Notes == > > > > -- > Ben Cotton > He / Him / His > Fedora Program Manager > Red Hat > TZ=America/Indiana/Indianapolis > _______________________________________________ > 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 -- Iñaki Úcar _______________________________________________ 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
