Hi, On 12/5/23 14:38, Aoife Moloney wrote:
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 == Improve support for unified kernels in Fedora. == Owner == * Name: [[User:kraxel| Gerd Hoffmann]] * Email: kraxel@xxxxxxxxxx * Name: [[User:vittyvk| Vitaly Kuznetsov]] * Email: vkuznets@xxxxxxxxxx == Detailed Description == See [[ Changes/Unified_Kernel_Support_Phase_1 ]] for overview and Phase 1 goals. ==== Phase 2 goals ==== * Add support for booting UKIs directly. ** Boot path is shim.efi -> UKI, without any boot loader (grub, sd-boot) involved.
This is IMHO a mistake, the systemd-boot and UKI paths are the perfect time to break with shim and require some form of actual fedora/whatever secure boot key enrollment on the machine. Shim's fundamentally backdooring the UEFI security infrastructure, and frankly some of what is being done is pretty sketchy and its somewhat amazing it hasn't broken by vendors cleaning up their UEFI implementations*. Furthermore, the dependency on MS signing shim is also strongly in the pragmatic but not idea category as well.
Some of the stronger reasons for using shim (MOK's and 3rd party binary modules, ex nvidia) really shouldn't be considered a problem for UKI based machines as the hardware profiles need to be restricted enough that the whole UKI concept works at all. Put another way, there isn't really an answer to a generic boots everywhere UKI at the movement unless one is willing to create GB+ UKIs with every boot critical driver in existence, at which point its probably worth revisiting the entire initramfs boot method. For example, the current method of: load a compressed filesystem, decompress it, and then pick out the needed pieces, switch root then free the initramfs is very inferior to a "sealed volume" method that can mount and read the fs directly without all the overhead of loading/decompressing/freeing a huge blob of unused data. Furthermore, UKI are largely just a stopgap to solve the lack of a manifest like system that can validate the executable and shared libraries in the initramfs itself. Nevermind the piles and piles of configuration options that end up in the initrd for every obscure boot method (ex: where will the iscsi authentication information be placed, surely not the the kernel command line)
* I would expect that the UEFI hardening to continue to the point where shim's antics are no longer allowed now that people are continuing to look at the weaknesses in the current vendors UEFI boot paths.
Thanks,
** The UEFI boot configuration will get an entry for each kernel installed. ** Newly installed kernels are configured to be booted once (via BootNext). ** Successful boot of the system will make the kernel update permanent (update BootOrder). * Enable UKIs for aarch64. ** Should be just flipping the switch, dependencies such as kernel zboot support are merged. * Add a UEFI-only cloud image variant which uses UKIs. ** Also suitable for being used in confidential VMs. ** Cover both x86_64 and aarch64. ==== Related bugs ==== * shim: remove dependency on grub2-efi-x64 ([https://bugzilla.redhat.com/show_bug.cgi?id=2240989 buzilla 2240989]) * shim: handling of multiple lines in BOOT.CSV is inconsistent ([https://issues.redhat.com/browse/RHEL-10704 jira RHEL-10704], [https://github.com/rhboot/shim/issues/554 github 554]) * anaconda: add support for [https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/ discoverable partitions] ([https://bugzilla.redhat.com/show_bug.cgi?id=2160074 bugzilla 2160074], [https://bugzilla.redhat.com/show_bug.cgi?id=2178043 bugzilla 2178043]) * dracut: do not create yet another initramfs for UKIs ([https://github.com/dracutdevs/dracut/pull/2521 github PR 2521]) * kernel: enable UKIs on aarch64 ([https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2818 MR 2818]) == Feedback == == Benefit to Fedora == * Better secure boot support: the UKI initrd is covered by the signature. * Better support for tpm measurements and confidential computing. ** measurements are more useful if we know what hashes to expect for the initrd. ** measurements are more useful without grub.efi in the boot path (which measures each grub.cfg line processed). * More robust boot process ** generating the initrd on the installed system is fragile == Scope == * Proposal owners: ** updates for virt-firmware and uki-direct packages. ** enable UKIs on aarch64 ([https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2818 MR 2818]). ** prepare kickstart ([https://pagure.io/fedora-kickstarts.git Fedora kickstarts]) changes for generating UKI enabled images. * Other developers: ** installer/anaconda: implement discoverable partition support. ** bootloader/shim: fix bugs. ** Fedora Cloud SIG: Add UKI enabled images as an option to [https://fedoraproject.org/cloud/download Download Fedora Cloud] ** See also: [https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_2#Related_bugs Related Bugs] section. * 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, it's opt-in. Also the uefi cloud image is an additional image and will not replace the current bios/uefi hybrid image. == How To Test == ==== Switch an existing install to use UKIs. ==== Needs up-to-date Fedora 39 or Rawhide install in a virtual machine. Bare metal hardware with standard storage (ahci / nvme) should work too. Needs an big enough ESP to store UKI images there (minimum 200M, recommended 500M). 1. dnf install virt-firmware uki-direct * The uki-direct package contains the kernel-install plugin and systemd unit needed to automatically manage kernel updates. * You should have version 23.10 or newer. 2. sh /usr/share/doc/python3-virt-firmware/experimental/fixup-partitions-for-uki.sh * Workaround for [https://bugzilla.redhat.com/show_bug.cgi?id=2160074 bug 2160074] (anaconda not setting up [https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/ discoverable partitions]). * UKIs need this to find the root filesystem without root=... on the kernel command line. 3. dnf install kernel-uki-virt 4. kernel-bootcfg --show * optional step, shows UEFI boot configuration, the new UKI should be added as BootNext $ kernel-bootcfg --show # C - BootCurrent, N - BootNext, O - BootOrder # -------------------------------------------- # N - 0008 - 6.5.7-300.fc39.x86_64 <= entry for the the new kernel # C O - 0007 - 6.5.6-300.fc39.x86_64 <= currently running kernel # O - 0006 - Fedora <= grub2 entry # O - 0001 - UEFI QEMU QEMU HARDDISK [ ... ] 5. reboot 6. kernel-bootcfg --show * optional again, after successful boot the new kernel should be first in BootOrder. $ kernel-bootcfg --show # C - BootCurrent, N - BootNext, O - BootOrder # -------------------------------------------- # C O - 0008 - 6.5.7-300.fc39.x86_64 # O - 0007 - 6.5.6-300.fc39.x86_64 # O - 0006 - Fedora # O - 0001 - UEFI QEMU QEMU HARDDISK [ ... ] ==== Test UKI cloud images ==== Repo with kickstart files and scripts: https://gitlab.com/kraxel/fedora-uki Images for download: https://www.kraxel.org/fedora-uki/ * fedora-uki-cloud: uki-based cloud image, use cloud-init to configure this. * fedora-uki-direct: minimal uki-based image, root password is 'root'. * fedora-classic: minimal non-uki image, root password is 'root'. Known problems: * images can fail to boot on the first attempt ** should that happen reset the guest once, the second and all following boots will work fine. ** root cause is a shim bug ([https://github.com/rhboot/shim/issues/554 github 554]). ** known workaround: add a vTPM to the guest configuration. ==== Booting another kernel ==== From the booted system: * uefi-boot-menu --reboot From the firmware: If your UEFI firmware offers an boot menu you should be able to use that to select the kernel to boot. Unfortunately this is not standardized so there is no standard procedure to do so. * Virtual machines (OVMF): Enter the firmware setup by pressing ESC when you see the tianocore splash screen. Select "Boot Manager" in the toplevel menu. * Thinkpad laptops: Interupt normal boot (just 'Enter' on recent hardware, or using the special key on older models), then press F12 ("choose a temporary startup device"). == User Experience == == Dependencies == == Contingency Plan == * Contingency mechanism: ** drop kickstart file for the uefi-only cloud image. * Contingency deadline: N/A (not a System Wide Change) * Blocks release? No == Documentation == N/A (not a System Wide Change) == Release Notes ==
-- _______________________________________________ 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