Две новости о предзагрузчике

Это перевод двух сообщений, которые Джеймс Боттомли разместил в своем блоге. Первый пост был сделан 1 февраля и называется «LCA2013 и Реструктуризация безопасной загрузки».

Некоторое время я молчал, так что пришло время рассказать о том, что происходит с безопасным загрузчиком 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 Machine Owner Key (MOK). Таким образом, Linux Foundation Pre-BootLoader теперь использует стандартные переменные MOK для хранения авторизованных двоичных хэшей.

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

Я сделаю отдельный пост, объясняющий, как работает новая архитектура, но я подумал, что было бы лучше объяснить, что произошло в прошлом месяце.

И этот второй пост, который он сделал вчера, называется «Запустил систему безопасной загрузки Linux Foundation».

Как и было обещано, вот система безопасной загрузки Linux Foundation. На самом деле он был предоставлен нам Microsoft 6 февраля, но с поездками, конференциями и встречами у меня не было времени все проверить до сегодняшнего дня. Это файлы:

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

Чтобы использовать образ mini-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/

Решите, хорошие это новости или плохие.