Пользователи Linux могут столкнуться с еще одним препятствием, связанным с Secure Boot, когда 11 сентября истечет срок действия ключа, подписанного Microsoft, который используется многими дистрибутивами для поддержки функции безопасности на основе микропрограммы, в результате чего пользователи окажутся в зависимости от дистрибутивов от OEM-производителей, а системы, возможно, не получат необходимое обновление микропрограммы.
Начнем с краткого обзора того, что такое Secure Boot. Это часть Unified Extensible Firmware Interface (UEFI), которая заменила Basic Input/Output System (BIOS) в современных системах. (Хотя энтузиасты и производители по-прежнему часто называют его BIOS.) В статье базы знаний Microsoft об этой функции объясняется, что она «является стандартом безопасности, разработанным членами индустрии ПК, чтобы гарантировать, что устройство загружается только с помощью программного обеспечения, которому доверяет [производитель]».
Производители должны убедиться, что «база данных подписей (db), база данных отозванных подписей (dbx) и база данных ключей регистрации (KEK)» «хранится в энергонезависимой памяти микропрограммы (NV-RAM) на этапе производства». Затем производитель «блокирует прошивку от редактирования, за исключением обновлений, подписанных правильным ключом, или обновлений, выполненных физически присутствующим пользователем, который использует меню прошивки, а затем генерирует ключ платформы (PK) [...], используемый для подписания обновлений KEK или отключения Secure Boot».
Ни одно из этих требований не препятствует установке операционных систем, отличных от Windows. Однако большинство устройств поставляются с предустановленной ОС Microsoft, а это означает, что для установки чего-либо другого сначала необходимо отключить Secure Boot. (Это предполагает, что пользователь знает о существовании UEFI/BIOS, умеет им пользоваться и знает, как изменить настройки загрузки). Тогда возникает вопрос, позволяет ли установленная ОС повторно включить Secure Boot после того, как она была установлена вместе с Windows или вместо нее.
Это ставит дистрибьюторов операционных систем перед выбором: полностью отказаться от поддержки Secure Boot; ожидать, что пользователи будут генерировать и подписывать свои собственные ключи; или найти способ использовать контролируемые Microsoft db, dbx и KEK для включения Secure Boot в своих собственных системах. NetBSD, OpenBSD и некоторые из их более эзотерических аналогов остановились на первом варианте, в то время как некоторые дистрибутивы Linux и FreeBSD выбрали третий, используя «shim» для построения своей поддержки Secure Boot поверх инфраструктуры Microsoft.
Теперь, когда мы с этим разобрались: LWN сообщил (paywall), что Microsoft перестанет использовать истекающий ключ для подписи shim в сентябре. «Но заменяющий ключ, доступный с 2023 года, может не быть установлен на многих системах; что еще хуже, он может потребовать от поставщика оборудования выпуска обновления для системной прошивки, что может произойти, а может и нет», — сообщает LWN. «Похоже, что подавляющее большинство систем не пострадает от этой перестановки, но это может потребовать дополнительных усилий от дистрибьюторов и пользователей».
В отчете говорится, что производители могут добавить поддержку нового ключа в полном обновлении прошивки или путем обновления базы данных KEK. Первый вариант предполагает, что производители будут заинтересованы в распространении обновления прошивки для широкого спектра продуктов, чтобы небольшой процент их пользователей мог использовать Secure Boot с ОС, отличной от Windows; второй вариант — это непроверенный механизм, который не гарантирует работу на всех устройствах. Оба варианта, по всей видимости, оставят по крайней мере некоторых людей в поиске решения самостоятельно.
Все это для функции с многочисленными уязвимостями, которые были как широко распространенными (см.: BootHole, BlackLotus, оба PDF-файла), так и ограниченными материнскими платами определенных производителей (см.: MSI, Gigabyte). Устранение недостатков системы также не всегда приветствуется, поскольку они использовались для установки Windows 11 на системах без Trusted Platform Module (TPM) 2.0, поскольку пользователи не хотят оставаться на Windows 10, но и не хотят покупать новое оборудование.
Легко понять привлекательность Secure Boot — усложнение установки bootkit должно быть явным плюсом. Однако надвигающаяся проблема с истекающим сроком действия ключа — это лишь последняя из серии неудобств, которые побуждают людей либо оставаться на Windows, либо полностью отключить Secure Boot. В настоящее время многие люди выбирают первое, но будет ли это продолжаться, когда популярность других платформ будет расти по мере угасания Windows 10? И готова ли Secure Boot в ее нынешнем виде к таким изменениям?
Оригинал
Уникальность
