Ключи от вашего Linux — у Microsoft. Как так вышло, что безопасность открытой ОС зависит от ее главного конкурента

Архитектура Arm за последние годы превратилась из нишевой в массовую: смартфоны, одноплатные компьютеры, сетевое оборудование и даже серверы всё чаще работают именно на ней. Linux здесь занимает центральное место, однако привычная для x86-мира связка UEFI и Secure Boot пока остаётся экзотикой.

В сегменте ПК и серверов стандарт UEFI окончательно вытеснил BIOS ещё к началу 2010-х, а Secure Boot закрепился после решения Microsoft сделать его обязательным для сертификации Windows 8. Тогда сообщество Linux столкнулось с проблемой: системы на ядре Линукс не могли загружаться на машинах с активированной проверкой подписи. Решением стал компонент shim, подписанный Microsoft, который позволял добавлять собственные ключи и доверенные сертификаты. Благодаря ему Fedora, Ubuntu, openSUSE и другие дистрибутивы научились безболезненно устанавливаться на ПК с включённым Secure Boot.

На стороне Arm ситуация выглядит сложнее. Причина в том, что сама компания Arm лишь выпускает архитектурные спецификации, а реализацией занимаются десятки независимых производителей чипов. У каждого из них собственная прошивка, зачастую несовместимая с альтернативами. Нередко эта прошивка вовсе не поддерживает UEFI, что автоматически исключает Secure Boot.

На практике универсальным инструментом стала загрузочная программа u-boot , которая обеспечивает соответствие спецификации UEFI и может проверять подписи исполняемых файлов. Однако в отличие от x86-устройств, где в прошивке уже предустановлены ключи Microsoft, u-boot поставляется без каких-либо доверенных сертификатов. Пользователю приходится самостоятельно создавать и внедрять ключи, а затем подписывать загружаемые модули ядра или использовать промежуточный загрузчик вроде grub2, чтобы облегчить процесс.

Существуют и варианты с цепочечной загрузкой, когда u-boot передаёт управление аппаратной реализации UEFI. На Raspberry Pi 3 и 4 это уже работает, а новые чипы RK3588 считаются перспективными в плане поддержки. Такой подход даёт привычный интерфейс, знакомый пользователям ПК, однако зависит от доступности конкретной прошивки для конкретного устройства. В любом случае, если используется Secure Boot через u-boot, загружаться будут только корректно подписанные бинарные файлы.

На уровне самих дистрибутивов Linux картина выглядит неоднородной. Debian, Ubuntu и SUSE на Arm64 умеют устанавливаться с включённым Secure Boot и предустановленными сертификатами Microsoft — по сути, поведение повторяет x86. Но у проектов, связанных с Red Hat, картина иная.

Fedora распространяет shim без подписи Microsoft, из-за чего установка невозможна при активном Secure Boot. В RHEL shim подписан, но не ключом Microsoft, а внутренним ключом Red Hat, и такая схема тоже блокирует работу «из коробки».

На практике пользователям приходится отключать Secure Boot на время установки, а затем вручную добавлять собственные ключи и делать доверенными либо shim, либо grub2. Интересно, что CentOS Stream и Alma Linux, основанные на кодовой базе Red Hat, уже содержат Microsoft-подписанный shim, а в сообществе обсуждается возможность аналогичного шага для Fedora.

В итоге можно сказать, что опыт, накопленный в x86-мире, позволяет адаптировать UEFI Secure Boot и на Arm64, но главная сложность кроется в аппаратной части. Не все устройства поставляются с прошивкой UEFI, а внедрение её постфактум возможно далеко не всегда. Пока наиболее реальный путь — полагаться на u-boot с функциями UEFI и механикой Secure Boot либо использовать цепочечную загрузку к специализированным реализациям на базе проекта EDKII.