После полугода разработки организация UEFI Forum выложила наконец в открытый доступ документацию по новым стандартам Platform Initialization 1.4, Advanced Configuration and Power Interface 6.0 и Unified Extensible Firmware Interface 2.5, на базе которых сейчас разрабатывается абсолютное большинство прошивок для ПК и серверов.
Обычно между выпуском новых версий стандартов и первыми прошивками на их базе проходит обычно от 4 до 6 месяцев, но уже сейчас можно предсказать с высокой долей вероятности, какие именно новые возможности появятся в UEFI для платформ на базе процессоров Intel Skylake и AMD Falcon Series.
Я решил разделить описание новшеств на 3 части, иначе оно рискует оказаться очень длинным и читать его никто не станет. Если вас интересуют новшества, описанные в стандарте PI 1.4 и мои комментарии к ним — добро пожаловать под кат.

Очень короткое введение


Если вдруг вас пугает незнакомая терминология или вы не можете понять, о чем тут вообще речь, прочтите вот эту мою статью и возвращайтесь.
Возможно, обычному человеку будут малоинтересны описания новых PPI и протоколов, тем более, что их можно взять и прямо из документации, поэтому я постараюсь разбавить скучное перечисление изменений комментариями о том, для чего они могут понадобится разработчику UEFI и чем грозят его пользователям.

UEFI Forum рассказывает и показывает


Совместно в документацией UEFI Forum опубликовал вот этот пресс-релиз, от которого после очистки от маркетингового буллшита остается следующее:
Все стандарты
  • NVM support: поддержка оперативной памяти, сохраняющей данные при выключении машины, так называемой NVDIMM.
PI 1.4
  • Graphics PPI: запуск графическую подсистему во время фазы PEI.
  • Multi-processor PPI: инициализация всех доступных процессоров и ядер во время фазы PEI.
  • Capsule PPI: обнаружение образов с обновлениями в формате UEFI Capsule, сборка их в непрерывную область памяти и передача в фазу DXE.
  • No Execute Support: защита прошивки от скомпрометированного гипервизора/ОС.
ACPI 6.0:
  • CPU Topology Recognition: определение топологии CPU, позволяет точнее управлять компонентами SoC и снизить их энергопотребление.
  • Source Language Evolution: улучшения синтаксиса языка ASL, на котором пишутся обработчики вызовов ACPI.
UEFI 2.5:
  • Boot From HTTP: новый способ загрузки по сети, пришедший на смену PXE.
  • Platform Recovery: новый стандарт на способы восстановления целостности прошивки при невозможности загрузки системы.
  • Connectivity Support: поддержка технологий Bluetooth и Wi-Fi/EAP2.
  • High Assurance Enterprise Replacement: новая система автоматического разворачивания обновлений.

Все это замечательно, конечно, но не очень информативно, да и список изменений далеко не полный, поэтому мы пойдем другим путем. Пусть заключается в том, чтобы при помощи утилиты Beyond Compare сравнить 7 PDF-файлов старого стандарта с соответствующими файлами нового, найти все значимые изменения и понять, зачем они нужны и чем грозят. Приступим.

Изменения в Platfrom Initialization


Стандарт на PI состоит из 5 томов, описывающих фазы PEI, DXE, SMM, общие архитектурные элементы прошивки и протоколы взаимодействия с оборудованием. Пройдемся по изменениям в них в порядке возрастания номера.

Volume 1. Pre-EFI Initialization

ResetSystem2
В EFI_PEI_SERVICES добавлена новая функция ResetSystem2 и соответствующий ей PPI. От обычной ResetSystem и ее PPI новая функция отличается параметрами и имеет следующую сигнатуру:
VOID ResetSystem2 (IN EFI_RESET_TYPE ResetType,
                   IN EFI_STATUS     ResetStatus,
                   IN UINTN          DataSize,
                   IN VOID          *ResetData OPTIONAL);

Тип может принимать одно из следующих значений: EfiResetCold, EfiResetWarm, EfiResetShutdown, EfiResetPlatformSpecific, где EfiResetCold — «холодная» перезагрузка, т.е. сброс и повторная инициализация процессора, чипсета и всего, что к ним подключено, EfiResetWarm — «мягкая» перезагрузка, т.е. сброс только процессора, EfiResetShutdown — выключение машины, а EfiResetPlatformSpecific — тип сброса определяется GUIDом, переданным в ResetData.

Полезная функция, особенно радует возможность выполнить Shutdown прямо из PEI (раньше приходилось городить платформозависимые костыли) и передать статус сброса (т.е. штатный он или нет, а если нет, то почему произошел).

SEC Platform Information 2 PPI
Новый PPI для получения информации не только о BSP, об остальных процессорах и ядрах. Понадобится для PPI ниже.

EFI MP Services PPI
PPI для ранней инициализации всех процессоров и ядер. Позволит уже в PEI инициализировать и использовать несколько ядер.

PEI Recovery Block IO 2 PPI
Новый драйвер блочных устройств для режима восстановления PEI. Может быть использован для реализации стандартного механизма PEI Recovery, сейчас каждый вендор придумывает что-то свое, и почти всегда это свое работает из рук вон плохо. Посмотрим, какой получится ли стандартная реализация.

PEI Capsule PPI
PPI для сборки нескольких обновлений в формате UEFI Capsule в одну непрерывную область памяти и передачи этой области в DXE-драйвер, который и проведет обновление. Позволит реализовать обновление прошивки по частям, не связываясь при этом с Intel BiosGuard и подобными вендор-специфичными решениями.

Volume 2. Driver Execution Environment Core Interface

Новые типы EfiGcdMemory
UEFI составляет для себя и ОС карту памяти, которая заполняется функцией AddMemorySpace(), выглядящей вот так:
EFI_STATUS AddMemorySpace(IN EFI_GCD_MEMORY_TYPE GcdMemoryType,
                          IN EFI_PHYSICAL_ADDRESS BaseAddress,
                          IN UINT64 Length,
                          IN UINT64 Capabilities);

Первым параметром указывается тип добавляемой области памяти, который выбирается из следующих вариантов:
typedef enum {
      EfiGcdMemoryTypeNonExistent,
      EfiGcdMemoryTypeReserved,
      EfiGcdMemoryTypeSystemMemory,
      EfiGcdMemoryTypeMemoryMappedIo,
      EfiGcdMemoryTypePersistent,
      EfiGcdMemoryTypeMoreReliable,
      EfiGcdMemoryTypeMaximum
} EFI_GCD_MEMORY_TYPE;

Предпоследние два типа, Persistent и MoreReliable, были добавлены в этом обновлении.
Тип Persistent будет использоваться для NVDIMM и других non-volatile хранилищ, отображенных напрямую в адресное пространство BSP, а тип MoreReliable — для «более надежной» памяти, например, для локальной памяти BSP, являющегося частью NUMA-кластера.
Вместе с добавлением двух новых типов памяти появились соответствующие им атрибуты EFI_RESOURCE:
EFI_RESOURCE_ATTRIBUTE_PERSISTENT
EFI_RESOURCE_ATTRIBUTE_PERSISTABLE
EFI_RESOURCE_ATTRIBUTE_MORE_RELIABLE
EFI_RESOURCE_ATTRIBUTE_READ_ONLY_PROTECTED
EFI_RESOURCE_ATTRIBUTE_READ_ONLY_PROTECTABLE
Описывать их я не буду, ибо имена говорят сами за себя.

В остальных томах важных изменений нет вообще, лишь пара новых GUIDов для новых PPI и исправления очепяток.

Заключение


Изменения, на первый взгляд, положительные, но немного пугающие.

Дело в том, что написание PEI-модулей — занятие весьма нетривиальное из за специфических требований к ним, а отладка таких модулей (особенно тех, которые выполняются до инициализации оперативной памяти) — еще нетривиальнее, и потому хотелось бы иметь минимальное количество кода в PEI (просто по принципу меньше кода — меньше багов). Я понимаю, зачем в стандарт добавили PPI для графики и многоядерности, и они добавлены в качестве опциональных, но это мне придется реверсить глючный PEI-модуль видеокарты, чтобы понять, какого черта он не работает, и а про последствия внезапного появления многопоточности там, где ее не было и не планировалось я предпочту промолчать. Будем надеяться, что эти опциональные PPI просто никто не реализует и они так и останутся на бумаге.

О новшествах стандарта ACPI 6.0 — во второй части, об UEFI 2.5 — в третьей.
Спасибо за внимание и безглючных вам прошивок.

P.S.
Внимательный читатель уже заметил, что о поддержке NX, которую рекламируют в пресс-релизе, ничего так и не было сказано, но это потому, что она не является частью стандарта, а реализована отдельно благодаря работе инженеров Phoenix. Реализовано грамотно, будем надеяться на скорейшее внедрение.

Комментарии (7)


  1. amarao
    02.06.2015 23:18
    +4

    boot from http — одобряю. Старые ритуалы pxe с tftp всегда раздражали.


    1. CodeRush Автор
      02.06.2015 23:37

      Поддерживаю, тем более, что сетевой стек UEFI готов к применению уже пару лет, а толку от него не было почти никакого и потому он был отключен по умолчанию почти на всех системах. Теперь вот применение нашлось, но реализаций я пока еще не видел, ждем-с.


    1. toxicdream
      03.06.2015 21:36

      О сколько чудных дыр ГУАШ нам готовит.

      ЗЫ Пунтосвичер об казахский споткнулся. Решил не исправлять.


  1. Atakua
    03.06.2015 11:09
    +1

    Спасибо за статью! Было бы интересно узнать Ваше отношение к Bios Guard поподробнее. Я по работе вроде бы и связан с низкоуровневыми фазами загрузки на IA, но вот конкретно Bios Guard как-то прошло мимо меня. Тем интереснее узнать мнение сторонних разработчиков об этой и подобных тенденциях в UEFI-строении.


    1. CodeRush Автор
      03.06.2015 11:56
      +1

      Отдел маркетинга немного спутал терминологию, и теперь непонятно, о каком именно Guard'е идет речь.
      Если речь идет про то, что раньше называлось Intel PFAT, но отрицательно, слишком уж сложной оказалась технология, а плюсов каких-то кроме меньшей attack surface у нее по сравнению с обычным SMM-флешером нет, зато минусов вагон и маленький бронепоезд. решающими минусами для меня были vendor lock-in и необходимость писать скрипты на еще одном DSL, только чтобы образ для обновления прошивки подготовить.
      Если же речь идет о том, что раньше называлось Intel AC, а теперь называется то BIOS Guard, то Boot Guard в зависимости от настроения, то нейтрально. С одной стороны, я отлично понимаю, зачем и кому нужен hardware root of trust, но когда для возможности сменить прошивку или добавить туда свой код в худшем случае придется менять чипсет (или весь SoC, если у вас одночиповая система) или терпеть перезагрузку раз в 30 минут — это наводит на неприятные мысли про тивоизацию, ограничение свободы ради безопасности и так далее. Есть, конечно, свои плюсы, но на большинстве наших плат технология эта использовать не будет. Хотите root-of-trust — используйте крипточип или TPM measured boot, а обычный пользователь имеет право менять прошивки своих устроств на все, что угодно.


  1. xpancy
    03.06.2015 11:28

    Главный вопрос: на сколько это всё помешает обычному человеку запустить Линукс?


    1. CodeRush Автор
      03.06.2015 12:10
      +2

      Не помешает, даже поможет, я расскажу подробнее об этом во второй части.