Die Technik hinter Secure Boot (SB) zu durchschauen ist auf den ersten Blick nicht so einfach. Es ist mehr als nur ein "Im UEFI an/aus schalten". Daher hier eine kurze Zusammenfassung.
Generell: Alles ist eine große "chain of trust". Wenn ein Bootloder (BL), oder auch eine signierte firmware (FW) und im Extremfall ein Kernel und dessen Treiber nicht die korrekten Signaturen aufweisen, wird der Bootprozess abgebrochen (bzw die Treiber nicht geladen).
Dabei verwendet Secure Boot verschiedene Schlüssel und Signaturlisten
1) Der PK (Platform Key) wird von Hardware Hersteller in das System geschrieben. Dieser signiert die Schlüssel im...
2) ...KEK (Key Exchange Keys) Speicher. Hier liegen normalerweise zwei MS Schlüssel: "Microsoft UEFI CA 2011 Certificate" (damit signiert MS unter anderem die angesprochenen Bootloader,) und "Microsoft PA 2011 Certificate" (damit ist der Windows Bootloader signiert). Schlüssel im KEK können die DB und DBx modifizieren.
3) Die DB (Allow-List) und DBX (Deny-List) sind Listen von Hashes oder Zertifikaten. Die DB dient dazu, Hashes/Zertifikate von BL, FW, ... zuzulassen, die nicht durch die Schlüssel im KEK-Speicher signiert sind. Die DBX wiederum kann genutzt werden, durch KEK signierte BL, FW, ... auszusperren. Genau hier hat MS kürzlich zugeschlagen.
Um SB nun für OS neben Windows zu nutzen gibt es drei Optionen:
1) MS Schlüssel bleiben im UEFI, ein von MS signierter BL wie grub oder refind startet. Das hat den Nachteil, dass bei jedem Update dieser BL diese neu signiert werden müssen.
2) MS Schlüssel bleiben im UEFI, shim (auch signiert von MS) chain-loaded den nächsten BL. Vorteil ist, dass shim recht simpel ist und daher selten ein Signatur-Update braucht. Die nachgeschaltete BL können durch die OS Maintainer signiert werden (ohne MS) und die schlüssel in shim hinterlegt werden.
In beiden Fällen hängt man von dem Monopol von MS ab, da nur deren KEK es erlaubt, die DB (allow-list) und DBX (deny-list) nach belieben zu ändern. Genau das ist hier jetzt Anfang August passiert.
Unabhängig davon wird man nur, wenn man...
3) Eigene Schlüssel im UEFI platziert (PK und KEK) und seinen BL selbst mit dem KEK signiert.
Der größte Nachteil dieser Methode ist aber nun, dass unter anderem die Firmware einiger Hardware (z.B. nVidia GPUs) nicht mehr vertraut wird, da diese mit dem "Microsoft UEFI CA 2011 Certificate" signiert wurde (kann gerade bei Laptops zum "soft-brick" führen) und dass Windows nicht mehr bootet, da dessen Bootloader mit dem "Microsoft PA 2011 Certificate" signiert ist.
Man kann allerdings die Hashes entsprechender Hardware und des MS Bootloaders in die DB übernehmen. Diese herauszufinden ist recht schwierig und hat mich selber so einiges an Lebenszeit gekostet.
Alternativ kann man auch "Microsoft PA 2011 Certificate" (Windows BL) und "Microsoft UEFI CA 2011 Certificate" (MS signierte BL und Firmware) wieder in den KEK Speicher hinzufügen. Damit sind wir aber wieder bei dem Punkt, wo MS nach belieben DB und DBX editieren kann. Das ist aber eher unkritisch, wenn man seinen BL selber signiert. Das öffnet aber dennoch Tür und Tor für bösartige BL, die von MS signiert wurden (falls es denn solche gibt). Wer also paranoid ist und auf Windows verzichten kann, lässt beide Zertifikate außen vor.
In meinen Augen gibt es nur eine grundsätzlich zufriedenstellende Lösung: Es muss eine/mehrere Signining Authorität(en) (CA) her, die unabhängig von MS sind und von denen jeder (selbst MS) seine BL sowie Zertifikate signieren lassen muss.