On Tue, Dec 20, 2022 at 04:22:39PM +0000, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Dec 20, 2022 at 10:22:03AM -0500, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1 > > It's great to see this happening! > > > 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. > > With my FESCo hat on, I immediately have the following comment: > please narrow down the scope to things that we can actually approve > for F38. E.g. the parts related to replacing grub2 by sd-boot > are IMHO not realistic for F38 (*). And if we use grub2, then also the > pre-calculation of TPM PCR values is not realistic, since they are > too volatile with grub2... I think that those are all very interesting > research tangents, but the stuff that gets a stamp of approval as a > Fedora Change needs to be down-to-earth and users-know-what-to-expect > and you-can-pretty-much-figure-out-how-things-will-look-from-the-change-description. > > (*) Or if that is actually the plan, please specify *where* sd-boot > would be supported. The 'description' text there somewhat contradicts the 'Scope' section, which only mentions grub2, not sd-boot: Proposal owners: Update kernel build to create unified kernel sub-package. part one: PR#2179 part two: (wip) https://gitlab.com/kraxel/kernel-ark/-/commits/unified/ Other developers: grub2: add unified kernel support wip code at https://github.com/osteffenrh/grub2/ installer(s): add support for discoverable partitions. Bug#1075288 While use of sd-boot is desirable in many ways, it is not a pre-requisite for the use of UKIs. For that matter neither is the grub2 support. IMHO keeping sd-boot separate from this change though is better to avoid us getting diverted into a huge debate about bootloader choices for Fedora, as that's a huge topic in its own right. As noted there are some WIP patches for grub to allow it to load UKIs. This would let us address the major hole in grub where initrds are not signed for SecureBoot. As yuo mention, grub PCRs calculations are still complex / fragile. Without grub2 support for UKIs, and without sd-boot signed by Fedora, UKIs are still useful. shim can be configured to directly boot the UKI, at which point the PCR calculations are pretty easy [1]. For virtual machines with pre-built disk images, a boot loader can be considered redundant for common use, as with public cloud users rarely even see the bootloader phase of boot, let alone bother trying to interact with it. This is actually desirable for confidential VMs, as you don't want to be interacting with the guest over a virtual keyboard/console, as that's not a confidential channel. IOW, I think scope of this change should be UKIs as the mandatory deliverable, and grub2 support for UKIs as a nice-to-have, and anything about sd-boot strictly as a separate Change (whether f38 or F$later TBD) With regards, Daniel [1] I've got an experimental tool for doing PCR pre-calculations https://gitlab.com/berrange/tpm-prevision/ -- |: 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
