В последней части цикла я постараюсь рассказать о новшествах стандарта UEFI 2.5, первые реализации которого должны появиться примерно через полгода на новых платах с процессорами Intel Skylake и AMD R-Series. В первой и второй частях речь шла о более низкоуровневых (и потому менее интересных неспециалистам) стандартах PI 1.4 и ACPI 6.0, здесь же поговорим об изменениях, напрямую влияющих на работу ОС и возможности загрузки по сети. Если вы хотите узнать, что нового в UEFI 2.5, почему PXE уходит в прошлое и зачем UEFI поддержка WiFi и Bluetooth — искренне прошу под кат.В отличие от своих низкоуровневых собратьев, стандарт UEFI развивается в очень высоком темпе, и с момента выпуска предыдущей версии 2.4 Errata C не успело пройти и полугода. Изменений масса, поэтому я постараюсь отфильтровать мелкие и не слишком важные, вроде исправлений опечаток и правок некоторых частей текста, допускавшего двоякое толкование. Если вас это не устраивает и вам нужны все изменения до последней запятой — оригинал документа к вашим услугам.
Как и в предыдущей части, я разделил изменения на группы, чтобы не описывать каждый новый протокол по нескольку раз. Поехали!
ESRT и новый способ обновления прошивки
В UEFI 2.5 вводится новая необязательная таблица ESRT, при помощи которой UEFI может сообщить операционной системе типы и версии имеющихся компонентов прошивки, а также статус их последнего обновления.С использованием этой таблицы ОС может инициировать обновление не только всей прошивки целиком (как это было практически на всех произведенных материнских платах с UEFI), но и конкретных независимых друг от друга компонентов, таких как VBIOS/GOP-драйвер, Raid-драйвер, UNDI-драйвер и т.п. Для инициации обновления будет использован стандартный механизм UEFI Capsule Update, а само обновление будет произведено при следующей загрузке. Файлы с обновлениями компонентов защищены от модификации ЭЦП на основе RSA2048/SHA256 и могут быть выпущены только обладателями закрытого ключа, поэтому прошивать модифицированные образы (и не важно, выполнена ли модификация злобным вирусом или опытным пользователем) с помощью Capsule Update не выйдет, так что программатор по прежнему наше всё.
ESRT также будет использоваться для доставки обновлений через подсистему обновления компонентов ОС (т.е. Windows Update для Win10 и fwupd для Linux).
SysPrep, OS Recovery и Platform Recovery
Изначально в фазе BDS можно было запустить только один тип EFI-приложений — bootloader, он же EFI-загрузчик. Порядок загрузки задается в переменной BootOrder, а путь и параметры загрузчика сохраняются в переменных Boot####, начиная с Boot0000 и заканчивая BootFFFF. В UEFI 2.3 был добавлен еще один тип — DXE-драйвер, который будет запущен диспетчером BDS до запуска любых загрузчиков из Boot####, и вместе с типом добавились соответствующие переменные DriverOrder и Driver####. В версии 2.4 добавили возможность привязать к EFI-загрузчику из Boot#### горячую клавишу, которая хранится в переменной Key####. В текущей версии и этого оказалось мало, и были добавлены сразу 3 новых типа приложений: SysPrep, OsRecovery и PlatformRecovery.SysPrep
Иногда получалось, что запускать какой-либо код из Driver#### слишком рано (к примеру, нужна консоль или полностью инициализированное железо), а из Boot#### — слишком поздно (BS-переменные уже недоступны, приходится шаманить с BootOrder'ом, чтобы гарантированно запускаться первым, если риск сломать загрузку совсем). Чтобы решить эту проблему, предложен третий тип приложений — System Preparation Application. Такие приложения запускаются после драйверов, но до загрузчиков и имеют доступ к консоли и графическому режиму. К приложениям такого типа могут относиться шифровальщики дисков, эмуляторы IPMI, системы адаптированного UI для людей с ограниченными возможностями и т.п. На SysPrep-приложения распространяются те же ограничения, что и на загрузчики, т.е. для использования их вместе с SecureBoot они должны быть подписаны подходящей ЭЦП.Возможно выглядит весьма полезной, осталось дождаться реализации и попробовать в деле.
OS Recovery
Если ни один из загрузчиков не смог запустить ОС, то ОС может инициировать восстановление загрузчика, для чего используются переменные OsRecoveryOrder и OsRecovery####. Эта возможность доступна только системам с поддержкой SecureBoot и для её использования SecureBoot должен быть активирован. При ее использовании приложения из SysPrep и PlatfromRecovery загружаться не будут.Platform Recovery
Если ни один из загрузчиков не смог запустить ОС, то UEFI тоже может инициировать восстановление загрузчика, используя данные из PlatfromRecoveryOrder и PlatfromRecovery####. Обе эти переменные недоступны для модификации из ОС, и будут использованы только в случае, когда OS Recovery недоступен. Одна из переменных PlatfromRecovery#### может быть помечена флагом Default Boot Behavior, т.е. именно указанное в ней приложение будет запущено в случае, если ничего другого запустить не удалось.Если обе вышеперечисленные возможности производители прошивок реализуют правильно, то о проблемах вроде этой можно будет наконец забыть.
Безопасность
В новом стандарте появилось несколько новых протоколов, которые предлагается использовать для контроля целостности компонентов прошивки и шифрования. Протокол EFI_PKCS7_VERIFY_PROTOCOL с двумя функциями VerufySignature и VerifyBuffer позволяет проверить целостность как самой ЭЦП (в формате PKCS7 binary DER), как и подписанных ей данных. Протокол EFI_HASH2_PROTOCOL добавляет к уже имеющейся возможности посчитать хеш-сумму от непрерывного буфера заранее заданного размера тройку функций HashInit, HashUpdate и HashFinal, которые позволяют вычислять хеш от потока данных или нескольких буферов на разных концах доступной памяти. Протокол EFI_BLOCK_IO_CRYPTO_PROTOCOL добавляет возможность чтения/записи данных с шифрованием «на лету»Также в стандарт добавлена поддержка использования NX-бита для защиты буферов и областей с данными от исполнения.
NVM
Как и в стандарты более низкого уровня, в UEFI 2.5 добавлена поддержка NVDIMM и других типов Persistent Memory. В основном это разного рода определения в заголовочных файлах, но нашлось место и новому протоколу — EFI_NVM_EXPRESS_PASS_THRU_PROTOCOL, используя который можно общаться с NVMe-устройствами напрямую, передавая «сырые» команды обнаруженным NVMe-устройствам и обрабатывая ответы от них.Сетевой стек и загрузка по сети
Загрузка по HTTP
Основным новшеством стандарта UEFI 2.5 является добавление загрузки по HTTP в качестве альтернативы уже имевшейся реализации UEFI PXE с использованием протокола TFTP. Для этого понадобилось добавление поддержки протоколов DNSv4, DNSv6 и самого HTTP, поддержки IPv6 драйвером UNDI, предложены изменения для корпоративных DHCP-серверов и некоторые другие улучшения. Окончательная схема загрузки по HTTP по стандарту выглядит вот так:
Загрузчик — обычное UEFI-приложение (чтобы отличать удаленные загрузчики от локальных, в стандарте их обозвали NBP), которые для использование совместно с SecureBoot требуется подписать подходящей ЭЦП. NBP может использовать сетевой стек для загрузки следующих стадий, так что написание многостадийных загрузчиков теперь небольшая проблема, в отличие от PXE.
Поддержка WiFi и Bluetooth
Также в новом стандарте появилась поддержка VLAN, WIFI и Bluetooth как компонентов сетевого стека. Вместе с ней появился целый ворох новых протоколов вроде EFI_WIRELESS_MAC_CONNECTION_PROTOCOL или EFI_BLUETOOTH_HC_PROTOCOL, которые, при наличии драйвера для аппаратной части, позволят получить доступ к беспроводным сетям из UEFI-драйверов и приложений.В итоге с прошивкой на базе UEFI 2.5 можно загрузить ОС ноутбука по WiFi с удаленного HTTP(S)-сервера без слишком уж сильного колдунства. Не могу сказать, что мне это очень нужно или меня это сильно радует, мой внутренний параноик немного ворчит, но если сетевая инфраструктура не нужна — ее можно отключить (и проконтролировать, что она действительно отключена) или выпилить совсем, это тоже не очень сложно.
Остальное
Осталась еще масса мелких изменений, о которых почти нечего рассказывать: поддержка устройств чтения смарт-карт, которые могут быть использованы как источники данных для различного-рода криптографии, новый протокол EFI_USBFN_IO_PROTOCOL для низкоуровневого общения с USB-устройствами, новые протокол EFI_REGULAR_EXPRESSION_PROTOCOL и HII-опкод EFI_IFR_MATCH2, который это самый RegExp-протокол будет использовать, несколько новых типов DevicePath-нод — BMC, SD-карта, RAM-диск, и так далее, всего не перечислить.Заключение
Мое общее впечатление от новых версий UEFI-стандартов — скорее положительное. Не могу сказать, что все изменения ожидаемы или очень нужны простому пользователю, часть сможет «выстрелить» только при грамотной реализации стандарта со стороны разработчиков UEFI-платформ (т.е. AMI, Insyde, Phoenix и т.д.), а некоторые очень понравятся разработчикам (ASL 2.0 FTW!), но в конечном итоге мой вердикт — пойдет. Посмотрим, конечно, получится ли реализовать все, что гладко выглядит на бумаге, но я надеюсь, что через полгода мне не придется писать статью вроде «почему не работает UEFI HTTP Boot и как с этим бороться».Спасибо читателю за потраченное время, и удачных вам прошивок.
This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий