Dvě novinky týkající se pre-bootloaderu

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í“

Trochu jsem byl zticha, takže je čas dát aktuální informace o tom, co se děje se zabezpečeným zavaděčem Linux Foundation (zejména to, že byl uveden na LCA2013). (Odkaz na snímky)

Podstata problému spočívá v tom, že GregKH (vývojář jádra Greg Kroah-Hartman) na začátku prosince zjistil, že navrhovaný Pre-BootLoader nebude v současné podobě s Gummiboot fungovat. To bylo trochu skličující, protože to znamenalo, že to neplnilo poslání Linux Foundation aktivovat všechny bootloadery. Ve výzkumu byl důvod prostý: Gummiboot byl vytvořen, aby prokázal, že můžete vytvořit malý a jednoduchý bootloader, který by využíval výhod všech služeb dostupných na platformě UEFI, místo aby byl masivním zavaděčem odkazů, jako je GRUB. Bohužel to znamená, že zavádíte jádra pomocí funkce BootServices-> LoadImage (), což znamená, že jádro, které se má zavést, musí projít kontrolami bezpečného spuštění na platformě UEFI. Původně jako Pre-BootLoader shim (Bootloader Mathewa Garretta), byl napsán, aby používal načítání odkazů PE / Coff, aby porazil kontroly bezpečného bootování. Bohužel to znamená, že něco spuštěné programem Pre-BootLoader musí také používat načítání odkazů, aby porazilo kontroly bezpečného spuštění u všeho, co chce načíst, a proto Gummiboot, který záměrně není zavaděčem odkazů, nebude v rámci tohoto 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.