On Tue, Dec 20, 2022 at 01:56:57PM -0500, Chris Murphy wrote: > > > 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 parted/libparted already have support for handling GUIDs since their 3.5 release. I added pyparted support in https://github.com/dcantrell/pyparted/pull/95 and I've got work in progress for blivet support https://github.com/storaged-project/blivet/pull/1080 in theory that should merely then require anaconda to set a flag in blivet to automagicaly enable setting well known GUIDs. I've also got some changes to pykickstart to let the GUID be set in kickstart file part commands. > > 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. Yes, bare metal is certainly harder due to the much wider variance in boot hardware and also users tend todo much more complex thing. The focus on VMs was intentional to make the problem more tractable to solve. Even for VMs this proposal doesn't solve every use case. It is anticipated things will evolve incrementally over time to cover more use cases for both VMs & bare metal. The existing way of booting kernels+locally created initrds isn't going anywhere, so we're not loosing any features. > > * 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 As part of virtualization work with confidential VMs we are in active discussions/collaboration with people invovled in bootloaders from the Red Hat side. I'm not going to comment on likes/dislikes anyone might have historically. We're just looking to work positively find acceptable solutions to the goals for confidential VMs, ideally with little disruption for existing practices. > > * 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. Note, for cloud VM disk images, there's little reason to even have a /boot partition as a separate volume. We can size the ESP such that it is large enough for our needs in cloud kickstart files. For bare metal this would need to be considered though, since vendors can ship insufficiently large ESPs. THis is out of scope for anything in the near future, sine our focus is on VMs, especially cloud VMs. > > * 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. Pre-generated initrds solves the SecureBoot hole, but it does other things too. Most specifically it gives us predictable measurements of the boot components. We don't really want to seal secrets (LUKS key) to measurements that are variable across upgrades, and that means you have to reseal periodically. We do, however, want to be able to do attestation of a running system, and that is more scalable if we can have a more predictable set of measurements across every VM instance in the fleet. Locally generated initrds will always be impractical in this respect, unless you can guaranee the locally generated content will always be identical on every install. At that point though, there's little point in building it locally at all. > 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. Completely eliminating the need for an initrd is an interesting option. I'm not sure that would be a thing that can be delivered in a practical timeframe though, given its potential impact on the distro as a whole. UKIs have the benefit that they have near zero impact on anything that's done today. They're just enabling new use cases that aren't possible today. The main burden of course is the need to support them as a concept in parallel with existing local initrds. I think that burden is quite modest though, and offset by the use cases they unlock. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ 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
