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

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

      +4
      boot from http — одобряю. Старые ритуалы pxe с tftp всегда раздражали.
        0
        Поддерживаю, тем более, что сетевой стек UEFI готов к применению уже пару лет, а толку от него не было почти никакого и потому он был отключен по умолчанию почти на всех системах. Теперь вот применение нашлось, но реализаций я пока еще не видел, ждем-с.
          0
          О сколько чудных дыр ГУАШ нам готовит.

          ЗЫ Пунтосвичер об казахский споткнулся. Решил не исправлять.
          +1
          Спасибо за статью! Было бы интересно узнать Ваше отношение к Bios Guard поподробнее. Я по работе вроде бы и связан с низкоуровневыми фазами загрузки на IA, но вот конкретно Bios Guard как-то прошло мимо меня. Тем интереснее узнать мнение сторонних разработчиков об этой и подобных тенденциях в UEFI-строении.
            +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, а обычный пользователь имеет право менять прошивки своих устроств на все, что угодно.
            0
            Главный вопрос: на сколько это всё помешает обычному человеку запустить Линукс?
              +2
              Не помешает, даже поможет, я расскажу подробнее об этом во второй части.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое