Két bejegyzés fordítását jelentik, amelyeket James Bottomley tett a blogján. Az első bejegyzés február 1-jén készült, és az "LCA2013 és a biztonságos rendszerindítás újraszervezése" címet viseli.
Kicsit csendben voltam, ezért ideje frissítést adni arról, hogy mi történik a Linux Foundation Secure Boot Loader-jével (főleg, hogy az LCA2013-on szerepelt). (Link a diákra)
A probléma lényege, hogy a GregKH (kernelfejlesztő Greg Kroah-Hartman) december elején fedezte fel, hogy a javasolt Pre-BootLoader a jelenlegi formájában nem fog működni a Gummiboot-tal. Ez kissé ijesztő volt, mert azt jelentette, hogy nem teljesíti a Linux Alapítvány azon küldetését, hogy aktiválja az összes rendszerbetöltőt. A kutatás során az ok egyszerű volt: a Gummiboot-ot azért hozták létre, hogy bemutassák, hogy készíthet egy kicsi, egyszerű rendszerbetöltőt, amely kihasználja az UEFI platformon elérhető összes szolgáltatást, ahelyett, hogy olyan masszív link betöltő lenne, mint a GRUB. Sajnos ez azt jelenti, hogy a rendszermagokat a BootServices-> LoadImage () függvény segítségével indítja, ami azt jelenti, hogy az indítandó kernek át kell mennie az UEFI platform biztonságos indításellenőrzésén. Eredetileg a Pre-BootLoader, hasonló alátétlemez (Mathew Garrett bootloaderje), a PE / Coff link betöltésével használták a biztonságos indításellenőrzés legyőzésére. Sajnos ez azt jelenti, hogy a Pre-BootLoader által futtatott valaminek a link betöltését is fel kell használnia a biztonságos indításellenőrzés legyőzéséhez, bármit is be akar tölteni, ezért a Gummiboot, amely szándékosan nem link betöltő, nem fog működni ebben a sémában.
Tehát át kellett strukturálnom és át kellett írnom: A probléma mostantól kezdve "hogyan hozhatunk létre egy, a Microsoft által aláírt link betöltőt, amely betartja a házirendjüket", átkerült a problémába, hogy "hogyan engedélyezhetem a rendszerindító betöltő összes gyermekének a hogy engedelmeskedjenek politikájuknak. Szerencsére van mód az UEFI platform-aláíró infrastruktúra elfogására saját architektúra biztonsági protokolljának telepítésével. Sajnos a platform inicializálási specifikációja valójában nem része az UEFI specifikációnak, de szerencsére minden megtalálható Windows 8 rendszer megvalósítja. Az új architektúra elfogja ezt a protokollt, és hozzáadja a saját biztonsági ellenőrzését. Van azonban egy második probléma: Amíg az architektúra biztonsági protokolljának visszahívásában vagyunk, nem feltétlenül az UEFI rendszer képernyője a miénk, így teljesen lehetetlenné válik a bináris futtatás engedélyezésére szolgáló felhasználói teszt elvégzése. Szerencsére erre van egy nem interaktív módszer, ez a SUSE Machine Owner Key (MOK) mechanizmus. Ezért a Linux Foundation Pre-BootLoader most úgy fejlődött, hogy szabványos MOK változókat használjon az engedélyezett bináris hashek tárolására.
Mindennek az a következménye, hogy most már használhatja a Pre-BootLoadert a Gummiboot-tal (akárcsak az LCA2013 demójában). A rendszerindításhoz hozzá kell adni 2 kivonatot: az egyiket magának a Gummiboot-nak, a másikat pedig a kernelnek, amelyet indítani akarunk, de valójában ez egy jó dolog, mert most egyetlen biztonsági házirend vezérli a teljes rendszerindítási sorrendet. Maga a Gummiboot is javításra került, hogy felismerje a biztonságos indítás miatti összeomlást, és üzenetet jelenít meg arról, hogy melyik hash-t kell regisztrálnia.
Külön bejegyzést készítek az új architektúra működéséről, de úgy gondoltam, jobb lenne elmagyarázni, mi történt a múlt hónapban.
És ez a második bejegyzés, amelyet tegnap tett, és amelynek neve "Elindította a Linux Foundation biztonságos rendszerindító rendszerét"
Ahogy ígértem, itt van a Linux Foundation Secure Boot System. Valójában február 6-án adta ki nekünk a Microsoft, de az utazásokkal, konferenciákkal és találkozókkal a mai napig nem volt időm mindent érvényesíteni. A fájlok a következők:
PreLoader.efi (md5sum 4f7a4f566781869d252a09dc84923a82)
HashTool.efi (md5sum 45639d23aa5f2a394b03a65fc732acf2)
Hozzon létre egy indítható mini-USB képet is; (A dd használatával telepítenie kell az USB-re; a kép GPT partíciókkal rendelkezik, tehát az egész lemezt használja). Van egy EFI héja, ahol a kernnek lennie kell, és a gummiboot segítségével tölti be. Itt megtalálja (md5sum 7971231d133e41dd667a184c255b599f).A mini-USB kép használatához meg kell adnia a rakományt a loader.efi (az \ EFI \ BOOT mappában) és a shell.efi (a gyökér mappában). Tartalmazza a KeyTool.efi másolatát is, a futtatáshoz meg kell adnia a hash-t.
Mi történt a KeyTool.efi-vel? Eredetileg aláírt készletünk része volt. A tesztelés során a Microsoft azonban felfedezte, hogy az UEFI platformok egyikének hibája miatt fel lehet használni a platform kulcsának programszerű eltávolítására, ami tönkretenné az UEFI biztonsági rendszert. Amíg ezt nem tudjuk megoldani (a hurokban van egy magánszolgáltató), addig nem voltak hajlandók aláírni a KeyTool.efi fájlt, bár a FOK futtatásához engedélyezheti MOK-változók hozzáadásával.
Mondja el, hogy megy ez, mert érdekelne visszajelzések gyűjtése arról, hogy mi működik és mi nem. Különösen aggasztónak tartom, hogy a biztonsági protokoll felülírása egyes platformokon nem fog működni, ezért különösképpen szeretném tudni, hogy nem működik-e nekik.
forrás:
http://blog.hansenpartnership.com/lca2013-and-rearchitecting-secure-boot/
http://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/
Döntse el, hogy jó vagy rossz hír-e.