Мэтью Гаррет (Matthew Garrett), один из разработчиков ядра Linux из компании Red Hat, представил план реализации полного комплекса средств для поддержки режима безопасной загрузки UEFI в следующем выпуске Linux-дистрибутива Fedora. Целью обеспечения поддержки является предоставление из коробки возможности установки Fedora Linux на компьютеры, укомплектованные операционной системой Windows 8. Напомним, что для сертификации оборудования на совместимость с Windows 8, компания Microsoft требует обязательной активации по умолчанию режима безопасной загрузки UEFI, блокирующего загрузку систем, не имеющих заверенной цифровой подписи.
Возможность работы Fedora в режиме безопасной загрузки UEFI будет охватывать как технические стороны, так и организационные меры. Режим безопасной загрузки подразумевает, что все компоненты, взаимодействующие с оборудованием и обеспечивающие загрузку ОС, должны иметь цифровую подпись, в том числе загрузчик, ядро ОС, загружаемые ядром драйверы и все модули ядра. При этом возникает ряд проблем с цифровыми подписями. У создателей альтернативных систем имеется два пути получения таких подписей - заверение подписи у официально аккредитованной организации или самостоятельное создание цифровой подписи.
В первом случае возникает несовместимость с лицензией GPLv3 (запрет тивоизации), под которой распространяется GRUB2, и требуется заверение подписи при изменении каждого из загружаемых компонентов (например, при пересборке модуля ядра нужно получить для него цифровую подпись, также затрудняется использование проприетарных драйверов). Во втором случае наблюдаются существенные для рядового пользователя трудности, связанны с необходимостью изменения конфигурации прошивки (отключению UEFI) или ручной загрузкой в прошивку своих ключей (интерфейс по загрузке ключей никак не стандартизирован и может быть реализован производителем на своё усмотрение). По мнению Гаррета недопустимо заставлять пользователя дополнительно разбираться в настройке прошивки при желании использовать Fedora Linux.
Тем не менее, несмотря на кажущуюся безвыходность сложившейся ситуации, разработчики Fedora нашли достаточно интересное компромиссное решение. На первом этапе загрузки будет использован специальный дополнительный загрузчик, заверенный ключом от компании Microsoft. После получения управления данный загрузчик передаст управление штатному загрузчику GRUB 2, который, как и ядро и все загружаемые в дальнейшем модули, будет подписан собственным ключом проекта Fedora. Ключ для создания первичного загрузчика будет сформирован при помощи сервиса Microsoft, позволяющего за 99$ (ключ делегирует Verisign) получить доступ к формированию неограниченного числа подписей для исполняемых файлов.
Заверение первичного загрузчика ключом Microsoft является оптимальным вариантом, который позволит обеспечить совместимость со всем оборудованием. Получение собственного заверяющего ключа для проекта Fedora потребовало бы к необходимости согласования с каждым OEM-производителем вопроса включения проверочного ключа Fedora в прошивку, что неизбежно привело бы появлению оборудования, которое не поддерживает Fedora. Кроме того получение подобного ключа дало бы несправедливое преимущество по отношению к другим дистрибутивам Linux. Получение ключа для Linux вцелом потребовало бы существенных финансовых затрат (миллионы долларов) и значительного времени на создание и поддержание специальной инфраструктуры для координации формирования подписей для различных дистрибутивов, которая смогла бы гарантировать безопасность корневого ключа.
В рамках реализации плана поддержки режима безопасной загрузки UEFI планируется внести изменения в различные компоненты дистрибутива. В GRUB 2 внесены такие изменения, как блокирование загрузки модулей на лету для обеспечения целостности процесса безопасной загрузки. Ядро Linux будет собрано с поддержкой проверки цифровых подписей модулей и драйверов. Так как спецификация требует обязательной проверки всех компонентов взаимодействующих с оборудованием, при использовании режима безопасной загрузки UEFI функциональность ядра будет немного урезана, например, будет заблокирована поддержка прямого обращения к памяти устройств из пространства пользователя, т.е. для работы с графической картой обязательным будет использование DRM-драйвера, работающего на уровне ядра (при загрузке в обычном режиме данное ограничение не будет действовать). Процесс формирования подписей для стандартных модулей и драйверов будет автоматизирован, вопросы организации формирования подписей для сторонних модулей ядра (например, virtualbox, драйверы nvidia и AMD Catalist) и для модулей пересобранных из исходных текстов пока находятся на стадии обсуждения.
Изначально предлагалось подготовить специальный инструментарий, который бы позволил пользователям формировать подписи для своих вариантов ядра, модулей и загрузчиков, но создание такого инструментария сопряжено с необходимостью решения проблемы доступа к заверяющему подписи ключу, который необходимо держать в секрете. Возможно данная проблема будет решена через создание специального закрытого сервиса. Другим, более приемлемым, вариантом в такой ситуации является генерация пользователем собственного ключа, добавление его в UEFI-прошивку и пересборка начального загрузчика с новым ключом, после чего новый ключ можно будет использовать для формирования локальных цифровых подписей (заверенные ключом Fedora компоненты не придётся переподписывать, так как новый ключ будет определён как доверительный в прошивке).
Поддержка режима безопасной загрузки UEFI ожидается только для x86-систем, для систем на базе архитектуры ARM с предустановленным Windows 8 использование Fedora принципиально поддерживаться не будет. Технически, реализуемая поддержка безопасной загрузки UEFI позволяет организовать установку Fedora на таких системах, но так как компания Microsoft явно запрещает предоставление любых способов отключения безопасной загрузки или добавления своих ключей, разработчики Fedora могут обеспечить работу только заверенных дистрибутивных компонентов, использовать пересобранные или сторонние компоненты без покупки ключа у Microsoft будет невозможно.
