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-sign... 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/sec... 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.