Управление загрузчиками EFI в Linux: режим безопасной загрузки Secure Boot

Оригинал: Managing EFI Boot Loaders for Linux: Dealing with Secure Boot
Автор: Roderick W. Smith
Дата публикации: 6 июля 2013 г.
Перевод: Н.Ромоданов
Дата перевода: февраль 2014 г.

Кроме реализации нового протокола загрузки, в UEFI добавлена новая функция, которая потенциально может вызвать много путаницы и проблем, но она также может улучшить безопасность системы: режим безопасной загрузки Secure Boot. Как следует из названия, режим Secure Boot является средством обеспечения безопасности. Его потенциал повышения безопасности системы будет наибольшим в системах Windows. Но, режим Secure Boot, из-за из своих особенностей, может усложнить загрузку Linux. В статье описывается, что представляет собой режим Secure Boot и как на него реагирует сообщество Linux. Имейте в виду, что ситуация меняется быстро, так что если вы читаете текст через несколько месяцев после его обновления, то положение дел уже могло измениться!

Что такое режим безопасной загрузки Secure Boot?

В течение десятилетий персональные компьютеры страдали от вирусов, червей и других вредоносных программ. Некоторые из самых ранних вирусов для персональных компьютеров распространялись как вирусы загрузочного сектора: Они размещались в виде кода в загрузочных секторах дискет и, когда пользователи загружали свои компьютеры с помощью зараженных дискет DOS, передавались от одного компьютера к другому. Несмотря на то, как дискеты потеряли свою важность, и широкую известность приобрели другие пути передачи вирусов, а обычным делом стало подключение к сети Интернет, вредоносный код, попадающий в компьютер во время начальной загрузки, всегда среди приоритетных интересов у авторов вредоносных программ. За счет того, что он выполняется раньше, чем ядро ОС возьмет управление над компьютером, вредоносная программа может «спрятаться» такими способами, которыми не удастся воспользоваться после того, как операционная система берет на себя управление. Предварительно загруженная вредоносная программа может стать невидимой для операционной системы, и антивирусным сканерам практически не удается обнаружить вредоносные программы, по крайней мере, без перезагрузки в спасательную систему, которая не заражена.

В BIOS совсем мало возможностей защиты от инфицирования предварительно загружаемыми вредоносными программами; когда происходит загрузка BIOS, ОС неявно доверяет всему, что выполняется в качестве загрузчика. До конца 2012 года это утверждение также было справедливо для большинства промышленных реализаций EFI. И для того, чтобы в процесс загрузки добавить дополнительный слой защиты был создан режим Secure Boot. При включенном режиме Secure Boot для любой программы EFI, которая запускается прошивкой, в прошивке проверяется наличие криптографической подписи. Если криптографическая подпись отсутствует, не соответствует ключу, хранящемуся в энергонезависимой памяти компьютера, или указана в энергонезависимой памяти в черном списке, то прошивка отказывается выполнять программу. Конечно, это просто начало процесса; надежный загрузчик EFI должен продолжить процесс загрузки в безопасном режиме, что в конечном счете приведет тому, что безопасной будет сама операционная система. Автору вирусов потребовалось бы создать подписанный вирус, что более трудно в случае, если пользователи контролируют работу с системными клавишами. Таким образом, предварительно загружаемая вредоносная программа может быть заблокирована. Есть масса способов чтобы затем сделать что-нибудь не так, как надо, но режим Secure Boot обеспечивает, по меньшей мере, основу, на которой можно будет создать в целом безопасный компьютер, по крайней мере, в теории!

В описании режима Secure Boot в спецификациях UEFI не предлагается никаких механизмов создания доверительной сети для ключей этого режима. Если исходить только из спецификаций UEFI, то можно решить, что режим Secure Boot будет активироваться непосредственно там, где компьютеры будут использоваться; администраторам на местах следует подписывать загрузчики, которые они используют, защищаясь тем самым от авторов вредоносных программ. Но, фирма Microsoft включила в свою сертификационную программу Windows 8 требование, которое обязывает продавцов поставлять компьютеры с включенным режимом Secure Boot. На практике это означает, что производители должны добавлять на свои компьютеры ключи от фирмы Microsoft, и если производители не будут добавлять другие ключи, то работать будут только загрузчики, подписанные Microsoft.

К счастью, все не так плохо, как это может показаться. Microsoft имеет партнерские отношения с фирмой Verisign, регулирующей подписывание загрузчиков. Любой может заплатить $99 фирме Verisign для того, чтобы получить средства, позволяющие подписывать неограниченное количество двоичных файлов таким образом, что они будут работать, используя ключ Microsoft, или, точнее, ключ, который фирма Microsoft использует для подписывать сторонних двоичных файлов. Кроме того, фирма Microsoft требует, чтобы на компьютерах x86 и x86-64 предоставлялись средства, позволяющие полностью отключить режим Secure Boot, давая пользователям контроль над процессом загрузки. Пользователям ARM не так повезло, Microsoft требует, чтобы на системах ARM, на которых есть логотип Windows 8, режим Secure Boot нельзя было отключать.

Затравкой первоначального публичного обсуждения этих вопросов был в сентябре 2011 года блог Мэтью Дж. Гарретта (Matthew J. Garrett), разработчика из Red Hat. Большая часть первоначального обсуждения на веб-форумах и в других общественных местах была исключительно паническая, и даже через год я иногда вижу слишком нервные посты. Я призываю успокоиться; как описано в этой статье, есть, по крайней мере, три способа решения режима Secure Boot: его отключение, использование предварительно подписанного загрузчика или использование своих собственных ключей.

Отключение режима Secure Boot

Если вы не уверены, что режим Secure Boot улучшит безопасность вашей системы, вы можете полностью его отключить. Учитывая тот факт, что большинство вредоносных программ нацелено на Windows, этот подход является наиболее разумным на компьютерах, на которых не работают системы Windows. Для того, чтобы сделать это, вы должны хорошо ориентироваться в экранах настройки, имеющихся в вашей прошивке. К сожалению, место, где должны находиться параметры режима Secure Boot, или способ, как их можно вызывать, не стандартизованы; поэтому я не могу предоставить процедуру, которая будет работать на любом компьютере. Однако я могу описать параметры на одном компьютере, который у меня есть и в котором поддерживается режим Secure Boot: материнская плата ASUS P8H77-I. Эта плата поставляется с отключенным режимом Secure Boot, но, основываясь на моем практическом опыте, я могу представить, как эта плата будет поставляться в случае, если бы она использовалась на компьютере с предварительно установленной системой Windows 8. Исходя из этих предположений, вам для того, чтобы отключить режим Secure Boot, потребуется выполнить следующее:

Конечно, прошивка вашего компьютера, скорее всего, будет отличаться от моей. Лучше всего, если вы хотите отключить режим Secure Boot, вам следует изучить параметры прошивки (настроек setup-а) вашей собственной системы. В вашей инструкции эта информация может присутствовать, либо ее там может не быть. В случае с моей материнкой ASUS P8H77-I, в руководстве не упоминалось о параметрах режима Secure Boot; я должен был разобраться с этим методом проб и ошибок. Я слышал о ситуациях, которые как лучше, так и хуже, чем с моей материнкой ASUS. В «лучшей» ситуации был пункт меню, снабженный довольно очевидным названием Secure Boot и варианты настройки Enabled (Включить) и Disabled (Выключить). В «худшей» ситуации, о которой я слышал от других, при попытке отключить режим Secure Boot красным цветом выдавались страшные сообщения, либо прежде, чем вы смогли бы получить доступ к прошивке, требовалось загрузится в Windows, и запускать программу, работающую под Windows.

Использование подписанного загрузчика

Использование загрузчика, подписанного с ключом от Microsoft, является наиболее простым и прямым подходом к работе с режимом Secure Boot; однако, это также и самый ограничивающий подход. В зависимости от того, каким подписанным загрузчиком вы пользуетесь, вам всякий раз, когда вы пытаетесь загрузить не подписанный загрузчик, нужно вводить подтверждение, либо вы будет ограничены тем, какие операционные системы и ядра вы сможете загружать. По состоянию на начало 2013 года я знаю два подписанных загрузчика, предназначенных для использования с Linux: программа shim из системы Fedora (которая также используется в Ubuntu, SUSE и Sabayon) и загрузчик PreLoader фонда the Linux Foundation. На момент написания статьи имеется подписанная версия shim, но PreLoader все нужно реализовывать в виде подписанного двоичного файла. Я также описал, как проверять подпись в уже подписанном загрузчике для того, чтобы убедиться, что она именно та, которая должна быть.

Использование программы Shim из системы Fedora

Чтобы соответствовать целям режима Secure Boot, загрузчик Linux должен обеспечивать аутентификацию ядра Linux, а дистрибутив Linux должен обеспечить дополнительные меры безопасности в тех ядрах, которые им предлагаются. К сожалению, эти цели не в ладах с философией свободы открытого исходного кода и свободой пользователей, позволяющей управлять своими компьютерами. Поэтому решение Secure Boot для Linux должно балансировать между этими двумя целями. Это именно то, что делает программа shim, созданная в системе Fedora. Она делает это с помощью поддержки использования следующих трех различных типов ключей:

Примечание: Вы можете спросить, почему эти возможности нельзя добавить в существующий загрузчик, например, в GRUB 2. Против этого есть несколько причин. Одна из них относится непосредственно к вопросам договоренностей: Как пишет в блоге Джеймса Боттомли (James Bottomley) в этом блоге, Microsoft отказывается подписывать двоичные файлы, распространяемые под некоторыми открытыми лицензиями, в том числе под лицензией GPLv3, которая используется как в GRUB 2, так и в rEFInd. Другая причина относится к сфере практики: загрузчик, такой как GRUB 2, является большой программой, которую в случае обнаружения ошибок велика может потребоваться быстро заменить. Но процесс подписания с участием третьих лиц может замедлить процесс выпуска релиза, что поставщики дистрибутивов считают неприемлемым.

Весь смысл режима Secure Boot состоит в том, чтобы предотвратить попытки вредоносной программы получить контроль над компьютером. Поэтому, когда загрузка происходит с включенным режимом Secure Boot, система Fedora 18 ограничивает действия, которые некоторые пользователи Linux считают само собой разумеющимися. Например, должны быть подписаны модули ядра Linux, что затрудняет использование драйверов ядра сторонних производителей, таких как те, которые необходимы проприетарным видеодрайверам фирм Nvidia и AMD/ATI. Чтобы запустить локально-скомпилированное ядро, вы должны подписать его ключом МОК и зарегистрировать этот ключ МОК в системе. Общий объем подобных ограничений полностью зависит от тех, кто разработал и подписал загрузчик, запускаемый с помощью программы shim, и ядра, запускаемого с помощью этого загрузчика. Скорее всего, что в некоторых дистрибутивах будут поставляться ядра, которые будут сравнительно не сильно обременены добавлением ограничений безопасности.

В добавок к дистрибутиву Fedora (и, вероятно, в конце концов, дистрибутиву Red Hat Enterprise Linux), для дистрибутивов SuSE и Ubuntu было объявлено, что в них будет использоваться загрузчик him - на самом деле, в Ubuntu 12.10 уже используется ранняя версия, в которой не поддерживаются ключи MOK. (Анализ работы этой версии смотрите в этом блоге). В версиях этих дистрибутивов, выпущенных в конце 2012 года и в последующий период, должны быть доступны подписанные версии программы shim.

Примечание: Описанная здесь процедура утомительна, т.к. она требует самостоятельного подписывания загрузчиков и ядер. Как только в дистрибутивах появится программа shim, трудность этого процесса резко снизится. Если вам повезет, вы сможете использовать Ubuntu 12.10 или Fedora 18 с включенным режимом Secure Boot и не замечать отличие от установки без использования режима Secure Boot.

Если вы хотите сейчас использовать программу shim, то с практической точки зрения у вас есть три варианта: Вы можете запустить Ubuntu 12.10; вы можете запустить Fedora 18, или вы можете запустить подписанную версию, созданную Мэтью Гарретт (Matthew Garrett), добавить свой собственный ключ MOK и подписать любой двоичный файл, который захотите. К сожалению, прямо сейчас этот процесс все еще немного утомителен. Вкратце, он выглядит следующим образом:

1. Загрузите компьютер. Это само по себе может потребовать изучения. Вам, возможно, придется использовать восстановительный диск с включенным режимом Secure Boot, временно отключить режим Secure Boot, выполнить загрузку с помощью программы PreLoader, созданной фондом Linux Foundation, либо выполнить эту работу с помощью системы Windows. (Диск Ubuntu 12.10 может в режиме восстановления использовать первый из этих вариантов).
2. Если на вашем компьютере еще не установлен пакет OpenSSL, то установите его. (Как правило, она поставляется как пакет с именем openssl).
3. Загрузите и установите пакет sbsigntool. Ссылки на двоичные пакеты для различных дистрибутивов доступны на странице сервиса сборки OpenSUSE Build Service, или вы можете получить исходный код пакета, введя команду git clone git://kernel.ubuntu.com/jk/sbsigntool. (Процесс сборки пакета sbsigntool будет подробно описан позже в разделе «Генерация ваших собственных ключей»).
4. Скачайте программу shim с сайта Matthew J. Garrett или с сайта вашего дистрибутива в случае, если для него выпущена подписанная версия этой программы. (но, не используйте версию для дистрибутива Ubuntu 12.10; как было отмечено ранее, ее недостаточно для использования ключей MOK). Подписанная версия shim из дистрибутива Fedora 18 должна работать нормально с другими дистрибутивами, но если вы загружаете не систему Fedora 18, вы не получите от этого никаких преимуществ; если вы пользуетесь двойной загрузкой и загружаете другой дистрибутив, единственная причина этого — отдельно выполнить какой-нибудь из описанных здесь шагов.
5. Установите программу shim обычным образом так, как это описано в статье «Установка загрузчика EFI».
6. В тот же самый каталог, где находится shim.efi, установите программу MokManager.efi (которая поставляется вместе с shim). Двоичный файл MokManager.efi управляет вашими ключами MOK, поэтому если эта программа не будет установлена, вы, в результате, не сможете добавить свои собственные ключи.
7. Создайте каталог для хранения ваших собственных ключей MOK и перейдите в этот каталог.

8. Введите следующие две команды для создания своих открытых и закрытых ключей:

   $ openssl req -new -x509 -newkey rsa:2048 -keyout MOK.key -out MOK.crt \
     -nodes -days 3650 -subj "/CN=Your Name/"
   $ openssl x509 -in MOK.crt -out MOK.cer -outform DER
   

   Если вы использовали параметр --localkeys скрипта install.sh из пакета rEFInd, то генерации ключей не требуется, так как эти ключи уже созданы и хранятся в каталоге /etc/refind.d/keys/ под названием refind_local.*.

   Замените параметр Your Name на свое имя или другие идентифицирующие характеристики, а также настройте время действия сертификата (устанавливается с помощью параметра -days) так, как считаете нужным. Если вы не укажите параметр -nodes, то программа предложит вам ввести ключевую фразу для дополнительной безопасности. Запомните ее, поскольку она вам будет нужна при подписывании ваших собственных двоичных файлов. Результатом будет файл закрытого ключа (MOK.key), который является очень важным, поскольку он необходим при подписывании двоичных файлов, и два открытых ключа (MOK.crt и MOK.cer), которые можно использовать для проверки подлинности подписи в двоичных файлов. Оба файла с открытыми ключами эквивалентны, но они используются в различных инструментальных средствах — в программе sbsigntool для подписывания двоичных файлов используется ключ MOK.crt, а программа MokManager добавляет ключ MOK.cer.

9. Скопируйте файл MOK.cer в каталог, где его сможет прочитать ваш загрузчик EFI, например, загрузчик ESP вашего компьютера.

   Примечание: Версия 0.2 программы shim не может напрямую запускать ядра Linux. Вам все еще нужно использовать shim в сочетании с загрузчиком, например, старой версией GRUB, GRUB 2 или ELILO. Поскольку gummiboot запускает Linux с помощью системных вызовов EFI, он не будет работать с программой shim. То же самое касается программы rEFInd версий 0.4.7 и более ранних, но начиная с версии 0.5.0 rEFInd может «общаться» с программой shim и использовать ее для аутентификации загрузчиков, которые запускаются.

10. Перейдите в каталог, где находится двоичный модуль, который вы хотите подписать с помощью вашего ключа МОК
11. Подпишите ваш двоичный модуль — наберите команду sbsign --key MOK.key --cert MOK.crt --output binary-signed.efi binary.efi, указав пути к ключам и имена двоичных модулей.
12. Скопируйте нужный загрузчик в каталог программы shim и поменяйте его название на grubx64.efi. Конечно, в случае, если вы не пользуетесь загрузчиком GRUB, это может показаться странным, но пока просто так сделайте. Если надо, то настройте загрузчик.
13. Перезагрузитесь. Если повезет, вы увидите простой текстовый пользовательский интерфейс с пометкой Shim UEFI key management. Это программа MokManager, которая запускается программой shim в случае, если ваш загрузчик не прошел проверку из-за того, что для него еще не был получен ключ.

14. Нажмите клавишу со стрелкой, указывающей вниз, и для того, чтобы выбрать вариант Enroll key from disk (Взять ключ с диска), нажмите клавишу Enter. Экран будет очищен и вам будет предложено выбрать ключ, например, следующим образом:

    

15. Каждая из строк с длинной неуклюжей записью представляет собой раздел диска. Выберите одну из них и вы увидите список файлов. Продолжайте выбирать подкаталоги до тех пор, пока не найдете файл MOK.cer, созданный и скопированный ранее в раздел ESP.
16. Выберите файл MOK.cer. Программа MokManager запросит подтверждение того, что вы хотите зарегистрировать ключ. Подтвердите это.
17. Выйдите из всех каталогов, в которые вы зашли, и вернитесь в главное меню программы MokManager.
18. В главном меню выберите вариант Continue boot (продолжить загрузку).

После этого компьютер может загрузить свою используемую умолчанию ОС, может перезагрузиться или, возможно, даже может зависнуть. Тем не менее, когда вы перезагрузите компьютер, загрузчик, который вы установили с именем grubx64.efi, должен запуститься в режиме Secure Boot. В зависимости от своих возможностей, он может загрузить любое ядро, которое он бы загрузил в случае, если бы режим Secure Boot был бы отключен, запустить только те загрузчики, которые подписаны ключами Secure Boot данной платформы, или запустить программы EFI или ядра, подписанные с обычными ключами Secure Boot или вашим собственным ключом МОК.

В будущем, использовать программу shim будет легче, поскольку в дистрибутивах будут поставляться предварительно подписанные загрузчики, что устранит необходимость выполнения большинства этих шагов. Тем не менее, если вы хотите подписать свои собственные двоичные модули, вы все равно должны установить программное обеспечение, позволяющее подписывать программы, добавить свой собственный ключ через программу MokManager, и подписать двоичные файлы, которые вы создали самостоятельно или получили из другого источника.

Проверка ваших загрузчиков

Самый простой способ убедиться, что ваши загрузчики подписаны должным образом, это попытаться с их помощью загрузиться. Тем не менее, вы, возможно, захотите проверить их перед перезагрузкой хотя бы просто для того, чтобы убедиться, что они будут загружаться. Чтобы сделать это, вам нужна копия открытого ключа, который вы создали ранее с помощью программы openssl. Если двоичный модуль был подписан разработчиком вашего дистрибутива, вам нужна копия открытого ключа для этого дистрибутива. Если у вас есть ключ в виде сертификата X509 (обычно с расширением .crt), то вы можете проверить двоичный модуль с помощью команды sbverify:

$ sbverify --cert keys/refind.crt refind_x64.efi
Signature verification OK

В этом примере показана успешная проверка двоичного файла refind_x64.efi с помощью открытого ключа keys/refind.crt. Неудачи, как правило, сопровождаются сообщениями, в которых указывается, что что-то пошло не так, при этом часто используются технические термины. Как правило, двоичные модули либо не подписаны, либо они подписаны ключом, отличным от того, открытую копию которого вы пытались использовать.

Если вы пытаетесь проверить двоичный модуль, который был подписан поставщиками дистрибутива, вам нужна их копия открытого ключа. Эти ключи часто представляются в составе исходного кода их копий программы shim, так что поищите ключи там. Я также предоставляю несколько ключей в подкаталоге refind/keys вместе с моем менеджером загрузки rEFInd. Проблема в том, что большинство доступных файлов ключей представлены в формате DER (с расширением .cer или .der), но вам нужен текстовый файл PEM (с расширением .crt). Вы можете конвертировать из одного формата в другой с помощью программы openssl:

$ openssl x509 -in fedora-ca.cer -inform der -out fedora-ca.crt

В этом примере файл fedora-ca.cer преобразуется в файл fedora-ca.crt, который вы можете использовать для проверки подлинности двоичных файлов, подписанных поставщиками дистрибутива Fedora.

Использование загрузчика PreLoader от Linux Foundation

Предложенное фондом Linux Foundation решение проблемы режима Secure Boot, известное как загрузчик PreLoader, обладает такими же возможностями, что и программа shim, но оно также отличается от последней следующими двумя ключевыми аспектами:

С практической точки зрения, у PreLoader есть преимущество в случае, если вы хотите запустить не подписанный загрузчик (например, со старого дистрибутива Linux), либо если вы хотите распространять загрузочный образ системы, но у вас нет средств для оплаты вашего собственного ключа для подписи. Если вы не сильны с технической точки зрения, то в таких случаях загрузчик PreLoader особенно полезен, поскольку вам не нужно иметь дело с подписыванием ключей так, как это описано для случая применения программы shim. Если в вашем дистрибутиве подписаны загрузчики и/или ядра, то вам лучше отказаться от использования shim. Если загрузчики вашей системы (возможно, в том числе ее ядра) меняются редко и если вы готовы подписывать ключи, то любая из программ будет работать одинаково хорошо.

Чтобы использовать загрузчик PreLoader, выполните следующие действия:

1. Загрузите компьютер. Как и в случае с установкой shim, этот шаг может потребовать дополнительного изучения. Возможно, вам придется временно отключить режим Secure Boot, использовать восстановительный диск с включенным режимом Secure Boot, либо выполнить эту работу из Windows.
2. Скачайте подписанный вариант загрузчика PreLoader с его собственного сайта.
3. Установите PreLoader так, как это описано на странице установка загрузчика EFI (EFI Boot Loader Installation). Возможно, вы захотите установить его у себя в том каталоге, где находится загрузчик, используемый по умолчанию.
4. Скопируйте файл HashTool.efi из пакета PreLoader в тот же самый каталог, где находится двоичный модуль PreLoader.
5. В тот же самый каталог, где находится загрузчик PreLoader, поместите загрузчик, используемый по умолчанию, и переименуйте его в loader.efi.
6. Перезагрузитесь и, при необходимости, выберите загрузчик PreLoader в качестве варианта загрузки. PreLoader должен запуститься, но он будет жаловаться, что не может запустить loader.efi. Затем он запустит программу HashTool, являющуюся программой, используемой загрузчиком PreLoader для запоминания информации (хэшей) о программах, для которых подтвердили разрешение на запуск.
7. В HashTool, выберите вариант Enroll Hash (Записать в хэш).
8. Найдите и выберите файл программы loader.efi. HashTool запросит подтверждение; ответьте Yes.

   Примечание: К сожалению, программа HashTool имеет очень серьезное ограничение: она может запоминать хэши только тех двоичных файлов, которые хранятся на диске, с которого эта программа запущена. Таким образом, вам, возможно, потребуется либо скопировать программу HashTool на диск, на котором хранятся ваши исполняемые файлы, либо скопировать двоичные файлы на диск, на котором хранится программа HashTool. После того, как вы запомните хэш двоичного файла, он будет работать при запуске из любого места.

9. На практике теперь вам нужно будет повторить два предыдущих шага для каждого загрузчика, который вы хотите запускать. Например, если вы для запуска ядра Linux используете загрузчик gummiboot или rEFInd, вам потребуется выбрать каждый из них для запоминания. Но этого делать не нужно, если для запуска ядра Linux вы используете загрузчик ELILO или GRUB, однако вам, возможно, потребуется добавить хэш-информацию для тех загрузчиков, которые запускаются с помощью GRUB.
10. Выберите в главном меню HashTool вариант Exit (Выйти) или Reboot System (Перезагрузка системы).

В этот момент ваш компьютер должен перезагрузиться в ваш обычный загрузчик и, если вы зарегистрировали ядра и последующие загрузчики с помощью HashTool, то у вас у должна быть возможность запускать эти двоичные файлы так, как если бы они были подписаны ключом Secure Boot вашей платформы. Такая регистрация является важным пунктом. Если вы для запуска ядер Linux пользуетесь загрузчиком rEFInd или gummiboot, то вам необходимо регистрировать каждое новое ядро, когда вы (или системы пакетов вашего дистрибутива) его устанавливаете. Этот факт также означает, что у вас должна быть возможность запуска HashTool. ELILO это сделать не может, но вы можете для того, чтобы иметь возможность запускать программу HashTool, настроить rEFIt, rEFInd, gummiboot, GRUB Legacy и GRUB 2. На самом деле, загрузчик rEFInd версии 0.6.7 и последующих версий распознает двоичным модуль HashTool.efi и предоставляет на главном экране для него тег.

На самом деле загрузчик PreLoader использует за кулисами тот же список ключей MOK, что и программа shim; просто PreLoader использует его для хранения хэш-значений программ, а не их ключей. Вполне возможно, что в будущем программа shim и PreLoader будут приобретать черты друг друга. Однако на данный момент, если вы хотите использовать ключи, вы должны пользоваться программой shim, а если вы хотите использовать хэши не подписанных двоичных файлов, вы должны пользоваться загрузчиком PreLoader. Теоретически вам должно быть достаточно иметь возможность использовать один из этих инструментов с тем, чтобы запустить другой для последующего запуска вашего загрузчик, и это должно позволить вам использовать для проверки подлинности либо ключи, либо хэш-значения. Однако, я эту возможность не пробовал.

---

Продолжение статьи: Замена ключей в вашей прошивке.

---

---