Что новые версии UEFI-стандартов нам готовят, часть первая, PI 1.4

После полугода разработки организация 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. Реализовано грамотно, будем надеяться на скорейшее внедрение.