De är översättningarna av två inlägg som James Bottomley har tagit på sin blogg. Det första inlägget gjordes den 1 februari och kallas "LCA2013 och omstrukturering av den säkra start"
Jag var tyst lite, så det är dags att ge en uppdatering om vad som händer med Linux Foundation Secure Boot Loader (speciellt att den presenterades på LCA2013). (Länk till bilderna)
Kärnan i problemet är att GregKH (kärnutvecklare Greg Kroah-Hartman) upptäckte i början av december att den föreslagna Pre-BootLoader inte skulle fungera i sin nuvarande form med Gummiboot. Det var något skrämmande eftersom det innebar att det inte uppfyllde Linux Foundation uppdrag att aktivera alla startladdare. I forskningen var anledningen enkel: Gummiboot skapades för att visa att du kunde skapa en liten och enkel bootloader som skulle dra nytta av alla tjänster som finns tillgängliga på UEFI-plattformen istället för att vara en massiv länklastare som GRUB. Tyvärr betyder det att du startar kärnor med BootServices-> LoadImage () -funktionen, vilket innebär att kärnan som ska startas måste gå igenom de säkra startkontrollerna på UEFI-plattformen. Ursprungligen Pre-BootLoader, som shim (Mathew Garrett's bootloader), skrevs för att använda PE / Coff-länkbelastning för att slå säkra startkontroller. Tyvärr betyder det att något som körs av Pre-BootLoader också måste använda länkladdning för att slå de säkra startkontrollerna på allt det vill ladda och därför kommer Gummiboot, som medvetet inte är en länkladdare, inte fungerar enligt detta schema.
Så jag var tvungen att omstrukturera och skriva om: Problemet gick nu från "hur man skapar en länkladdare signerad av Microsoft som följer deras policyer" till "hur man aktiverar alla barn i startladdaren för att använda BootServices-> LoadImage () -funktionen sätt att följa deras politik. Lyckligtvis finns det ett sätt att fånga UEFI-plattformens signeringsinfrastruktur genom att installera ditt eget arkitektursäkerhetsprotokoll. Tyvärr är plattformsinitieringsspecifikationen faktiskt inte en del av UEFI-specifikationen, men tack och lov implementeras den av alla Windows 8-system du kan hitta. Den nya arkitekturen avlyssnar protokollet och lägger till sin egen säkerhetskontroll. Det finns emellertid ett andra problem: Medan vi befinner oss i återuppringning av arkitektursäkerhetsprotokollet äger vi inte nödvändigtvis UEFI-systemskärmen, vilket gör det helt omöjligt att göra ett användartest för att auktorisera körningen av binärsystemet. Lyckligtvis finns det ett icke-interaktivt sätt att göra detta och det är SUSE Machine Owner Key (MOK) -mekanismen. Därför utvecklades Linux Foundation Pre-BootLoader nu till att använda standard MOK-variabler för att lagra auktoriserade binära hash.
Resultatet av allt detta är att du nu kan använda Pre-BootLoader med Gummiboot (precis som det gjordes i demo på LCA2013). För att starta måste du lägga till två hash: en för Gummiboot själv och den andra för kärnan som du vill starta, men det är faktiskt en bra sak för nu har du en enda säkerhetspolicy som kontrollerar hela startsekvensen. Gummiboten själv lappades också för att känna igen en bugg på grund av den säkra start och visar ett meddelande som berättar vilken hash du ska registrera.
Jag kommer att göra ett separat inlägg som förklarar hur den nya arkitekturen fungerar, men jag trodde att det skulle vara bättre att förklara vad som hände förra månaden.
Och det här andra inlägget gjorde han igår och heter "Lanserade Linux Foundation Secure Boot System"
Som lovat är här Linux Foundation Secure Boot System. Det släpptes faktiskt till oss av Microsoft den 6 februari, men med resor, konferenser och möten hade jag inte tid att validera allt förrän idag. Filerna är:
PreLoader.efi (md5sum 4f7a4f566781869d252a09dc84923a82)
HashTool.efi (md5sum 45639d23aa5f2a394b03a65fc732acf2)
Skapa också en startbar mini-USB-bild; (Du måste installera den på USB med dd; bilden har GPT-partitioner, så den använder hela disken). Den har ett EFI-skal där kärnan ska vara och använder gummiboot för att ladda den. Du hittar den här (md5sum 7971231d133e41dd667a184c255b599f).För att använda mini-USB-bilden måste du ange hash för loader.efi (i mappen \ EFI \ BOOT) och shell.efi (i rotmappen). Den innehåller också en kopia av KeyTool.efi, du måste ange hash för att köra.
Vad hände med KeyTool.efi? Det skulle ursprungligen bli en del av vårt signerade kit. Men under testet upptäckte Microsoft att på grund av ett fel i en av UEFI-plattformarna kunde den användas för att ta bort plattformsnyckeln programmatiskt, vilket skulle förstöra UEFI-säkerhetssystemet. Tills vi kan lösa detta (vi har den privata leverantören i slingan) vägrade de att underteckna KeyTool.efi även om de kan auktorisera det genom att lägga till MOK-variabler om de vill köra det.
Låt mig veta hur detta går eftersom jag är intresserad av att få feedback om vad som fungerar och vad som inte fungerar. Jag är särskilt oroad över att säkerhetsprotokollets åsidosättning inte kommer att fungera på vissa plattformar, så jag vill särskilt veta om det inte fungerar för dem.
Källor:
http://blog.hansenpartnership.com/lca2013-and-rearchitecting-secure-boot/
http://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/
Bestäm om det är goda eller dåliga nyheter.