CVE-2022-21894 VS shim

ESET described what BlackLotus does to exploit baton drop:

CVE-2022-21894 PoC: Secure Boot Security Feature Bypass Vulnerability https://github.com/Wack0/CVE-2022-21894

The write-up I saw suggests that revoking the Windows bootloader would cause existing install and restore images to fail to boot even with Secure Boot disabled because it checks its own signature, which would be pretty amazing if true: https://github.com/Wack0/CVE-2022-21894

Microsoft doesn't really sign other people's code for UEFI. They do sign shim (https://github.com/rhboot/shim) which will look at other keys the user registered with UEFI to load other components to enable you to write custom third party UEFI modules while still supporting secure boot.

In this case, the distros first boot loader is shim, which is signed by Microsoft. Shim is FOSS: https://github.com/rhboot/shim

How do I get dual boot set up and running? There doesn't seem so much documentation about this sbat chicanery as it was introduced to shim in 2021 and patched in rEFInd a bit more than a month ago, so I suppose not enough people have had this trouble yet.

Secure boot still isn't "secure" at all because microsoft has signed multiple bootloaders with their own keys, which exist only to chain load a second bootloader. See https://github.com/rhboot/shim and https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/

A new mechanism called SBAT (https://github.com/rhboot/shim/blob/main/SBAT.md) is now used to allow revocation of groups of bootloaders rather than individual hashes in order to mitigate the resource consumption

{ echo "sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md" echo "systemd-boot,1,systemd,systemd-boot,1,https://systemd.io" } > sbat.csv

Yeah, that incident instigated a totally new approach to revoking bad bootloaders that everybody (including Microsoft) should be using nowadays. So I guess HP just never got the memo.