Sorry for showing up here unannounced. This is a very strange claim. I'm not speaking in any official capacity but at least __personally__ being at the Linux Systems Group at MSFT I've never have encountered any hard requirement on grub. In any case, I want to point out a few things: * Some of the signing requirements as expressed here afaict: https://techcommunity.microsoft.com/t5/hardware-dev-center/updated-uefi-signing-requirements/ba-p/1062916 and it mentions: > If your submission is a SHIM (handing off execution to another > bootloader), then you must first submit to the SHIM review board and be > approved before a submission will be signed. [...]". I don't see any requirement that suggeste MSFT would require a specific boot loader. * MSFT recently published https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process and states > The default state of Secure Boot has a wide circle of trust which can result > in customers trusting boot components they may not need. Since the Microsoft > 3rd Party UEFI CA certificate signs the bootloaders for all Linux > distributions, trusting the Microsoft 3rd Party UEFI CA signature in the UEFI > database increases the attack surface of systems. A customer who intended to > only trust and boot a single Linux distribution will trust all distributions > – much more than their desired configuration. A vulnerability in any of the > bootloaders exposes the system and places the customer at risk of exploit for > a bootloader they never intended to use, as seen in recent vulnerabilities, > for example with the GRUB bootloader or firmware-level rootkit affecting boot > components. Secured-core PCs require Secure Boot to be enabled and configured > to distrust the Microsoft 3rd Party UEFI CA signature, by default, to provide > customers with the most secure configuration of their PCs possible. This explicitly mentions the security track record of GRUB as one of the reasons for making this - let's keep it civil and call it controversial - decision of disabling the 3rd part signing key in the BIOS. * The shim-review repo did approve a shim plus another boot loader for CISCO multiple times. For example, https://github.com/rhboot/shim-review/issues/212 > We have no plans to use GRUB2 as a second stage loader. Our intention is to > bundle the Linux Kernel, initramfs, and kernel command line into a single EFI > binary such that the PE/COFF signature protects all of those components. We > are using a small EFI stub, based on the systemd-boot stub, to do this and we > have augmented it to add support for a SBAT section. The "stubby" EFI shim: > https://github.com/puzzleos/stubby So just to be very clear their stubby boot loader is a standalone systemd-boot clone... In light of all this quotes like: https://github.com/rhboot/shim/issues/472#issuecomment-1118529154: > grub is the only 2nd stage loader that is allowed to be signed with the shim > MS trust chain, so it's a bit pointless. and https://github.com/rhboot/shim/issues/472#issuecomment-1118628769 > Regarding bootloader signing: grub is being signed, signing any additional > bootloader increases the attack surface, hence only grub will be signed (the > exception is that you can load a kernel directly; you can combine the kernel > with systemd-boot stub too, as the entire binary is signed - however, > systemd-boot stub is becoming increasingly complex (e.g. sysexts) and at some > point one might have to pull the plug on that too and use a fork of an older > version). > > Note that we only have talked about distributions that already ship grub > bootloader. We have not discussed signing alternative bootloaders for new > distributions without grub; however, at least systemd-boot and pxelinux are > barred from signing in general due to implementation quality concerns > fundamental disagreement about how secure boot works. > > e.g. if you sign systemd-boot or pxelinux with your key inside the shim, your > next shim review will be rejected Especially "systemd-boot stub is becoming increasingly complex" and "due to implementation quality concerns" is mind-blowlingly ironic and frankly disingenuous. _______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
