Jedná se o překlady dvou příspěvků, které na svém blogu zaujal James Bottomley. První příspěvek byl zveřejněn 1. února a má název „LCA2013 a restrukturalizace zabezpečeného spouštění“
Chvíli jsem mlčel, takže je čas na aktualizaci o tom, co se děje s Secure Boot Loaderem od Linux Foundation (zejména od jeho představení na LCA2013). ( Odkaz na slajdy )
Podstata problému spočívá v tom, že GregKH (Greg Kroah-Hartman, vývojář jádra) začátkem prosince zjistil, že navrhovaný Pre-BootLoader nebude ve své současné podobě fungovat s Gummibootem. To bylo odrazující, protože to znamenalo, že nenaplňuje poslání Linux Foundation, kterým je povolení všech bootloaderů. Důvod byl po prošetření jednoduchý: Gummiboot byl vytvořen, aby demonstroval, že lze vytvořit malý, jednoduchý bootloader, který by využíval všechny služby dostupné na platformě UEFI, místo aby byl masivním linkloaderem jako GRUB. Bohužel to znamená, že bootuje jádra pomocí funkce BootServices->LoadImage(), což znamená, že jádro, které se má bootovat, musí projít zabezpečenými bootovacími kontrolami na platformě UEFI. Původně byl Pre-BootLoader, stejně jako shim (bootloader Mathewa Garretta), napsán tak, aby používal link loading PE/Coff k obcházení zabezpečených bootovacích kontrol. Bohužel to znamená, že cokoli spuštěné programem Pre-BootLoader musí také použít načítání odkazů k překonání kontrol zabezpečeného spouštění u čehokoli, co chce načíst, a proto Gummiboot, který záměrně není zavaděčem odkazů, nebude v tomto schématu fungovat.
Takže jsem musel restrukturalizovat a přepsat: Problém nyní šel od „jak vytvořit zavaděč odkazů podepsaný společností Microsoft, který se řídí jejich zásadami“ až po „jak povolit všem dětem zavaděče používat funkci BootServices-> LoadImage () způsob, jak se řídit jejich politikou. Naštěstí existuje způsob, jak zachytit infrastrukturu podepisování na platformě UEFI instalací vlastního bezpečnostního protokolu architektury. Specifikace inicializace platformy bohužel ve skutečnosti není součástí specifikace UEFI, ale naštěstí ji implementuje každý systém Windows 8, který najdete. Nová architektura tento protokol zachytí a přidá vlastní kontrolu zabezpečení. Existuje však druhý problém: Zatímco jsme v zpětném volání bezpečnostního protokolu architektury, nutně nevlastníme obrazovku systému UEFI, takže je zcela nemožné provést uživatelský test, který by autorizoval provedení binárního souboru. Naštěstí existuje neinteraktivní způsob, jak to udělat, a tím je mechanismus SUSE Machine Owner Key (MOK). Proto se Linux Foundation Pre-BootLoader nyní vyvinul tak, aby používal standardní MOK proměnné k ukládání autorizovaných binárních hashů.
Výsledkem toho všeho je, že Pre-BootLoader lze nyní použít s Gummiboot (stejně jako to bylo provedeno v ukázce na LCA2013). Chcete-li zavést systém, musíte přidat 2 hashe: jeden pro samotný Gummiboot a druhý pro jádro, které chcete zavést, ale je to vlastně dobrá věc, protože nyní máte jedinou bezpečnostní politiku, která řídí celou spouštěcí sekvenci. Samotný Gummiboot byl také opraven, aby rozpoznal havárii kvůli zabezpečenému spuštění a zobrazí zprávu, která vám řekne, který hash se má zaregistrovat.
Udělám samostatný příspěvek vysvětlující, jak nová architektura funguje, ale myslel jsem si, že by bylo lepší vysvětlit, co se stalo minulý měsíc.
A tento druhý příspěvek, který včera udělal, se jmenuje „Spuštění systému Linux Foundation Secure Boot System“
Jak jsem slíbil, tady je Linux Foundation Secure Boot System. Ve skutečnosti nám ji vydala společnost Microsoft 6. února, ale při cestách, konferencích a schůzkách jsem do dnešního dne neměl čas vše ověřit. Soubory jsou:
PreLoader.efi (md5sum 4f7a4f566781869d252a09dc84923a82)
HashTool.efi (md5sum 45639d23aa5f2a394b03a65fc732acf2)
Vytvořte také zaváděcí obraz mini-USB; (Musíte jej nainstalovat na USB pomocí dd; obraz má oddíly GPT, použijte tedy celý disk). Má shell EFI, kde by mělo být jádro, a používá jej k načtení pomocí gummibootu. Najdete jej zde (md5sum 7971231d133e41dd667a184c255b599f).Chcete-li použít obrázek mini-USB, musíte zadat hodnoty hash pro loader.efi (ve složce \ EFI \ BOOT) a shell.efi (v kořenové složce). Zahrnuje také kopii KeyTool.efi, ke spuštění musíte zadat hash.
Co se stalo s KeyTool.efi? Původně to mělo být součástí naší podepsané sady. Během testování však Microsoft zjistil, že kvůli chybě v jedné z platforem UEFI by mohl být použit k programovému odebrání klíče platformy, což by zničilo bezpečnostní systém UEFI. Dokud to nevyřešíme (máme ve smyčce soukromého dodavatele), odmítli podepsat KeyTool.efi, i když jej můžete autorizovat přidáním proměnných MOK, pokud jej chcete spustit.
Dejte mi vědět, jak to jde, protože mě zajímá shromažďování zpětné vazby o tom, co funguje a co ne. Zejména se obávám, že přepsání bezpečnostního protokolu nemusí na některých platformách fungovat, takže chci zvláště vědět, jestli to pro ně nefunguje.
Zdroje:
http://blog.hansenpartnership.com/lca2013-and-rearchitecting-secure-boot/
http://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/
Rozhodněte se, zda jsou to dobré nebo špatné zprávy.