Две новини относно предварителния буутлоудър

Те са преводи на две публикации, които Джеймс Ботомли е взел в своя блог. Първият пост е направен на 1 февруари и се казва „LCA2013 и преструктуриране на сигурното зареждане“

Бях тихо за малко, така че е време да дам актуализация на това, което се случва със Secure Boot Loader на Linux Foundation (особено, че беше представен на LCA2013). (Връзка към слайдовете)

Същността на проблема е, че GregKH (разработчикът на ядрото Грег Кроах-Хартман) откри в началото на декември, че предложеният Pre-BootLoader няма да работи в сегашния си вид с Gummiboot. Това беше донякъде обезсърчително, защото означаваше, че не изпълнява мисията на Linux Foundation да активира всички буутлоудъри. При изследването причината беше проста: Gummiboot е създаден, за да демонстрира, че можете да направите малък, прост буутлоудър, който да се възползва от всички услуги, налични на платформата UEFI, вместо да бъде масивен линк за зареждане като GRUB. За съжаление това означава, че зареждате ядра с помощта на функцията BootServices-> LoadImage (), което означава, че ядрото, което трябва да бъде стартирано, трябва да премине през проверките за сигурно зареждане на платформата UEFI. Първоначално Pre-BootLoader, като шайба (Буутлоудъра на Матю Гарет), е написан, за да използва зареждане на PE / Coff връзка, за да победи сигурни проверки за зареждане. За съжаление, това означава, че нещо, изпълнявано от Pre-BootLoader, трябва също да използва зареждане на връзки, за да победи защитените проверки за зареждане на всичко, което иска да зареди и следователно Gummiboot, който умишлено не е зареждащ линк, няма да работи при това схема.

Така че трябваше да преструктурирам и пренапиша: Проблемът сега премина от „как да създам зареждащ линк, подписан от Microsoft, който се подчинява на техните политики“, до „как да активирам всички деца на зареждащия буут, за да използвам функцията BootServices-> LoadImage () на начин да се подчиняват на техните политики. ' За щастие има начин да прихванете инфраструктурата за подписване на платформата UEFI, като инсталирате собствен протокол за защита на архитектурата. За съжаление, спецификацията за инициализация на платформата всъщност не е част от спецификацията на UEFI, но за щастие тя се прилага от всяка система на Windows 8, която можете да намерите. Новата архитектура прихваща този протокол и добавя собствена проверка за сигурност. Има обаче втори проблем: Докато сме в обратното извикване на протокола за защита на архитектурата, ние не притежаваме непременно екрана на системата UEFI, което прави напълно невъзможно да се направи потребителски тест, който да разреши изпълнението на двоичния файл. За щастие има неинтерактивен начин да направите това и това е механизмът на собственика на машината SUSE (MOK). Следователно, Linux Foundation Pre-BootLoader сега еволюира, за да използва стандартните променливи MOK за съхраняване на оторизирани двоични хешове.

Резултатът от всичко това е, че вече можете да използвате Pre-BootLoader с Gummiboot (точно както беше направено в демонстрацията на LCA2013). За да стартирате, трябва да добавите 2 хеша: единия за самия Gummiboot, а другия за ядрото, което искате да стартирате, но всъщност е добре, защото сега имате една единствена политика за сигурност, контролираща цялата последователност на зареждане. Самият Gummiboot също беше закърпен, за да разпознае грешка поради сигурното зареждане и показва съобщение, което ви казва кой хеш да се регистрирате.

Ще направя отделна публикация, обясняваща как работи новата архитектура, но мислех, че ще е по-добре да обясня какво се е случило миналия месец.

И този втори пост, който той направи вчера, се казва „Стартира системата за сигурно зареждане на Linux Foundation“

Както беше обещано, ето и Linux Foundation Secure Boot System. Всъщност ни беше пуснат от Microsoft на 6 февруари, но с пътуванията, конференциите и срещите нямах време да проверя всичко до днес. Файловете са:

PreLoader.efi (md5sum 4f7a4f566781869d252a09dc84923a82)
HashTool.efi (md5sum 45639d23aa5f2a394b03a65fc732acf2)
Също така създайте стартиращ мини-USB образ; (Трябва да го инсталирате на USB с помощта на dd; изображението има GPT дялове, така че използва целия диск). Той има EFI черупка, където трябва да бъде ядрото и използва gummiboot, за да го зареди. Можете да го намерите тук (md5sum 7971231d133e41dd667a184c255b599f).

За да използвате мини-USB изображението, трябва да въведете хешовете за loader.efi (в папката \ EFI \ BOOT) и shell.efi (в основната папка). Той също така включва копие на KeyTool.efi, трябва да въведете хеш, за да стартирате.

Какво се случи с KeyTool.efi? Първоначално щеше да бъде част от подписания ни комплект. По време на тестването обаче Microsoft откри, че поради грешка в една от платформите на UEFI, той може да се използва за програмно премахване на ключа от платформата, което би развалило системата за сигурност на UEFI. Докато не успеем да разрешим това (ние имаме частния доставчик в цикъла), те отказаха да подпишат KeyTool.efi, въпреки че можете да го упълномощите, като добавите променливи MOK, ако искате да го стартирате.

Кажете ми как става това, защото се интересувам от събирането на отзиви за това какво работи и кое не. По-специално съм загрижен, че замяната на протокола за сигурност няма да работи на някои платформи, така че особено искам да знам дали не работи за тях.

Фуентес:

http://blog.hansenpartnership.com/lca2013-and-rearchitecting-secure-boot/

http://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/

Решете дали това са добри или лоши новини.