Обычно между выпуском новых версий стандартов и первыми прошивками на их базе проходит обычно от 4 до 6 месяцев, но уже сейчас можно предсказать с высокой долей вероятности, какие именно новые возможности появятся в UEFI для платформ на базе процессоров Intel Skylake и AMD Falcon Series.
Я решил разделить описание новшеств на 3 части, иначе оно рискует оказаться очень длинным и читать его никто не станет. Если вас интересуют новшества, описанные в стандарте PI 1.4 и мои комментарии к ним — добро пожаловать под кат.
Очень короткое введение
Если вдруг вас пугает незнакомая терминология или вы не можете понять, о чем тут вообще речь, прочтите вот эту мою статью и возвращайтесь.
Возможно, обычному человеку будут малоинтересны описания новых PPI и протоколов, тем более, что их можно взять и прямо из документации, поэтому я постараюсь разбавить скучное перечисление изменений комментариями о том, для чего они могут понадобится разработчику UEFI и чем грозят его пользователям.
UEFI Forum рассказывает и показывает
Совместно в документацией UEFI Forum опубликовал вот этот пресс-релиз, от которого после очистки от маркетингового буллшита остается следующее:
Все стандарты
- NVM support: поддержка оперативной памяти, сохраняющей данные при выключении машины, так называемой NVDIMM.
- Graphics PPI: запуск графическую подсистему во время фазы PEI.
- Multi-processor PPI: инициализация всех доступных процессоров и ядер во время фазы PEI.
- Capsule PPI: обнаружение образов с обновлениями в формате UEFI Capsule, сборка их в непрерывную область памяти и передача в фазу DXE.
- No Execute Support: защита прошивки от скомпрометированного гипервизора/ОС.
- CPU Topology Recognition: определение топологии CPU, позволяет точнее управлять компонентами SoC и снизить их энергопотребление.
- Source Language Evolution: улучшения синтаксиса языка ASL, на котором пишутся обработчики вызовов ACPI.
- 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)
Atakua
03.06.2015 11:09+1Спасибо за статью! Было бы интересно узнать Ваше отношение к Bios Guard поподробнее. Я по работе вроде бы и связан с низкоуровневыми фазами загрузки на IA, но вот конкретно Bios Guard как-то прошло мимо меня. Тем интереснее узнать мнение сторонних разработчиков об этой и подобных тенденциях в UEFI-строении.
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, а обычный пользователь имеет право менять прошивки своих устроств на все, что угодно.
amarao
boot from http — одобряю. Старые ритуалы pxe с tftp всегда раздражали.
CodeRush Автор
Поддерживаю, тем более, что сетевой стек UEFI готов к применению уже пару лет, а толку от него не было почти никакого и потому он был отключен по умолчанию почти на всех системах. Теперь вот применение нашлось, но реализаций я пока еще не видел, ждем-с.
toxicdream
О сколько чудных дыр ГУАШ нам готовит.
ЗЫ Пунтосвичер об казахский споткнулся. Решил не исправлять.