On Tue, Dec 20, 2022, at 10:22 AM, Ben Cotton wrote:
> == 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. Discoverable partitions is the first barrier in the proposal. I agree with everything up to this point. I like discoverable partitions specification, the gotcha is there is the significant amount of inertia still against trusting GPT partition type GUIDs. They tend to be entirely ignored in Linux. Yes systemd honors them, but the installer is pretty weak in its understanding of them, and by extention parted/libparted lacks support for (a) the entire discoverable partitions spec's listing of type GUIDs (b) arbitrary GUIDs. So I think the first big barrier to entry is answering the questions: * Enhance parted/libparted to support arbitrary GUIDs and enhance blivet to understand the full listing of GUIDs? Or * Enhance parted/libparted to support full listing of GUIDs? Or * switch anaconda/blivet to using fdisk/libfdisk? It already supports pretty much all GPT partition type GUIDs and receives regular updates with additions; I'm not sure if it supports arbitrary GUIDs, the CLI tool seems not to support it but maybe fdisk does. > 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. I like the focus on VM's so long as it drives us forward incrementally in a way we can then converge baremetal back toward rather than fragmenting. I'm skeptical this is going to be easy to do on baremetal... more in a bit. > * 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. Great. Just be aware the bootloader team is somewhere between disinterested in Boot Loader Specification, and hostile to it. They support the BLS snippet file format. Beyond that, there is defiance of the specification as an actual bonefide spec that Fedora does or even should support. And because of that you can expect breakage. For example: https://bugzilla.redhat.com/show_bug.cgi?id=2120845 For that matter, grubby likewise steps on *all* BLS snippets found in /boot/loader/entries when using the --update=ALL flag, not just the BLS snippets > ** When using btrfs: configure 'root' subvolume as default volume. The installer understands `btrfs subvolume set-default` so it could set the "root" subvolume. The difficulty I've always had with this, it's that it's not discoverable. There's no way someone not already familiar with the concept of changing the default subvolume would ever figure this out on their own, and I'm a big fan of the boot process being verbose and explicit. Anytime there's silent leaps of faith, it's harder to trouble shoot, and harder still for mortal users to understand how their system functions. But maybe this can be mitigated by e.g. the kernel's btrfs driver announcing the subvolume/subvolume ID it's mounting when it's not explicit (i.e. when it's honoring a subvolume other than ID 5, set as the default subvolume) Previously I've mentioned expanding the discoverable partitions conceptually, a sort of "discoverable subvolumes spec" so that Btrfs and OSTree and LVM could benefit from discoverability via a naming convention that a new systemd generator could parse and take action on. LVM and OSTree don't have an approximate equivalent of btrfs default subvolumes, so they are in need of a solution to find the proper root without it being explicit. If we're going to accept that specifying root trees must be explicit for LVM and OSTree, then I think we might as well leave things be for Btrfs and explicitly list the root tree there too. > * Add proper systemd-boot support to installers. Great. The gotcha though is this in effect requires a change in the file system currently mounted at /boot, which is ext4. And ext4 isn't supported by sd-boot or UEFI firmware. So if you're going to support sd-boot, the installer needs to be aware that either the ESP is big enough to be used as /boot, or if it's not big enough then it will be mounted on /efi *and* a new partition XBOOTLDR formatted as FAT will be used as /boot. This is not a major consideration for this feature proposal, but the sooner some of these decisions are made the easier it's going to be by not having to unwind mistakes down the road: For the purposes of a VM, it's a single OS setup so it makes sense to go with the simplest option which is an ESP on /boot that serves the purposes of both ESP and "boot" (bootloader, bootloader configuration, and kernels all on one volume). However... There is the still common and supported baremetal dual-boot scenario were the ESP will be too small, so we'll need ESP on /efi, and XBOOTLDR on /boot. While we could support both EFI only and EFI+XTBOOTLDR layouts for the different use cases, I'd encourage just supporting one size fits all: EFI+XTBOOTLDR. It's more compatible (dual boot), and more like what we have today. > * Better secure boot support (specifically the initrd is covered by > the signature). We need to solve the glaring hole that is the initrd. There's no question about it. I can't really assess if this feature is the best way to do that. Or if it would be adequate for dracut to self-sign every locally generated initrd with a unique key pair and throw away the private key after each initrd is generated. Or if we could do enough strict standardization in the boot chain with a possibly larger kernel to avoid needing an initrd, i.e. get to sysroot mount faster thereby obviating the need for a large initrd. The problem with a large initrd anyway is that we have to load the whole thing in memory and unpack it. And this will increase boot times. For whatever reason, the bootloaders don't support particularly fast reading off modern storage. Maybe it's a pre-boot environment limitation, not a bootloader limitation, I'm not sure. -- Chris Murphy _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
