Det er oversættelserne af to indlæg, som James Bottomley har taget på sin blog. Det første indlæg blev lavet den 1. februar og kaldes "LCA2013 og Restrukturering af den sikre opstart"
Jeg var stille lidt, så det er på tide at give en opdatering om, hvad der foregår med Linux Foundation's Secure Boot Loader (især at det blev vist på LCA2013). (Link til diasene)
Essensen af problemet er, at GregKH (kerneudvikler Greg Kroah-Hartman) opdagede i begyndelsen af december, at den foreslåede Pre-BootLoader ikke ville fungere i sin nuværende form med Gummiboot. Det var noget skræmmende, fordi det betød, at det ikke opfyldte Linux Foundation's mission om at aktivere alle bootloadere. I undersøgelsen var årsagen enkel: Gummiboot blev oprettet for at demonstrere, at du kunne lave en lille og simpel bootloader, der ville drage fordel af alle de tilgængelige tjenester på UEFI-platformen i stedet for at være en massiv linklæsser som GRUB. Desværre betyder det, at du starter kerner ved hjælp af BootServices-> LoadImage () -funktionen, hvilket betyder, at kernen, der skal startes, skal gennemgå de sikre bootkontroller på UEFI-platformen. Oprindeligt Pre-BootLoader, ligesom shim (Mathew Garrett's bootloader), blev skrevet til at bruge PE / Coff-linkindlæsning for at besejre sikre opstartscheck. Desværre betyder det, at noget, der udføres af Pre-BootLoader også skal bruge linkindlæsning for at slå de sikre opstartscheck på alt, hvad det vil indlæse, og derfor fungerer Gummiboot, som bevidst ikke er en linkindlæser, ikke under denne ordning.
Så jeg var nødt til at omstrukturere og omskrive: Problemet gik nu fra "hvordan man opretter en link loader underskrevet af Microsoft, der overholder deres politikker" til "hvordan man gør det muligt for alle børn i boot loader at bruge BootServices-> LoadImage () funktionen af måde at adlyde deres politikker på. Heldigvis er der en måde at opfange UEFI-platformens underskriftsinfrastruktur ved at installere din egen arkitektursikkerhedsprotokol. Desværre er platformens initialiseringsspecifikation faktisk ikke en del af UEFI-specifikationen, men heldigvis implementeres den af ethvert Windows 8-system, du kan finde. Den nye arkitektur opfanger protokollen og tilføjer sin egen sikkerhedskontrol. Der er dog et andet problem: Mens vi er i tilbagekaldelse af arkitekturens sikkerhedsprotokol, ejer vi ikke nødvendigvis UEFI-systemskærmen, hvilket gør det helt umuligt at lave en brugertest for at godkende udførelsen af binærprogrammet. Heldigvis er der en ikke-interaktiv måde at gøre dette på, og det er SUSE Machine Owner Key (MOK) -mekanismen. Derfor udviklede Linux Foundation Pre-BootLoader nu sig til at bruge standard MOK-variabler til at gemme autoriserede binære hashes.
Resultatet af alt dette er, at Pre-BootLoader nu kan bruges med Gummiboot (ligesom det blev gjort i demoen på LCA2013). For at starte, skal du tilføje 2 hashes: en til selve Gummiboot og den anden til kernen, som du vil starte, men faktisk er det en god ting, for nu har du en enkelt sikkerhedspolitik, der styrer hele opstartssekvensen. Selve Gummiboot blev også patchet for at genkende et nedbrud på grund af sikker opstart og viser en besked, der fortæller dig, hvilken hash du skal tilmelde dig.
Jeg vil lave et separat indlæg, der forklarer, hvordan den nye arkitektur fungerer, men jeg troede, det ville være bedre at forklare, hvad der skete i sidste måned.
Og dette andet indlæg gjorde han i går og hedder "Lanceret Linux Foundation Secure Boot System"
Som lovet er her Linux Foundation Secure Boot System. Det blev faktisk frigivet til os af Microsoft den 6. februar, men med rejser, konferencer og møder havde jeg ikke tid til at validere alt indtil i dag. Filerne er:
PreLoader.efi (md5sum 4f7a4f566781869d252a09dc84923a82)
HashTool.efi (md5sum 45639d23aa5f2a394b03a65fc732acf2)
Opret også et bootbart mini-USB-billede; (Du skal installere det på USB ved hjælp af dd; billedet har GPT-partitioner, så det bruger hele disken). Den har en EFI-skal, hvor kernen skal være, og bruger gummiboot til at indlæse den. Du kan finde det her (md5sum 7971231d133e41dd667a184c255b599f).For at bruge mini-USB-billedet skal du indtaste hashes for loader.efi (i mappen \ EFI \ BOOT) og shell.efi (i rodmappen). Det inkluderer også en kopi af KeyTool.efi, du skal indtaste hash'en for at køre.
Hvad skete der med KeyTool.efi? Det skulle oprindeligt være en del af vores underskrevne sæt. Under testen opdagede Microsoft imidlertid, at på grund af en fejl i en af UEFI-platformene, kunne den bruges til at fjerne platformnøglen programmatisk, hvilket ville ødelægge UEFI-sikkerhedssystemet. Indtil vi kan løse dette (vi har den private sælger i løkken) nægtede de at underskrive KeyTool.efi, selvom de kan godkende det ved at tilføje MOK-variabler, hvis de vil køre det.
Lad mig vide, hvordan dette går, fordi jeg er interesseret i at indsamle feedback om, hvad der fungerer og hvad der ikke fungerer. Især er jeg bekymret for, at sikkerhedsprotokoloverstyringen ikke fungerer på nogle platforme, så jeg vil især gerne vide, om det ikke fungerer for dem.
Kilder:
http://blog.hansenpartnership.com/lca2013-and-rearchitecting-secure-boot/
http://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/
Beslut om det er gode eller dårlige nyheder.