Linux og Secure Boot. En fejl, som vi ikke kan gentage

I tidligere artikel Jeg huskede en præcedens for Microsofts krav om at kræve, at TPM version 2-modulet kunne bruge Windows 11. Jeg refererer til kravet om, at computere med Windows 8 forudinstalleret bruger UEFI i stedet for BIOS til bootloaderen, og at modulet Secure Boot var forudinstalleret.  Nu vil jeg tale om den efter min mening forkerte måde, hvorpå Linux håndterede problemet.

Linux og Secure Boot

Secure Boot kræver, at hvert program, der startes, har en signatur, der garanterer dets ægthed gemt i databasen over bundkortets ikke-flygtige hukommelse. Der er to måder at vises på i denne database. Uanset om det er inkluderet af producenten eller inkluderet af Microsoft.

Løsningen nået ved nogle Linux -distributioner med Microsoft var, at dette firma accepterede signaturen af ​​en binær, der skulle stå for lanceringen af ​​boot loader for hver distribution. Disse binære filer blev gjort tilgængelige for samfundet.

Efterfølgende ville Linux Foundation lancere en generisk løsning, der kan vedtages af alle distributioner.

På udkig efter en bedre løsning foreslog en Red Hat -udvikler Linus Torvalds følgende:

Hej Linus

Kan du medtage dette patch -sæt venligst?

Giver en funktion, hvormed nøgler dynamisk kan tilføjes til en kerne, der kører i sikker boot -tilstand. For at tillade, at en nøgle indlæses under en sådan betingelse, kræver vi, at den nye nøgle signeres af en nøgle, som vi allerede har (og som vi har tillid til), hvor de nøgler, vi "allerede har", kunne omfatte dem, der er indlejret i kernen, dem i UEFI -databasen og dem for den kryptografiske hardware.

Nu vil "keyctl add" allerede håndtere X.509 -certifikater, der er underskrevet på denne måde, men Microsofts signeringstjeneste vil kun underskrive eksekverbare EFI PE -binarier.

Vi kan kræve, at brugeren genstarter i BIOS, tilføjer nøglen og derefter skifter tilbage, men under visse omstændigheder vil vi være i stand til at gøre dette, mens kernen kører.

Den måde, vi har fundet på at rette dette på, er at integrere et X.509 -certifikat, der indeholder nøglen i et afsnit kaldet ".keylist" i en EFI PE -binær og derefter få Microsoft -signeret binær

Linus ord

Linus svar (Lad os huske, at det var før hans åndelige tilbagetog at genoverveje sin holdning i forhold til andre mennesker), var følgende:

BEMÆRK: Den følgende tekst indeholder bandeord

Guys, dette er ikke en pik sugende konkurrence.

Hvis du vil bruge PE -binærerne, skal du fortsætte. Hvis Red Hat ønsker at uddybe sit forhold til Microsoft, er det * dit * problem. Det har intet at gøre med den kerne, som jeg vedligeholder. Det er let for dig at have en signaturmotor, der analyserer PE -binæren, verificerer signaturerne og signerer de resulterende nøgler med din egen nøgle. Koden, for Guds skyld, er allerede skrevet, det er i den forbandede inklusionsanmodning.

Hvorfor skal jeg bekymre mig? Hvorfor skulle kernen bekymre sig om nogle idiotiske "vi underskriver kun PE -binarier" dumme? Vi understøtter X.509, som er standarden for signering.

Dette kan gøres på brugerniveau. Der er ingen undskyldning for at gøre det i kernen.

Linus

Min mening er, at Linus for en gangs skyld havde ret. Faktisk hverken Linux Foundation eller distributionerne skulle have været afpresset af Microsoft.  Det er rigtigt, at brugerne kunne være gået tabt. Men som det viste sig senere, var Windows 8 en fejl, og XP fortsatte med at regere meget længere.

Virkeligheden er, at når Microsoft står over for en kamp, ​​er det tvunget til at overholde standarderne. Det skete, da hun mislykkedes med SIlverlight og blev tvunget til at vedtage HTML 5 -webstandarden. Det skete, da hun måtte opgive web -rendering -motorudvikling og basere Edge på Chromium.

Vi skal heller ikke glemme, at for at tiltrække programmører måtte den indeholde intet mindre end muligheden for at køre Linux på Windows.

Linux -distributioner har en bedre position end nogensinde for at tilbyde brugerne et alternativ til at fortsætte med at bruge perfekt funktionel hardware.