On Tue, Dec 20, 2022 at 1:18 PM Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > > Hi, > > On 12/20/22 17:28, Neal Gompa wrote: > > On Tue, Dec 20, 2022 at 10:22 AM 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 == > >> > > > > I think UKIs are fundamentally flawed and are an idea that came out of > > a group that doesn't really interact with real users enough to > > understand how much of a problem they actually are. I realize that > > this Change is only about VMs, but since it explicitly talks about it > > being "phase 1", the implication is that future Changes are coming to > > switch fully over. Consequently, I'm going to provide much more > > holistic feedback instead of just nitpicking on this case. > > > > In the Fedora case, things are simpler right up until we hit graphics > > drivers. This is also a problem for VMs too, because GPU passthrough > > is a common case for scientific and gaming workloads. > > In case of VMs there certainly is no need to load the GPU driver > from the initrd. > > > As long as the > > NVIDIA driver remains dominant in Linux, UKIs cannot work because by > > design you cannot load anything that isn't part of the kernel image. > > Actually since the NVIDIA binary driver couples the driver and userspace > versions together very tightly using the NVIDIA binary driver inside > the initrd is a bad idea. The rpmfusion pkgs deliberately do not do > this so that the kmods can be rebuild on an nvidia driver update for > all installed kernels without needing to then also regenerate all > initrds (which would be a bad thing to do since we might then cause > all initrds to break at the same time). > > > For bare metal, we *need* these drivers in early boot, though > > Actually I have been toying with the idea to just rely on efifb in > the initrd, at least for the cases where we have an efifb/simpledrm. > > When doing a 32 bit Debian install to test some kernel stuff on > quite old hw I noticed that Debian's install images let *grub* > bring up the video-output in vesa mode, with automatic resolution > selection. If we were to do this for legacy BIOS too then the kernel > could inherit that vesa mode with simpledrm and then we would have > legacy BIOS boot also covered with a "firmware framebuffer". > I think Fedora is the only major distro that doesn't do this, actually. Mageia and openSUSE do this too. They also use graphical GRUB by default instead of plain text GRUB. > Given the discussion about firmware sizes for GPUs in other threads, > I think this is something to seriously consider. Otherwise the size > of our initrds is going to become absolutely huge. > > Using firmware framebuffers inside the initrd could also significantly > speed up booting, since then the graphics card probing, which can be > quite slow when there are multiple external monitors, can be done in > parallel with booting the rest of the system instead of having plymouth > block on this. > I agree, though the driver handover process needs to work first. It doesn't solve the problem for storage and network drivers though. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
