Det er oversettelsene av to innlegg som James Bottomley har tatt på bloggen sin. Det første innlegget ble laget 1. februar og heter "LCA2013 and Restructuring the Secure Boot"
Jeg har vært stille en stund, så det er på tide med en oppdatering om hva som skjer med Linux Foundations Secure Boot Loader (spesielt siden den ble presentert på LCA2013). ( Lenke til lysbildene )
Kjernen i problemet er at GregKH (Greg Kroah-Hartman, en kjerneutvikler) oppdaget tidlig i desember at den foreslåtte Pre-BootLoader ikke ville fungere i sin nåværende form med Gummiboot. Dette var nedslående fordi det betydde at den ikke oppfylte Linux Foundations oppdrag om å aktivere alle oppstartslastere. Årsaken, etter undersøkelse, var enkel: Gummiboot ble laget for å demonstrere at man kunne lage en liten, enkel oppstartslaster som utnyttet alle tjenestene som var tilgjengelige på UEFI-plattformen, i stedet for å være en massiv lenkelaster som GRUB. Dessverre betyr dette at den starter opp kjerner ved hjelp av BootServices->LoadImage()-funksjonen, som betyr at kjernen som skal startes opp må gå gjennom de sikre oppstartskontrollene på UEFI-plattformen. Opprinnelig ble Pre-BootLoader, i likhet med shim (Mathew Garretts oppstartslaster), skrevet for å bruke PE/Coff-lenkelasting for å omgå de sikre oppstartskontrollene. Dessverre betyr dette at alt som utføres av Pre-BootLoader også må bruke lenkelasting for å overvinne sikre oppstartskontroller på alt den vil laste, og derfor vil ikke Gummiboot, som bevisst ikke er en lenkelaster, fungere under denne ordningen.
Så jeg måtte omstrukturere og skrive om: Problemet gikk nå fra "hvordan lage en koblingslaster signert av Microsoft som følger retningslinjene deres" til "hvordan man aktiverer alle barna til opplasteren for å bruke BootServices-> LoadImage () -funksjonen til måte å adlyde deres politikk på. ' Heldigvis er det en måte å fange UEFI-plattformens signeringsinfrastruktur ved å installere din egen sikkerhetsprotokoll for arkitektur. Dessverre er ikke plattformens initialiseringsspesifikasjon en del av UEFI-spesifikasjonen, men heldigvis er den implementert av alle Windows 8-system du kan finne. Den nye arkitekturen fanger opp protokollen og legger til sin egen sikkerhetskontroll. Imidlertid er det et annet problem: Mens vi er i tilbakeringing av arkitektursikkerhetsprotokollen, eier vi ikke nødvendigvis UEFI-systemskjermen, noe som gjør det helt umulig å gjøre en brukertest for å autorisere utførelsen av binærprogrammet. Heldigvis er det en ikke-interaktiv måte å gjøre dette på, og det er SUSE Machine Owner Key (MOK) -mekanismen. Derfor utviklet Linux Foundation Pre-BootLoader seg nå til å bruke standard MOK-variablene til å lagre autoriserte binære hashes.
Resultatet av alt dette er at du nå kan bruke Pre-BootLoader med Gummiboot (akkurat som det ble gjort i demoen på LCA2013). For å starte, må du legge til 2 hashes: en for selve Gummiboot og den andre for kjernen du vil starte, men det er faktisk en god ting fordi du nå har en enkelt sikkerhetspolicy som styrer hele oppstartssekvensen. Selve Gummiboot ble også lappet for å gjenkjenne et krasj på grunn av sikker oppstart og viser en melding som forteller deg hvilken hash du skal registrere deg.
Jeg vil gjøre et eget innlegg som forklarer hvordan den nye arkitekturen fungerer, men jeg trodde det ville være bedre å forklare hva som skjedde i forrige måned.
Og dette andre innlegget gjorde han i går og heter "Lanserte Linux Foundation Secure Boot System"
Som lovet, her er Linux Foundation Secure Boot System. Den ble faktisk gitt ut av oss 6. februar, men med reiser, konferanser og møter rakk jeg ikke å validere alt før i dag. Filene er:
PreLoader.efi (md5sum 4f7a4f566781869d252a09dc84923a82)
HashTool.efi (md5sum 45639d23aa5f2a394b03a65fc732acf2)
Lag også et oppstartbart mini-USB-bilde; (Du må installere den på USB ved hjelp av dd; bildet har GPT-partisjoner, så det bruker hele disken). Den har et EFI-skall der kjernen skal være og bruker gummiboot for å laste den. Du finner den her (md5sum 7971231d133e41dd667a184c255b599f).For å bruke mini-USB-bildet må du legge inn hasjene for loader.efi (i \ EFI \ BOOT-mappen) og shell.efi (i rotmappen). Den inneholder også en kopi av KeyTool.efi du må oppgi hashen for å kjøre.
Hva skjedde med KeyTool.efi? Det skulle opprinnelig være en del av vårt signerte kit. Imidlertid oppdaget Microsoft at på grunn av en feil i en av UEFI-plattformene, kunne den brukes til å fjerne plattformnøkkelen programmatisk, noe som ville ødelegge UEFI-sikkerhetssystemet. Inntil vi kan løse dette (vi har den private leverandøren i løkken) nektet de å signere KeyTool.efi, selv om du kan autorisere det ved å legge til MOK-variabler hvis du vil kjøre det.
Gi meg beskjed om hvordan dette går fordi jeg er interessert i å samle inn tilbakemeldinger på hva som fungerer og hva som ikke fungerer. Spesielt er jeg bekymret for at sikkerhetsprotokolloverstyringen ikke vil fungere på noen plattformer, så jeg vil spesielt vite 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/
Bestem om det er gode eller dårlige nyheter.