Secure Boot allowing only one signature on a binary creates a major mess.
1) Users wishing to run in a Secure Boot environment will have to trust Microsoft in order to boot official Fedora. The Secure Boot signing format currently allows only one signature on a binary -- so Fedora's shim bootloader can be signed only by the Microsoft-vouched key. If a user removes Microsoft's key, official Fedora will no longer boot, as long as Secure Boot is on.
Note: Unspecific to Fedora and also applicable to other Linux distributions.
1) Machines sold as "Ubuntu Certified," preinstalled with Ubuntu, will have an Ubuntu-specific key, generated by Canonical, in their firmware.
But that does not help Ubuntu much because Ubuntu cannot sign its bootloader (shim) with both keys, the Microsoft key and their Ubuntu key. Therefore, quote:
2) Ubuntu CDs, distributed separately from hardware, will also depend on the presence of Microsoft's key in the machine's firmware to boot, when Secure Boot is active.
And also the security gain is negligible because Microsoft's key also must be installed.
1) Machines sold as "Ubuntu Certified," preinstalled with Ubuntu, will have an Ubuntu-specific key, generated by Canonical, in their firmware. Additionally, they will be required by the certification guidelines to have the Microsoft key installed.
The decision to either trust Microsoft or Ubuntu is a big one. But in rather rare cases it will make sense for users to trust both keys at the same key (except in dual-boot scenarios).
It is also a bit of security theater.
the boot loader must not execute any unsigned code in a firmware context, that is, before ExitBootServices is called just before jumping into the kernel.
Then also nowadays the inital ramdisk used by most (if not all) Linux desktop distributions contains unsigned code.
Microsoft is dictating policy for the Linux boot process.
Due to the complexity of the Linux boot process, the number of active releases from different distributions with compatibility challenges, and the support and serviceability timelines of in-market products, a limited exception to the NX signing requirements has been granted.
This limited exception is granted for shims serving in-market products. This exception will be reviewed regularly, and once component versions are identified that meet the compatibility requirements, new shim signing requests for products targeting the identified components will no longer be exempt. Additionally, when shim functionality is developed to provide compatibility for older, non-compliant boot components, new shim signings will no longer be exempt.
Please reach out to: email@example.com with any questions on this policy.
Related shim ticket linking to the same source Is 15.8 being prepared?.
shim review board
shim HTTP boot
HTTP boot is part of the UEFI specification.
shim can be started from a UEFI boot entry. 
Where is that UEFI boot entry stored? Inside
efivars (a (U)EFI variable filesystem).
efivars stored? Inside the
NVRAM. What is the
NVRAM? Imagine it being similar to a hard drive but not really a separate hard drive. It's a writable storage area on the motherboard, part of the firmware.
The vulnerability can also be exploited locally by an attacker with enough privileges to manipulate data in the EFI Variables or on the EFI partition. This can be accomplished with a live Linux USB stick. The boot order can then be changed such that a remote and vulnerable shim is loaded on the system. This shim is then used to execute privileged code from the same remote server, all without ever disabling Secure Boot.
- shim bug report / feature request: remove shim HTTP boot due to security issues / split shim into
- shim documentation pull request mention HTTP boot support in readme
no THE shim