bootkit-samples VS shim

Bootkit samples https://github.com/hardenedvault/bootkit-samples

https://github.com/hardenedvault/bootkit-samples

The short-term solution for workaround is to protect the OS runtime. Otherwise you'd have to build the defense-in-depth at very infrastructure level from scratch with hardware, firmware and OS with attestation service not only based on the "confidential computing" but typically TCG's trusted computing.

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.