Re: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)
Gerd Hoffmann writes: ... >> I'm talking about removing shim from the boot flow. > > That is not a goal of this change proposal, and it's not up for debate > for phase #2. Maybe an option in a later phase, once we have a signed > systemd-boot (see below). Also, we have one more Fedora-specific problem: we can't create a new SB cert for signing UKIs so we're currently using the same cert as the traditional kernel. This works if you enroll the cert in DB but then these kernels are indistinguishable if you only look at PCR7, this complicates creating PCR policies a lot. The problem why we can't have a new SB certificate is not technical but organizational: currently, private parts of the certs are on physical cards which a few people have an issuing a new one is a real pain. Rumor has it this is going to change and I'd really like to have it included in 'phase #3'. In phase #2, we can probably add an option to 'uki-direct' to add UKIs without shim to Boot, this certainly won't be the default and will require Fedora cert to be enrolled into DB/MOK but for specific use-cases (e.g. AWS with provisioned varstore) this can be used. -- Vitaly -- ___ 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
Re: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)
Hi, > > > This is IMHO a mistake, the systemd-boot and UKI paths are the perfect > > > time > > > to break with shim and require some form of actual fedora/whatever secure > > > boot key enrollment on the machine. > > > > This is not going to fly. There are too many cases where you simply > > can't enroll fedora keys, so booting on machines with the MS 3rd party > > certificate enrolled IMHO must continue to work. > > I agree solving this for every possible machine combination is an > intractable problem at the moment. But, the UKI use case, as I understand > it, is a handful of hyperscalers and machines. Well, that is the main focus for now. At the end of the day I think using UKIs is good for all hardware. There are a number of roadblocks to be solved before they will actually work in more complex setups though. For the simple cases (no multiboot, ...) and standard storage (ahci/nvme) the virt UKI does also boot on physical hardware, I have a thinkpad running with it. But even when limiting things to the hyperscalers it doesn't work everywhere. On AWS you can bring your own uefi variable store, with whatever you want in 'db' etc. On Azure you can't. > I'm talking about removing shim from the boot flow. That is not a goal of this change proposal, and it's not up for debate for phase #2. Maybe an option in a later phase, once we have a signed systemd-boot (see below). > The UKI would be signed with the fedora key same as would be done with > shim in the boot path. The fedora public key is itself enrolled in the > UEFI key db alongside the assortment of existing db entries, and the > boot path would be UEFI->UKI. If the 'enroll fedora public key in db' part would be *that* simple shim would not exist in the first place. > > Problem #2 is we don't have a signed system-boot binary. Switching over > > to use systemd-boot when this has changed should be easy. The UKIs are > > already placed in $ESP/EFI/Linux, according to the boot loader spec, > > where systemd-boot would look for them. So the kernel-install workflow > > would need only minor changes. > > I'm not sure that is strictly needed. It'll be useful for multiple reasons, especially if you want make shim optional in the boot chain: (1) systemd-boot already supports secure boot key enrollment in case the machine is in setup mode. (2) It will remove the dependency on shim's fallback.efi (to create BDS entries for the UKIs on first boot). take care, Gerd -- ___ 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
Re: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)
Hi, On 12/18/23 06:41, Gerd Hoffmann wrote: On Fri, Dec 15, 2023 at 02:03:27PM -0600, Jeremy Linton wrote: Hi, Phase 2 goals * Add support for booting UKIs directly. ** Boot path is shim.efi -> UKI, without any boot loader (grub, sd-boot) involved. This is IMHO a mistake, the systemd-boot and UKI paths are the perfect time to break with shim and require some form of actual fedora/whatever secure boot key enrollment on the machine. This is not going to fly. There are too many cases where you simply can't enroll fedora keys, so booting on machines with the MS 3rd party certificate enrolled IMHO must continue to work. I agree solving this for every possible machine combination is an intractable problem at the moment. But, the UKI use case, as I understand it, is a handful of hyperscalers and machines. Those organizations either participate in this community or we have engineering contacts at who can assist with cleaning it up. And this isn't unheard of, poke around in a few machine's key database and you will find other distro's keys. I agree that depending on MS signing exclusively is a problem. I'd love to see fedora signing as an option. Given that EFI binaries can have multiple signatures we could have shim.efi signed by both microsoft and fedora. Which would allow to enroll the fedora keys instead of the microsoft keys (in case your platform offers that option) and everything works as it did before, except that the machine would only accept fedora-signed EFI binaries. Problem #1 is we don't have that in fedora today. Which btw is different from rhel/centos, where we actually have a second, distro-signed shim binary. Not as useful as one binary with two signatures, but better than nothing. I'm talking about removing shim from the boot flow. The UKI would be signed with the fedora key same as would be done with shim in the boot path. The fedora public key is itself enrolled in the UEFI key db alongside the assortment of existing db entries, and the boot path would be UEFI->UKI. Alternatively, better instructions for putting specific machines into UEFI setup mode can be provided, and something like the key enroller being used for fedora/libvirt/qemu today is used to replace the key infrastructure (PK/KEK/etc) on a given machine. The argument against this has always been that it breaks multiboot, but that is not applicable here. Frankly, none of this should be an issue for any machine that conforms to MS's requirements, as there is already a windows/everyone else boot switch to enable the keys needed to boot linux/shim vs the keys needed to boot modern windows versions. Problem #2 is we don't have a signed system-boot binary. Switching over to use systemd-boot when this has changed should be easy. The UKIs are already placed in $ESP/EFI/Linux, according to the boot loader spec, where systemd-boot would look for them. So the kernel-install workflow would need only minor changes. I'm not sure that is strictly needed. Your example boot flow shim->UKI depends on the BDS as the boot selector. If that boot flow works for the end user, there isn't a need the systemd-boot loader itself. It does solve various problems, like boot selection and command line editing, and a few other things, but isn't otherwise necessary. Of course it too, would be signed with the fedora keys rather than the MS ones, and maybe it should be built without the shim + LoadImage/StartImage hacks. Problem #3 is that apparently everything touching fedora secure boot signing takes ages to make any progress. One ticket I've looked at recently (IIRC the one to enable secure boot signing for aarch64) was roughly five years (!) old. So I'm not going to make my change proposals depend on any progress there. But I'll happily file a Phase #3 proposal once the problems outlined above are solved. Right, but little of it has been strictly technical. Other distro's have signed their aarch64 shim/boot path. That isn't to say there haven't been plenty of technical things needing attention, but those have been in the, "this should be cleaned up" category rather than "it doesn't work" category. But, your not really asking for more or less of the fedora infra with or without shim in the path. In both cases the UKI is signed with a fedora key. The difference is where the public key(s) gets enrolled. whole UKI concept works at all. Put another way, there isn't really an answer to a generic boots everywhere UKI at the movement unless one is willing to create GB+ UKIs with every boot critical driver in existence, Well, CoreOS actually does that. They don't use UKIs specifically, but they ship a generic initrd created on fedora infrastructure instead of generating an host-specific initrd on the installed machine (with only the drivers needed on the host included). Last time I looked it was ~80 MB in size. Well on x86, and a fair number of SystemReady SR
Re: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)
On Fri, Dec 15, 2023 at 02:03:27PM -0600, Jeremy Linton wrote: > Hi, > > > Phase 2 goals > > > > * Add support for booting UKIs directly. > > ** Boot path is shim.efi -> UKI, without any boot loader (grub, > > sd-boot) involved. > > This is IMHO a mistake, the systemd-boot and UKI paths are the perfect time > to break with shim and require some form of actual fedora/whatever secure > boot key enrollment on the machine. This is not going to fly. There are too many cases where you simply can't enroll fedora keys, so booting on machines with the MS 3rd party certificate enrolled IMHO must continue to work. I agree that depending on MS signing exclusively is a problem. I'd love to see fedora signing as an option. Given that EFI binaries can have multiple signatures we could have shim.efi signed by both microsoft and fedora. Which would allow to enroll the fedora keys instead of the microsoft keys (in case your platform offers that option) and everything works as it did before, except that the machine would only accept fedora-signed EFI binaries. Problem #1 is we don't have that in fedora today. Which btw is different from rhel/centos, where we actually have a second, distro-signed shim binary. Not as useful as one binary with two signatures, but better than nothing. Problem #2 is we don't have a signed system-boot binary. Switching over to use systemd-boot when this has changed should be easy. The UKIs are already placed in $ESP/EFI/Linux, according to the boot loader spec, where systemd-boot would look for them. So the kernel-install workflow would need only minor changes. Problem #3 is that apparently everything touching fedora secure boot signing takes ages to make any progress. One ticket I've looked at recently (IIRC the one to enable secure boot signing for aarch64) was roughly five years (!) old. So I'm not going to make my change proposals depend on any progress there. But I'll happily file a Phase #3 proposal once the problems outlined above are solved. > whole UKI concept works at all. Put another way, there isn't really an > answer to a generic boots everywhere UKI at the movement unless one is > willing to create GB+ UKIs with every boot critical driver in existence, Well, CoreOS actually does that. They don't use UKIs specifically, but they ship a generic initrd created on fedora infrastructure instead of generating an host-specific initrd on the installed machine (with only the drivers needed on the host included). Last time I looked it was ~80 MB in size. > at which point its probably worth revisiting the entire initramfs boot > method. That is *way* beyond the scope of this change proposal ... take care, Gerd -- ___ 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
Re: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)
Jeremy Linton wrote: > This is IMHO a mistake, the systemd-boot and UKI paths are the perfect > time to break with shim and require some form of actual fedora/whatever > secure boot key enrollment on the machine. Shim's fundamentally > backdooring the UEFI security infrastructure, and frankly some of what > is being done is pretty sketchy and its somewhat amazing it hasn't > broken by vendors cleaning up their UEFI implementations*. Furthermore, > the dependency on MS signing shim is also strongly in the pragmatic but > not idea category as well. How about we just use LogoFAIL to bypass Restricted Boot entirely without bothering with signatures at all? Kevin Kofler -- ___ 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
Re: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)
Hi, On 12/5/23 14:38, Aoife Moloney wrote: 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 == Improve support for unified kernels in Fedora. == Owner == * Name: [[User:kraxel| Gerd Hoffmann]] * Email: kra...@redhat.com * Name: [[User:vittyvk| Vitaly Kuznetsov]] * Email: vkuzn...@redhat.com == Detailed Description == See [[ Changes/Unified_Kernel_Support_Phase_1 ]] for overview and Phase 1 goals. Phase 2 goals * Add support for booting UKIs directly. ** Boot path is shim.efi -> UKI, without any boot loader (grub, sd-boot) involved. This is IMHO a mistake, the systemd-boot and UKI paths are the perfect time to break with shim and require some form of actual fedora/whatever secure boot key enrollment on the machine. Shim's fundamentally backdooring the UEFI security infrastructure, and frankly some of what is being done is pretty sketchy and its somewhat amazing it hasn't broken by vendors cleaning up their UEFI implementations*. Furthermore, the dependency on MS signing shim is also strongly in the pragmatic but not idea category as well. Some of the stronger reasons for using shim (MOK's and 3rd party binary modules, ex nvidia) really shouldn't be considered a problem for UKI based machines as the hardware profiles need to be restricted enough that the whole UKI concept works at all. Put another way, there isn't really an answer to a generic boots everywhere UKI at the movement unless one is willing to create GB+ UKIs with every boot critical driver in existence, at which point its probably worth revisiting the entire initramfs boot method. For example, the current method of: load a compressed filesystem, decompress it, and then pick out the needed pieces, switch root then free the initramfs is very inferior to a "sealed volume" method that can mount and read the fs directly without all the overhead of loading/decompressing/freeing a huge blob of unused data. Furthermore, UKI are largely just a stopgap to solve the lack of a manifest like system that can validate the executable and shared libraries in the initramfs itself. Nevermind the piles and piles of configuration options that end up in the initrd for every obscure boot method (ex: where will the iscsi authentication information be placed, surely not the the kernel command line) * I would expect that the UEFI hardening to continue to the point where shim's antics are no longer allowed now that people are continuing to look at the weaknesses in the current vendors UEFI boot paths. Thanks, ** The UEFI boot configuration will get an entry for each kernel installed. ** Newly installed kernels are configured to be booted once (via BootNext). ** Successful boot of the system will make the kernel update permanent (update BootOrder). * Enable UKIs for aarch64. ** Should be just flipping the switch, dependencies such as kernel zboot support are merged. * Add a UEFI-only cloud image variant which uses UKIs. ** Also suitable for being used in confidential VMs. ** Cover both x86_64 and aarch64. Related bugs * shim: remove dependency on grub2-efi-x64 ([https://bugzilla.redhat.com/show_bug.cgi?id=2240989 buzilla 2240989]) * shim: handling of multiple lines in BOOT.CSV is inconsistent ([https://issues.redhat.com/browse/RHEL-10704 jira RHEL-10704], [https://github.com/rhboot/shim/issues/554 github 554]) * anaconda: add support for [https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/ discoverable partitions] ([https://bugzilla.redhat.com/show_bug.cgi?id=2160074 bugzilla 2160074], [https://bugzilla.redhat.com/show_bug.cgi?id=2178043 bugzilla 2178043]) * dracut: do not create yet another initramfs for UKIs ([https://github.com/dracutdevs/dracut/pull/2521 github PR 2521]) * kernel: enable UKIs on aarch64 ([https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2818 MR 2818]) == Feedback == == Benefit to Fedora == * Better secure boot support: the UKI initrd is covered by the signature. * Better support for tpm measurements and confidential computing. ** measurements are more useful if we know what hashes to expect for the initrd. ** measurements are more useful without grub.efi in the boot path (which measures each grub.cfg line processed). * More robust boot process ** generating the initrd on the installed system is fragile == Scope == * Proposal owners: ** updates for virt-firmware and uki-direct packages. ** enable UKIs on aarch64 ([https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2818 MR 2818]). ** prepare kickstart ([https://pagure.io/fedora-kickstarts.git Fedora kickstarts]) changes for generating UKI enabled images. * Other developers: ** installer/anaconda: implement discoverable partition support. ** bootloader/shim: fix bugs. ** Fedora
Re: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)
Hi, On 12/6/23 11:26, Vitaly Kuznetsov wrote: Gerd Hoffmann writes: Hi, Does that mean that the Linux EFI boot code knows how to call back to shim to get the certificates instead of reading the firmware directly? No. The linux efi stub doesn't need that. shim.efi does: (a) Set efi variables, where the linux kernel can read the certificates from. This works the same way for both traditional kernels and UKIs. (b) provide an efi protocol for bootloaders, which can be called by grub and systemd-boot to verify the signature for binaries they load (typically the linux kernel, but could also be fwupd.efi). Note, the protocol is also used by systemd-stub (the base for UKIs) to verify cmdline addons, see commit 05c9f9c2517c54b98d55f08f8afa67c79be861e8 Author: Luca Boccassi Date: Fri May 12 00:55:58 2023 +0100 stub: allow loading and verifying cmdline addons this AFAIU means that we also need shim in the boot chain if we want to support these addons. That is true, buts its also false. The LoadImage protocol is more than capable of doing exactly what that patch does (AFAIK), and using strictly the UEFI protocols for validation. Of course if you want to backdoor the process then you need to add shim into it, which is part of what that patch is doing. -- ___ 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
Re: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)
> Gerd Hoffmann this AFAIU means that we also need shim in the boot chain if we want to > support these addons. Only if you want to use certs in MOK to verify them, otherwise it's not necessary. The protocol is just LoadImage which every firmware also provides and checks against DB. -- ___ 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
Re: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)
Gerd Hoffmann writes: > Hi, > >> Does that mean that the Linux EFI boot code knows how to call back to >> shim to get the certificates instead of reading the firmware directly? > > No. The linux efi stub doesn't need that. > > shim.efi does: > > (a) Set efi variables, where the linux kernel can read the > certificates from. This works the same way for both traditional > kernels and UKIs. > > (b) provide an efi protocol for bootloaders, which can be called by grub > and systemd-boot to verify the signature for binaries they load > (typically the linux kernel, but could also be fwupd.efi). Note, the protocol is also used by systemd-stub (the base for UKIs) to verify cmdline addons, see commit 05c9f9c2517c54b98d55f08f8afa67c79be861e8 Author: Luca Boccassi Date: Fri May 12 00:55:58 2023 +0100 stub: allow loading and verifying cmdline addons this AFAIU means that we also need shim in the boot chain if we want to support these addons. -- Vitaly -- ___ 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
Re: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)
Hi, > Does that mean that the Linux EFI boot code knows how to call back to > shim to get the certificates instead of reading the firmware directly? No. The linux efi stub doesn't need that. shim.efi does: (a) Set efi variables, where the linux kernel can read the certificates from. This works the same way for both traditional kernels and UKIs. (b) provide an efi protocol for bootloaders, which can be called by grub and systemd-boot to verify the signature for binaries they load (typically the linux kernel, but could also be fwupd.efi). take care, Gerd -- ___ 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
Re: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)
On Wed, Dec 6, 2023 at 5:15 AM Gerd Hoffmann wrote: > > Hi, > > > What is the point of using shim in this path? We're not having UKIs > > signed by Microsoft, and unless the Linux kernel knows how to call > > shim for certificates, I don't see how this is supposed to be useful > > for the Microsoft->Fedora->OS boot chain. > > Booting without shim.efi would work only if you enroll the fedora secure > boot CA in your firmware's security database. That is not the default, > and not all virtualization environments offer the option to do that. > > So, on a typical setup with the microsoft keys enrolled the firmware > wouldn't load the UKI, exactly because it is not signed by microsoft. > shim.efi is needed for everything signed with the fedora keys, be it > grub.efi, fwupd.efi, traditional kernels or UKIs. > > Also note that fallback.efi (comes with shim and runs in case there is > no UEFI boot configuration) will create only uefi boot entries including > shim in the boot path, so there is no easy way to exclude shim. > > Ideally we would have shim.efi signed with both microsoft and fedora > keys. In that case the firmware -> shim.efi -> fedora-signed.efi boot > path would work in both cases (fedora keys / microsoft keys enrolled). > Does that mean that the Linux EFI boot code knows how to call back to shim to get the certificates instead of reading the firmware directly? Because without that, shim is kind of pointless. Shim returns the certificates from firmware plus the embedded distribution one (Fedora's in this case) when it's asked for them. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ 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
Re: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)
Hi, > What is the point of using shim in this path? We're not having UKIs > signed by Microsoft, and unless the Linux kernel knows how to call > shim for certificates, I don't see how this is supposed to be useful > for the Microsoft->Fedora->OS boot chain. Booting without shim.efi would work only if you enroll the fedora secure boot CA in your firmware's security database. That is not the default, and not all virtualization environments offer the option to do that. So, on a typical setup with the microsoft keys enrolled the firmware wouldn't load the UKI, exactly because it is not signed by microsoft. shim.efi is needed for everything signed with the fedora keys, be it grub.efi, fwupd.efi, traditional kernels or UKIs. Also note that fallback.efi (comes with shim and runs in case there is no UEFI boot configuration) will create only uefi boot entries including shim in the boot path, so there is no easy way to exclude shim. Ideally we would have shim.efi signed with both microsoft and fedora keys. In that case the firmware -> shim.efi -> fedora-signed.efi boot path would work in both cases (fedora keys / microsoft keys enrolled). take care, Gerd -- ___ 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
Re: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)
On Tue, Dec 05, 2023 at 03:01:04PM -0600, Chris Adams wrote: > Once upon a time, Aoife Moloney said: > > * UKIs need this to find the root filesystem without root=... on the > > kernel command line. > > How does this work in system with more than one Linux install? Or any > more-complicated disk setup (e.g. SW RAID)? Does this also lock users > out from ALL kernel command-line options? Using UKIs is optional, if they don't work for your use case just continue using traditional kernels. Our main focus is virtualization use cases and cloud images, where you usually have a simple disk setup. Independent from that work is being done (mostly in systemd) to allow configure the command line for UKIs in a secure way. New in systemd v254 are addon images which can extend the command line. See "man systemd-stub" for details. take care, Gerd -- ___ 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
Re: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)
On Tue, Dec 05, 2023 at 04:14:00PM -0500, Neal Gompa wrote: > On Tue, Dec 5, 2023 at 3:47 PM Aoife Moloney wrote: > > > > 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 == > > Improve support for unified kernels in Fedora. > > > > == Owner == > > * Name: [[User:kraxel| Gerd Hoffmann]] > > * Email: kra...@redhat.com > > > > * Name: [[User:vittyvk| Vitaly Kuznetsov]] > > * Email: vkuzn...@redhat.com > > > > > > == Detailed Description == > > See [[ Changes/Unified_Kernel_Support_Phase_1 ]] for overview and Phase 1 > > goals. > > > > Phase 2 goals > > > > * Add support for booting UKIs directly. > > ** Boot path is shim.efi -> UKI, without any boot loader (grub, > > sd-boot) involved. > > ** The UEFI boot configuration will get an entry for each kernel installed. > > ** Newly installed kernels are configured to be booted once (via BootNext). > > ** Successful boot of the system will make the kernel update permanent > > (update BootOrder). > > * Enable UKIs for aarch64. > > ** Should be just flipping the switch, dependencies such as kernel > > zboot support are merged. > > * Add a UEFI-only cloud image variant which uses UKIs. > > ** Also suitable for being used in confidential VMs. > > ** Cover both x86_64 and aarch64. > > > > What is the point of using shim in this path? We're not having UKIs > signed by Microsoft, and unless the Linux kernel knows how to call > shim for certificates, I don't see how this is supposed to be useful > for the Microsoft->Fedora->OS boot chain. The VM UEFI firmware almost always only has the Microsoft certs installed. Thus the only thing it can boot is shim, which is signed by Microsoft. The boot configuration tells shim to boot the desired UKI, signed by Fedora, instead of its compiled default of booting grub. The only way you could do away with shim is to install the Fedora certs in UEFI directly, which isn't something most public clouds or other VM mgmt tools support well (if at all). 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@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
Re: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)
On Tue, Dec 5, 2023 at 3:47 PM Aoife Moloney wrote: > > 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 == > Improve support for unified kernels in Fedora. > > == Owner == > * Name: [[User:kraxel| Gerd Hoffmann]] > * Email: kra...@redhat.com > > * Name: [[User:vittyvk| Vitaly Kuznetsov]] > * Email: vkuzn...@redhat.com > > > == Detailed Description == > See [[ Changes/Unified_Kernel_Support_Phase_1 ]] for overview and Phase 1 > goals. > > Phase 2 goals > > * Add support for booting UKIs directly. > ** Boot path is shim.efi -> UKI, without any boot loader (grub, > sd-boot) involved. > ** The UEFI boot configuration will get an entry for each kernel installed. > ** Newly installed kernels are configured to be booted once (via BootNext). > ** Successful boot of the system will make the kernel update permanent > (update BootOrder). > * Enable UKIs for aarch64. > ** Should be just flipping the switch, dependencies such as kernel > zboot support are merged. > * Add a UEFI-only cloud image variant which uses UKIs. > ** Also suitable for being used in confidential VMs. > ** Cover both x86_64 and aarch64. > What is the point of using shim in this path? We're not having UKIs signed by Microsoft, and unless the Linux kernel knows how to call shim for certificates, I don't see how this is supposed to be useful for the Microsoft->Fedora->OS boot chain. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ 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
Re: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)
Once upon a time, Aoife Moloney said: > * UKIs need this to find the root filesystem without root=... on the > kernel command line. How does this work in system with more than one Linux install? Or any more-complicated disk setup (e.g. SW RAID)? Does this also lock users out from ALL kernel command-line options? -- Chris Adams -- ___ 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
F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)
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 == Improve support for unified kernels in Fedora. == Owner == * Name: [[User:kraxel| Gerd Hoffmann]] * Email: kra...@redhat.com * Name: [[User:vittyvk| Vitaly Kuznetsov]] * Email: vkuzn...@redhat.com == Detailed Description == See [[ Changes/Unified_Kernel_Support_Phase_1 ]] for overview and Phase 1 goals. Phase 2 goals * Add support for booting UKIs directly. ** Boot path is shim.efi -> UKI, without any boot loader (grub, sd-boot) involved. ** The UEFI boot configuration will get an entry for each kernel installed. ** Newly installed kernels are configured to be booted once (via BootNext). ** Successful boot of the system will make the kernel update permanent (update BootOrder). * Enable UKIs for aarch64. ** Should be just flipping the switch, dependencies such as kernel zboot support are merged. * Add a UEFI-only cloud image variant which uses UKIs. ** Also suitable for being used in confidential VMs. ** Cover both x86_64 and aarch64. Related bugs * shim: remove dependency on grub2-efi-x64 ([https://bugzilla.redhat.com/show_bug.cgi?id=2240989 buzilla 2240989]) * shim: handling of multiple lines in BOOT.CSV is inconsistent ([https://issues.redhat.com/browse/RHEL-10704 jira RHEL-10704], [https://github.com/rhboot/shim/issues/554 github 554]) * anaconda: add support for [https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/ discoverable partitions] ([https://bugzilla.redhat.com/show_bug.cgi?id=2160074 bugzilla 2160074], [https://bugzilla.redhat.com/show_bug.cgi?id=2178043 bugzilla 2178043]) * dracut: do not create yet another initramfs for UKIs ([https://github.com/dracutdevs/dracut/pull/2521 github PR 2521]) * kernel: enable UKIs on aarch64 ([https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2818 MR 2818]) == Feedback == == Benefit to Fedora == * Better secure boot support: the UKI initrd is covered by the signature. * Better support for tpm measurements and confidential computing. ** measurements are more useful if we know what hashes to expect for the initrd. ** measurements are more useful without grub.efi in the boot path (which measures each grub.cfg line processed). * More robust boot process ** generating the initrd on the installed system is fragile == Scope == * Proposal owners: ** updates for virt-firmware and uki-direct packages. ** enable UKIs on aarch64 ([https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2818 MR 2818]). ** prepare kickstart ([https://pagure.io/fedora-kickstarts.git Fedora kickstarts]) changes for generating UKI enabled images. * Other developers: ** installer/anaconda: implement discoverable partition support. ** bootloader/shim: fix bugs. ** Fedora Cloud SIG: Add UKI enabled images as an option to [https://fedoraproject.org/cloud/download Download Fedora Cloud] ** See also: [https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_2#Related_bugs Related Bugs] section. * 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, it's opt-in. Also the uefi cloud image is an additional image and will not replace the current bios/uefi hybrid image. == How To Test == Switch an existing install to use UKIs. Needs up-to-date Fedora 39 or Rawhide install in a virtual machine. Bare metal hardware with standard storage (ahci / nvme) should work too. Needs an big enough ESP to store UKI images there (minimum 200M, recommended 500M). 1. dnf install virt-firmware uki-direct * The uki-direct package contains the kernel-install plugin and systemd unit needed to automatically manage kernel updates. * You should have version 23.10 or newer. 2. sh /usr/share/doc/python3-virt-firmware/experimental/fixup-partitions-for-uki.sh * Workaround for [https://bugzilla.redhat.com/show_bug.cgi?id=2160074 bug 2160074] (anaconda not setting up [https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/ discoverable partitions]). * UKIs need this to find the root filesystem without root=... on the kernel command line. 3. dnf install kernel-uki-virt 4. kernel-bootcfg --show * optional step, shows UEFI boot configuration, the new UKI should be added as BootNext $ kernel-bootcfg --show # C - BootCurrent, N - BootNext, O - BootOrder # # N- 0008 - 6.5.7-300.fc39.x86_64<= entry for the the new kernel # C O - 0007 - 6.5.6-300.fc39.x86_64<= currently running kernel # O - 0006 - Fedora <= grub2 entry # O -
F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)
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 == Improve support for unified kernels in Fedora. == Owner == * Name: [[User:kraxel| Gerd Hoffmann]] * Email: kra...@redhat.com * Name: [[User:vittyvk| Vitaly Kuznetsov]] * Email: vkuzn...@redhat.com == Detailed Description == See [[ Changes/Unified_Kernel_Support_Phase_1 ]] for overview and Phase 1 goals. Phase 2 goals * Add support for booting UKIs directly. ** Boot path is shim.efi -> UKI, without any boot loader (grub, sd-boot) involved. ** The UEFI boot configuration will get an entry for each kernel installed. ** Newly installed kernels are configured to be booted once (via BootNext). ** Successful boot of the system will make the kernel update permanent (update BootOrder). * Enable UKIs for aarch64. ** Should be just flipping the switch, dependencies such as kernel zboot support are merged. * Add a UEFI-only cloud image variant which uses UKIs. ** Also suitable for being used in confidential VMs. ** Cover both x86_64 and aarch64. Related bugs * shim: remove dependency on grub2-efi-x64 ([https://bugzilla.redhat.com/show_bug.cgi?id=2240989 buzilla 2240989]) * shim: handling of multiple lines in BOOT.CSV is inconsistent ([https://issues.redhat.com/browse/RHEL-10704 jira RHEL-10704], [https://github.com/rhboot/shim/issues/554 github 554]) * anaconda: add support for [https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/ discoverable partitions] ([https://bugzilla.redhat.com/show_bug.cgi?id=2160074 bugzilla 2160074], [https://bugzilla.redhat.com/show_bug.cgi?id=2178043 bugzilla 2178043]) * dracut: do not create yet another initramfs for UKIs ([https://github.com/dracutdevs/dracut/pull/2521 github PR 2521]) * kernel: enable UKIs on aarch64 ([https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2818 MR 2818]) == Feedback == == Benefit to Fedora == * Better secure boot support: the UKI initrd is covered by the signature. * Better support for tpm measurements and confidential computing. ** measurements are more useful if we know what hashes to expect for the initrd. ** measurements are more useful without grub.efi in the boot path (which measures each grub.cfg line processed). * More robust boot process ** generating the initrd on the installed system is fragile == Scope == * Proposal owners: ** updates for virt-firmware and uki-direct packages. ** enable UKIs on aarch64 ([https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2818 MR 2818]). ** prepare kickstart ([https://pagure.io/fedora-kickstarts.git Fedora kickstarts]) changes for generating UKI enabled images. * Other developers: ** installer/anaconda: implement discoverable partition support. ** bootloader/shim: fix bugs. ** Fedora Cloud SIG: Add UKI enabled images as an option to [https://fedoraproject.org/cloud/download Download Fedora Cloud] ** See also: [https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_2#Related_bugs Related Bugs] section. * 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, it's opt-in. Also the uefi cloud image is an additional image and will not replace the current bios/uefi hybrid image. == How To Test == Switch an existing install to use UKIs. Needs up-to-date Fedora 39 or Rawhide install in a virtual machine. Bare metal hardware with standard storage (ahci / nvme) should work too. Needs an big enough ESP to store UKI images there (minimum 200M, recommended 500M). 1. dnf install virt-firmware uki-direct * The uki-direct package contains the kernel-install plugin and systemd unit needed to automatically manage kernel updates. * You should have version 23.10 or newer. 2. sh /usr/share/doc/python3-virt-firmware/experimental/fixup-partitions-for-uki.sh * Workaround for [https://bugzilla.redhat.com/show_bug.cgi?id=2160074 bug 2160074] (anaconda not setting up [https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/ discoverable partitions]). * UKIs need this to find the root filesystem without root=... on the kernel command line. 3. dnf install kernel-uki-virt 4. kernel-bootcfg --show * optional step, shows UEFI boot configuration, the new UKI should be added as BootNext $ kernel-bootcfg --show # C - BootCurrent, N - BootNext, O - BootOrder # # N- 0008 - 6.5.7-300.fc39.x86_64<= entry for the the new kernel # C O - 0007 - 6.5.6-300.fc39.x86_64<= currently running kernel # O - 0006 - Fedora <= grub2 entry # O -
