Secure Boot в Arch Linux в 2026: UKI без замены заводских ключей

Разбор новинки простыми словами: что это, кому нужно и брать ли.

Показывает, что базовый Secure Boot на Arch можно включить без пересборки цепочки PK/KEK/DB и без сертификатов Microsoft — достаточно добавить свой ключ в DB и повесить автоподпись UKI на хук mkinitcpio, что снимает риск сломать загрузку при обновлении ядра.

Связанные услуги: каталог, AI Boost Team, стать клиентом.

Что произошло

На Хабре появился разбор, который закрывает давнюю неловкость Arch Linux: Secure Boot можно включить, не переписывая цепочку ключей в прошивке и не привязываясь к сертификатам Microsoft. Автор под ником pluviusAestivus прошёл маршрут на материнской плате ASUS Prime 790-P и выложил его пошагово. Заявленное время на прочтение — четыре минуты, охват на момент выгрузки — 2.4K читателей.

Для владельца бизнеса это звучит как техническая мелочь. На деле речь о том, можно ли поставить машину на Linux и при этом не иметь дыры в загрузочной цепочке, которую любой аудит назовёт первой. Arch здесь плохой пример для парка: дистрибутив не настраивает Secure Boot по умолчанию, при установке его обычно отключают. Значит, типовая рабочая станция разработчика или сборочный стенд живёт с выключенной проверкой подписи загрузчика. Годами это списывали в «особенности дистрибутива».

Arch Linux, в отличие от многих дистрибутивов, не настраивает Secure Boot по умолчанию.

Что именно предлагают сделать

Маршрут строится вокруг Unified Kernel Image — одного файла, внутри которого лежат ядро, initramfs и сопутствующие данные. Такой образ грузится прямо из прошивки, без GRUB и systemd-boot. Отсюда и логика: подписывать нужно ровно один артефакт, а не три по отдельности.

Порядок действий в руководстве такой:

1. Бэкап ключей UEFI. Флешка с FAT, раздел Secure Boot в прошивке, пункт сохранения всех ключей. Копию с флешки — в надёжное место: заводские ключи всегда можно загрузить обратно.
2. Свой ключ. Пакет sbsigntools тянет за собой openssl. Ключ генерируется на rsa:4096 с sha256 и сроком действия 3650 дней, лежит в /etc/secureboot с правами 700 на каталог и 600 на приватный db.key. Публичная часть дополнительно выгружается в DER — db.cer, его прошивка и съест.
3. Добавление в DB. Файл db.cer с флешки добавляется в раздел DB через интерфейс UEFI. Заводские PK, KEK и DB остаются на месте, к ним просто дописывается новый участник. Проверка — sbctl list-enrolled-keys: в списке DB появляется строка «My Arch Linux Secure Boot».
4. Автоподпись. Скрипт в /etc/initcpio/post проверяет образ через sbverify и при отсутствии подписи подписывает его через sbsign. Хук срабатывает после сборки образа, то есть после каждого обновления ядра.

Четвёртый пункт — главный. Разовая подпись ядра это ловушка: первое же обновление приносит неподписанный образ, Secure Boot его отвергает, машина не грузится, а виноватым выходит «Linux». Автоподпись на хуке mkinitcpio снимает именно этот риск.

Тот же самый хук теперь будет срабатывать после каждого pacman -Syu, так что каждое новое ядро будет подписываться автоматически.

Чем это отличается от двух привычных путей

На вики Arch описаны три способа, и новичок в них тонет. Разница между ними не в сложности, а в том, что вы соглашаетесь менять.

sbctl с enroll-keys. Утилита предлагает пересобрать всю цепочку PK → KEK → DB под себя, переставив сертификаты Microsoft заново. Своя цепочка строже, но операция рискованная — страница вики пестрит предупреждениями в красных рамках. Плюс получается, что Linux-утилита отвечает за установку сертификатов Windows. Флаг, который «включает дефолтные ключи», на деле означает «переписать, добавив заводские», а не «не трогать».

shim. Рабочий и предсказуемый вариант, но он завязан на сертификаты Microsoft. Для части компаний это идеологический вопрос, для части — вопрос независимости от чужого реестра доверия.

Ключ в DB через UEFI. Третий путь, выбранный в разборе. Принцип — минимальное вмешательство: добавить только нужное, не трогать то, что уже работает.

Я решил полагаться на принцип минимального вмешательства: добавить только то, что нужно, и не трогать то, что уже работает. То есть, просто добавить новый ключ Arch Linux в существующий набор ключей.

Факт → что это значит

Кому это нужно и где применить

Первая аудитория — не энтузиасты, а те, кто держит парк Linux-машин в контуре с требованиями к защите загрузки. Небольшая студия, где пять-десять рабочих станций разработчиков, часто живёт без Secure Boot просто потому, что «на Arch он сложный». После такого разбора отговорка исчезает.

Вторая — точечные машины с повышенными требованиями: касса, терминал, станок с Linux-контроллером, стенд сборки. Здесь важна не столько криптография, сколько предсказуемость: загрузочный образ проверяется, а обновление ядра не превращается в поход к железу с флешкой.

Третий сценарий — привычка к минимальному вмешательству в прошивку. Если в компании есть правило «не трогать вендорские ключи без необходимости», третий путь из вики оказывается единственным, который правило соблюдает. Автор честно оговаривает уровень: задача — базовая защита загрузочного образа, сопоставимая с тем, что Windows даёт по умолчанию, а не «непробиваемый Secure Boot».

Где подвох

Ограничение номер один — железо. Нужен интерфейс UEFI с ручным добавлением ключа в DB. У ASUS Prime 790-P он есть, у большинства современных плат похожий функционал тоже, но «большинство» — не «все». Проверять надо до того, как выключили Secure Boot для установки.

Дальше — режим загрузки. Разбор написан под UKI, который грузится прямо из прошивки. Для GRUB или systemd-boot это уже другая настройка, и её в материале нет. Если в парке смесь загрузчиков, придётся считать отдельно по каждой группе машин.

И третье, самое скучное. Ключ, лежащий на диске, — это единственная точка отказа. Потеряли /etc/secureboot, потеряли бэкап — следующее обновление ядра оставит вас с неподписанным образом и включённой проверкой. Бэкап ключей прошивки, бэкап приватного ключа и копия текущего arch-linux.efi перед первой проверкой — не перестраховка, а обязательный минимум.

Брать или подождать

Брать, если у вас Arch с UKI и прошивка умеет добавлять ключ в DB вручную. Работы на вечер, откат — флешка с ключами. Для одной-двух машин это дешевле, чем разбираться с sbctl и его предупреждениями.

Подождать, если загрузка идёт через GRUB или systemd-boot, если плата не даёт трогать DB или если Secure Boot у вас уже настроен и работает. Переделывать работающую схему ради более красивой идеи — плохая сделка.

Не брать как политику парка без своего человека, который умеет читать вывод mkinitcpio. Автоподпись — это скрипт, а скрипт кто-то должен сопровождать при обновлениях системы.

Вердикт

Материал делает одну полезную вещь: превращает «Secure Boot на Arch — это больно» в конкретный список из четырёх шагов с понятной ценой риска. Ценность здесь не в криптографии, а в разделении ответственности: система сама отвечает за свою подпись, прошивка остаётся при своих ключах. Кто хочет строгости — идёт в sbctl. Кто хочет независимости от Microsoft — идёт в shim. Кто хочет минимум вмешательства и предсказуемый откат — идёт этим путём.

FAQ

Это заменит полноценную настройку Secure Boot по вики?

Нет. Это базовый уровень: подпись загрузочного образа и проверка его прошивкой. Полная цепочка со своими PK и KEK даёт больше контроля, но и больше способов сломать загрузку.

Что произойдёт после обновления ядра?

Хук пересоберёт и подпишет UKI автоматически. Ручных действий не требуется — ровно это и проверяют командой mkinitcpio -P до включения Secure Boot.

Можно ли откатиться?

Да, если сделан бэкап ключей прошивки. Ключи с флешки загружаются обратно через тот же раздел UEFI.

Нужен ли сертификат Microsoft?

При таком способе — нет. Он нужен для пути через shim; здесь доверие даёт ваш собственный ключ в DB.

Что сделать на этой неделе

Проверьте на одной машине, есть ли в прошивке ручное добавление ключа в DB. Если есть — сделайте бэкап ключей на флешку и положите его туда, где не потеряется. Дальше решение принимается за вечер, а не за квартал.