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". 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. Regards, Hans > And that's another problem: no third-party early boot drivers. Even if you > solve the signing issue, you need to introduce some kind of two-stage > OS boot process so we can bring up the bare minimum to load a second > image containing all the remaining drivers. And at that point, you've > defeated the purpose of UKIs. I've heard from some people that system > extensions (sysexts) would be a way to solve this, and maybe it is. > But again, we've eliminated the value of UKIs by doing so. > > Speaking more broadly, there are also problems that will be introduced > as this trickles down from Fedora into prominent downstreams (assuming > this is accepted). In the RHEL case, you've basically broken driver > disks completely. In the UKI model, there's no way to incorporate > early boot storage, network, and graphics drivers. This is > *incredibly* common for RHEL administrators because there's a general > acceptance of proprietary kernel modules from vendors these days. Even > ignoring those, Red Hat's kernel feature support mindset is completely > incompatible with UKIs, because RHEL does default-off rather than > Fedora's default-on model for kernel features. We could debate until > the cows come home on whether it's right or wrong, but their current > mindset essentially means tons of common hardware becomes unsupported > quite regularly. The ELRepo project is popular among RHEL folks > because it restores those drivers and makes it possible to use RHEL on > those machines through a combination of driver disks and kernel module > packages. > > The crux of the problem here is *signing*. All of this is tied up in > Secure Boot and TPM, which is the wrong place to actually handle this. > In other operating systems (notably Windows), Secure Boot certificates > are not used for blocking or enabling kernel-level drivers. Instead, > there's a kernel-level certificate store that is used to validate and > enable drivers, allowing everything to be managed in a hardware > platform agnostic way. I've also yet to hear of a decent reason for > TPM measurements too. Block or filesystem verity provides similar > guarantees to provide tamper resistance and are both much easier to > debug than TPM interfaces. I am not convinced that you are providing > security or reliability with this and the trade-offs are *terrible* > for regular users. > > With my FESCo hat on, I'm uneasy about this change. With my "Fedora > user and advocate" hat on, I think that the UAPI group has failed to > provide something useful to the Linux world here and I would be > extremely apprehensive about Fedora adopting any portion of this > stuff. > > > > -- > 真実はいつも一つ！/ 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 _______________________________________________ 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
