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 var litt stille, så det er på tide å gi en oppdatering om hva som skjer med Linux Foundation's Secure Boot Loader (spesielt at den ble omtalt på LCA2013). (Lenke til lysbildene)
Essensen av problemet er at GregKH (kjerneutvikler Greg Kroah-Hartman) oppdaget tidlig i desember at den foreslåtte Pre-BootLoader ikke ville fungere i sin nåværende form med Gummiboot. Det var noe skremmende fordi det betydde at det ikke oppfylte Linux Foundation's oppgave om å aktivere alle bootloaders. I forskningen var årsaken enkel: Gummiboot ble opprettet for å demonstrere at du kunne lage en liten, enkel bootloader som ville dra nytte av alle tjenestene som er tilgjengelige på UEFI-plattformen i stedet for å være en massiv koblingslaster som GRUB. Dessverre betyr det at du starter kjerner ved hjelp av BootServices-> LoadImage () -funksjonen, noe som betyr at kjernen som skal startes, må gå gjennom de sikre oppstartssjekkene på UEFI-plattformen. Opprinnelig Pre-BootLoader, som mellomlegg (Mathew Garrett's bootloader), ble skrevet for å bruke PE / Coff link loading for å bekjempe sikre oppstartssjekker. Dessverre betyr det at noe som drives av Pre-BootLoader også må bruke lenkeinnlasting for å slå de sikre oppstartsjekkene på hva det vil lastes inn, og derfor vil Gummiboot, som bevisst ikke er en koblingslaster, ikke fungere under dette 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.
Vel, jeg kan ikke se den langsiktige effekten, men for meg vil det være mitt mål å skaffe meg en av disse http://blog.linuxmint.com/?p=2055
De er veldig dyre, tror jeg.
Det er selskaper som selger datamaskiner uten forhåndsinstallert operativsystem. Andre lar deg velge mellom Ubuntu eller andre og sende det hjem til deg. Du kan også kjøpe delene og montere dem selv og sette operativsystemet du ønsker.
I byen din (GDL) er det en kjede av databutikker som selger datamaskiner uten forhåndsinstallert operativsystem. Du kan sette Linux på dem.
Det er alltid alternativer. I dette tilfellet er de fjerntliggende og veldig "skjult" for den vanlige brukeren. Men for de av oss som ønsker Linux, er det, det er det.
Det er ikke så mange alternativer for brukere i Latin-Amerika, siden de "spesielle" selskapene vanligvis ikke kommer hit
awwnnn trist, trist…. at jævla UEFI er et reelt problem
Rapporter feil…. hva skjedde? Hvorfor fikk jeg eplelogoen i kommentarene mine? Jeg bruker midori, men fra ubuntu, ikke fra en mac: /
Vel, veldig enkelt, du må bytte brukeragent.
Disse pluginene er basert på å søke etter en streng (tekststreng) i dette tilfellet ser de etter systemet ditt i brukeragenten, og midori-brukeragenten har en tekststreng som også har MacOS X, jeg kan ikke huske om intel eller Mac OSX eller to, men finn først denne strengen og relater den som om det var Mac. For en tid siden programmerte jeg et lignende skript i php og et annet javascript, og dette løses fra skriptet, da jeg ikke ser noe som kreves etter Mac OS X og sender resultatet til midori-variabelen, siden det er det eneste som skiller brukeragenten som brukes av midori med den fra Mac, eller vi kan også endre den.
Sjekk ut dette nettstedet med midori
http://whatsmyuseragent.com/
Og brukeragenten har ingenting med Linux å gjøre
Hilsen
«Carlos-Xfce
I byen din (GDL) er det en kjede av databutikker som selger datamaskiner uten forhåndsinstallert operativsystem. Du kan sette Linux på dem. "
På den tiden jeg så og ikke fant, bare en grossist som solgte meg netbooks uten operativsystem, men bare det, ingen PC eller bærbar datamaskin, bare netbook.
Kan du si navnet på kjeden?
Hvis utlegging av kjedenavnet kan feiltolkes, og regnes som nettsøppel, ville det være bra å vente til administratorene ga sin mening om det.