Реализация UEFI SecureBoot в ALT Linux

Вводная

Следует оговориться, что задокументированная реализация построена поверх предшествовавшей работы по поддержке загрузки в режиме UEFI, о чём было бы полезно написать отдельное HOWTO к тому моменту, когда мы этим занялись (конец 2012 года). Поскольку на данный момент основные дистрибутивы скорее умеют такую загрузку, было решено ограничиться пользовательской страничкой на вики и документированием средств сборки.

Ситуация с SecureBoot отличалась: по состоянию на 2013 год загружаться без отключения этой “ручки” и лишних проблем умели только Fedora, openSUSE и Ubuntu, причём сведения о реализации оказывались либо устаревшими, либо лоскутными, либо вместе.

Проблему можно охарактеризовать в нескольких частях, некоторые из которых являются (по крайней мере пока) одноразовыми, а другие — повторяющимися либо имеющими шанс свалиться на голову.

Одноразовая морока

Как и описывал Matthew Garrett, для авторизации на sysdev.microsoft.com пришлось обеспечить наличие IE/Windows, сертификата Symantec и логина live.com.

Сертификат Verisign/Symantec понадобится единственный раз, чтобы аутентифицировать компанию при регистрации на портале UEFI CA, а затем каждый раз, когда вы готовитесь загрузить очередной объект на рассмотрение и подпись. Это сертификат Authenticode class 3; его можно получить с одноразовой скидкой через Windows Dev Center. Для получения сертификата понадобится IE7+ с нестандартными настройками ActiveX — чтобы сначала его сгенерировать и импортировать, а затем экспортировать в файл.

Та же Windows-система (реальная или виртуальная) пригодится для заведения акаунта на sysdev.microsoft.com. Предлагаемые шаги:

1. завести акаунт live.com (sysdev.microsoft.com требует его для работы);
2. привязать/аутентифицировать компанию к этому акаунту (однократная процедура, заключается в подписывании тестового бинарника сертификатом Symantec/Verisign);
3. прочитать и принять лицензионные соглашения Microsoft.

Вам понадобится создать базу данных NSS с импортированными в нее сертификатами Symantec, скачать winqualexe.zip с сайта sysdev.microsoft.com, распаковать и подписать его (используя pesign), а затем закачать подписанный winqual.exe обратно. На момент осени 2013 г. требуется подписать лицензионные соглашения “Windows Logo Program Testing Agreement V3” и “UEFI Firmware Agreement”.

Многократная морока

Получение подписанного бинарника shim — последующая многократная процедура, которая выполняется каждый раз, когда вы собираете новую версию оного в пакет для выпуска. В процессе будет задействован все тот же Windows-хост или виртуалка с установленным Silverlight, подготовленный shim.efi с публичной частью вашего cacert, сертификат Symantec (чтобы подписать заявку), а также акаунт sysdev с правами подписи UEFI. Процедура занимает от нескольких дней до нескольких недель.

Процесс включает следующие шаги:

1. подготовка shim.efi;
2. заливка shim.cab на sysdev.microsoft.com;
3. отправка запроса на sysdev@microsoft.com;
4. ожидание и периодическая проверка входящих и спам-бокса вашего почтового акаунта;
5. скачивание подписанного бинарника, если/когда процесс наконец будет завершен.

По большому счету, есть два варианта EFI shim: старше версии 0.5 либо новее (сама версия 0.5 поломана). Начиная с версии 0.5, реализованы дополнительные ограничения по вторичному загрузчику, что потребует подписывать еще и образы ядра. Версия 0.4 лишена этого функционала, но нет гарантии, что вам удастся ее подписать (как это удалось сделать нам).

При подаче заявки с shim.cab вы получите номер заявки — submission ID, который потом будет использоваться в переписке с sysdev@microsoft.com для идентификации вашей заявки. Переписка может включать типовой вопросник от sysdev@microsoft.com на предмет дополнительных подробностей о вашем shim. По-видимому, в sysdev проверяют очередь заявок раз или два в неделю. Чтобы ускорить процедуру, можно заранее выслать ответы на ссылкой на полученный submission ID в теме письма.

Собирая все вместе

После получения подписанного бинарника shim понадобится аппаратный или виртуальный стенд со включенным SecureBoot, поддержка UEFI boot/install, а также терпение для внесения доработок в уже работающие части.
Вы должны убедиться в наличии верифицированной загрузочной цепочки при включенном SecureBoot как для установочного/загрузочного образа, так и для установленной ОС:

1. bootx64.efi или shim.efi (shim);
2. grubx64.efi (первичный бутменеджер или загрузчик);
3. vmlinuz (ядро) либо вторичный загрузчик;

цепочка может варьироваться после shim, но основные принципы сохраняются:

1. shim верифицируется ключем, который предоставляется для firmware с помощью KEK/DB, а затем верифицирует бинарник загрузчика с помощью встроенного сертификата, MOK или firmware;
2. последующие загрузчики могут обмениваться информацией с shim чтобы использовать информацию о вашем сертификате, встроенном в него, и MOK, добавленных пользователем конкретной машины.

ALT way

Ваша реализация может сильно отличаться; ALT Linux сейчас использует следующую:

shim -> refind -> elilo -> vmlinuz для install/live/rescue media 
shim -> grub2 -> vmlinuz для установленной системы

Мы используем refind в качестве бут-менеджера, поскольку некоторые реализации UEFI поставляются с кривыми реализациями выбора цели загрузки или не имеют таковой вовсе; elilo работает в качестве фильтра, позволяющего загрузить ядро Linux — нам это необходимо, т.к. мы хотим дать пользователям возможность загрузки неподписанных ядер и при этом не оставлять дыру, позволяющую загрузить что попало.