Поделиться через

Требования UEFI для выпусков Windows на платформах SoC

  • Статья

В этой статье описываются требования UEFI, которые применяются к windows 10 для настольных версий (Домашняя, Pro, Корпоративная и Для образовательных учреждений), а также Windows 10 Mobile. Дополнительные требования, применимые только к Windows 10 Mobile, см. в разделе Требования UEFI для Windows 10 Mobile.

Сводка требований

В следующей таблице перечислены все текущие требования к соответствию UEFI, как определено в спецификации UEFI (раздел 2.6 спецификации UEFI 2.3.1). В этой таблице термин Явное требование Windows определяет любой протокол или службу, которые вызываются непосредственно компонентом Windows. Хотя Windows явно использует только эти службы, другие перечисленные службы и протоколы могут неявно или явно требоваться для реализации основного встроенного ПО, драйверов устройств EFI или цепочек инструментов разработки и развертывания.

Корпорация Майкрософт приветствует отзывы и комментарии разработчиков по этому набору требований. Для любых требований к соответствию UEFI, которые не требуются ни ОС, ни встроенного ПО, мы намерены проработать UEFI.org, чтобы эти требования к соответствию для этого класса устройств были ослаблены.

Дополнительные сведения о конкретных требованиях см. в разделах после таблицы.

Требование Раздел спецификации UEFI Примечания
Системная таблица EFI 4.3 Явное требование Windows
Службы загрузки EFI 6,0
Службы событий, таймеров и задач 6.1
Службы памяти 6.2 Явное требование Windows
Службы обработчиков протоколов 6.3 Явное требование Windows
Службы образов 6.4 Явное требование Windows
Прочие услуги 6,5 Явное требование Windows
Службы среды выполнения EFI 7,0
Службы времени 7.3 Явное требование Windows
Службы переменных 7.2 Явное требование Windows
Прочие услуги 7,5 % Явное требование Windows
Обязательные протоколы UEFI
Протокол загруженных образов EFI 8.1
Протокол пути к устройству с изображением, загруженным EFI 8.2
Протокол пути устройства EFI 9.2 Явное требование Windows
Протокол служебных программ пути устройства EFI 9,5
Протокол распаковки EFI 18.5
Протокол интерпретатора EBC 20.11
Условно обязательные протоколы UEFI
Протокол простого текстового ввода EFI 11,3 Явное требование Windows
Протокол EX простого текстового ввода EFI 11.2
Протокол простого вывода текста EFI 11,4
Протокол вывода графики EFI 11.9 Явное требование Windows
Обнаруженный протокол EFI EDID 11.9.1
Активный протокол EFI EDID 11.9.1
Протокол блочного ввода-вывода EFI 12,8 Явное требование Windows
Протокол дискового ввода-вывода EFI 12.7
Протокол простой файловой системы EFI 12,4
Протокол параметров сортировки Юникод EFI 12.10
Простой сетевой протокол EFI 21.1
Базовый протокол кода PXE EFI 21,3
Протокол служб целостности загрузки EFI 21,5
Протокол последовательного ввода-вывода EFI 11,8
Привязка arm UEFI 2.3.5 Явное требование Windows
Требования к безопасности
Безопасная загрузка 27.0 Явное требование Windows
Требования к диспетчеру загрузки 3.1, 3.3 Явное требование Windows

Требования к системной таблице EFI

Системная таблица EFI должна соответствовать стандартному определению на уровне редакции. Таблица конфигурации, на которую указывает системная таблица EFI, должна содержать два идентификатора GUID и связанные с ними указатели, описанные в следующей таблице.

Идентификатор GUID Описание
EFI_ACPI_Table GUID Этот GUID должен указывать на указатель описания корневой системы ACPI (RSDP) для платформы.
SMBIOS_Table GUID Этот GUID должен указывать на структуру точек входа SMBIOS.

Для Windows требуется спецификация SMBIOS на уровне версии 2.4 или выше. Требуются разделы 3.2, "Обязательные структуры и данные" и 4"Правила соответствия". Доступен тест совместимости Windows SMBIOS.

Требования к службам загрузки EFI

В следующей таблице перечислены требования к службам загрузки EFI для Windows.

Служба загрузки EFI Требование
Службы памяти Для Windows требуются все службы памяти.
Службы обработчиков протоколов Для Windows требуются следующие службы обработчиков протоколов:

OpenProtocol()
CloseProtocol()
LocateDevicePath()
LocateHandle()
Службы образов Для Windows требуются следующие службы образов:

ExitBootServices()
Прочие службы загрузки Для Windows требуются следующие прочие службы загрузки:

Stall()

Примечание: Реализация Stall() должна иметь детерминированную (повторяемую) ошибку, чтобы можно было надежно исправить или отменить ошибки.

Требования к службам среды выполнения EFI

В следующей таблице перечислены требования к службам среды выполнения EFI для Windows.

Служба среды выполнения EFI Требование
Службы времени Для Windows требуются следующие службы времени:

GetTime()
SetTime()

Примечание: Службы времени будут вызываться только во время загрузки (до ExitBootServices()) для доступа к оборудованию платформы.
Службы переменных Все службы переменных UEFI необходимы для управления несколькими загрузочными устройствами и переменными безопасности в целевом классе систем.
Прочие службы среды выполнения Для Windows требуются следующие прочие службы среды выполнения:

ResetSystem()

Примечание: Реализация ResetSystem() должна поддерживать параметры сброса и завершения работы.

Требования к протоколу

В следующей таблице описаны протоколы UEFI, необходимые Windows для выполнения определенных функций во время загрузки.

Протокол Требование
Протокол вывода графики Для Windows требуется протокол GOP. Конкретные требования к буферу кадров:

Для встроенных дисплеев HorizontalResolution и VerticalResoluton должны быть собственным разрешением панели.

Для внешних дисплеев horizontalResolution и VerticalResoluton должны быть собственным разрешением дисплея или, если это не поддерживается, то максимальные значения, поддерживаемые видеоадаптером и подключенным дисплеем.

PixelsPerScanLine должен быть равен HorizontalResolution.

PixelFormat должен иметь значение PixelBlueGreenRedReserved8BitPerColor. Требуется физический буфер кадров; PixelBltOnly не поддерживается.

Когда выполнение передается загрузочному приложению UEFI, диспетчер загрузки встроенного ПО и встроенное ПО не должны использовать буфер кадров для каких-либо целей. Буфер кадров должен продолжать проверяться после выхода загрузочных служб.
Альтернативные выходные данные отображения Встроенное ПО UEFI должно поддерживать загрузку с помощью любого соединителя дисплея, поддерживаемого оборудованием. Если внутренняя панель подключена и видна, необходимо использовать внутреннюю панель. Все выходные данные, имеющие физически подключенные дисплеи, должны отображать загрузочный экран. Для подключенных дисплеев встроенное ПО UEFI должно:

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

Если собственный режим невозможен, он должен инициализироваться в режиме максимальной совместимости.

Если не удается определить возможности отображения, подключенный дисплей должен быть инициализирован в режиме, который, как известно, совместим с максимально возможным количеством мониторов (обычно 640x480 или 1024x768 с частотой 60 Гц).
Входные данные во время загрузки Протокол простого ввода текста EFI требуется для выбора загрузки или выбора других меню в системах со встроенными клавиатурами или подключенными клавиатурами. Для систем без клавиатуры в среде загрузки рекомендуется использовать три кнопки:

Кнопка "Пуск"
Кнопка увеличения громкости
Кнопка уменьшения громкости

О нажатиях кнопок следует сообщать по протоколу EFI Simple Text Input Protocol, сопоставляя их со следующими клавишами клавиатуры соответственно:

Клавиша Windows
Клавиша СТРЕЛКА ВВЕРХ
Клавиша СТРЕЛКА ВНИЗ
Загрузка локального хранилища Для Windows требуется поддержка протокола блочного ввода-вывода и протокола пути к устройству для решения хранилища, содержащего системный раздел EFI и раздел ОС Windows. Для загрузки из хранилища флэш-памяти, требующего выравнивания износа или другого управления флэш-памятью, это должно быть реализовано во встроенном ПО (а не в приложении UEFI).

Требования безопасности

Windows предъявляет требования к безопасности в таких областях, как безопасная загрузка, измеряемая загрузка, шифрование и защита данных. Эти требования подробно описаны в следующей таблице. Кроме того, для тех областей, в которых оборудование SoC не соответствует существующему стандарту (TPM, RTC и т. д.), разрабатываются дополнительные требования. Они описаны в конце таблицы.

Область Требование
Общее

  • Требование 1. ОБЯЗАТЕЛЬНО. Платформа должна соответствовать всем требованиям, указанным в этом разделе.

  • Требование 2. ОБЯЗАТЕЛЬНО. Платформы должны быть UEFI класса 3 без установленного или устанавливаемого модуля поддержки совместимости. Эмуляция BIOS и устаревшая загрузка КОМПЬЮТЕРА или AT должны быть отключены.
Безопасная загрузка UEFI

  • Требование 3. ОБЯЗАТЕЛЬНО. Безопасная загрузка, определенная в разделе 27 UEFI версии 2.3.1, должна поставляться с включенной базой данных сигнатур (EFI_IMAGE_SECURITY_DATABASE), необходимой для безопасной предварительно подготовленной загрузки компьютера. Начальное содержимое базы данных сигнатуры определяется изготовителем оборудования на основе необходимых сторонних драйверов UEFI, требований к восстановлению и загрузчика ОС, установленного на компьютере, но должна быть включена EFI_CERT_X509 подпись, предоставляемая корпорацией Майкрософт. Никаких дополнительных подписей не должно быть.

  • Требование 4. ОБЯЗАТЕЛЬНО. Требуется наличие базы данных сигнатур UEFI "запрещено" (EFI_IMAGE_SECURITY_DATABASE1).

  • Требование 5. ОБЯЗАТЕЛЬНО. Предоставленный Корпорацией Майкрософт KEK UEFI KEK должен быть включен в базу данных UEFI KEK. Дополнительные ключи KEK не должны присутствовать. Корпорация Майкрософт предоставляет KEK в виде подписи EFI_CERT_X509.

  • Требование 6. ОБЯЗАТЕЛЬНО. Ключпубликации PK должен присутствовать и храниться во встроенной памяти. Примечание. Так как PKpriv (аналог PKpub с закрытым ключом) управляет политикой безопасной загрузки на всех устройствах, подготовленных с помощьюPK pub, ее защита и использование должны быть строго защищены.

  • Требование 7. ОБЯЗАТЕЛЬНО. Исходные базы данных сигнатуры должны храниться во встроенном ПО и могут обновляться только с помощью обновления встроенного ПО, подписанного OEM, или путем записи переменных, прошедших проверку подлинности UEFI.

  • Требование 8. ОБЯЗАТЕЛЬНО. Образы в пути загрузки, которые не выполняют проверку подписи, не должны выполняться, и причина сбоя должна быть добавлена в EFI_IMAGE_EXECUTION_TABLE. Кроме того, рекомендуемый подход в таких ситуациях заключается в том, что диспетчер загрузки UEFI инициирует восстановление в соответствии со стратегией изготовителя оборудования.

  • Требование 9. ОБЯЗАТЕЛЬНО. Для образов UEFI, которым не удается проверить подпись, не должно быть разрешено физическое переопределение пользователя.

  • Требование 10. НЕОБЯЗАТЕЛЬНО. Изготовитель оборудования может реализовать возможность для физического пользователя отключить безопасную загрузку с доступом к PKpriv или с физическим присутствием через настройку встроенного ПО. Доступ к настройке встроенного ПО может быть защищен определенными платформами способами (паролем администратора, смарт-карта, статической конфигурацией и т. д.).

  • Требование 11. ОБЯЗАТЕЛЬНО, если реализовано требование 10. Если безопасная загрузка отключена, все существующие переменные UEFI будут недоступны.

  • Требование 12. НЕОБЯЗАТЕЛЬНО. Изготовитель оборудования может реализовать возможность физического пользователя выбирать между двумя режимами безопасной загрузки при настройке встроенного ПО: "Пользовательский" и "Стандартный". Пользовательский режим обеспечивает большую гибкость, как указано ниже.

  • Требование 13. ОБЯЗАТЕЛЬНО, если выполняется требование 12. Можно повторно включить отключенную безопасную загрузку в пользовательском режиме, задав конкретный PK владельца. Администрация должна действовать в соответствии с разделом 27.5 спецификации UEFI версии 2.3.1: Обмен ключами встроенного ПО/ОС. В пользовательском режиме владелец устройства может задать выбор подписей в базах данных подписей.

  • Требование 14. ОБЯЗАТЕЛЬНО, если реализовано требование 12. Настройка встроенного ПО должна указывать, включена ли безопасная загрузка и работает ли она в стандартном или пользовательском режиме. Настройка встроенного ПО должна предоставлять возможность возврата из настраиваемого режима в стандартный.

  • Требование 15. ОБЯЗАТЕЛЬНО. Если параметры встроенного ПО сбрасываются до заводских значений по умолчанию, все настраиваемые защищенные переменные будут удалены, а исходныйпаб PK должен быть восстановлен вместе с исходными базами данных подписей, подготовленными производителем.

  • Требование 16. ОБЯЗАТЕЛЬНО. Для подписывания драйвера используется параметр Authenticode (WIN_CERT_TYPE_PKCS_SIGNED_DATA).

  • Требование 17. ОБЯЗАТЕЛЬНО. Поддержка EFI_IMAGE_EXECUTION_INFO_TABLE (т. е. создание и хранение сведений об образах, запущенных или не запущенных во время загрузки).

  • Требование 18. ОБЯЗАТЕЛЬНО. Поддержка GetVariable() для EFI_IMAGE_SECURITY_DATABASE (как авторизованной, так и запрещенной базы данных сигнатур).

  • Требование 19. ОБЯЗАТЕЛЬНО. Поддержка SetVariable() для EFI_IMAGE_SECURITY_DATABASE (как авторизованной, так и запрещенной базы данных подписей) с использованием KEK Майкрософт для проверки подлинности.

  • Требование 20. ОБЯЗАТЕЛЬНО. EFI_HASH_SERVICE_BINDING_PROTOCOL: Поддержка службы: CreateChild(), DestroyChild().

  • Требование 21. ОБЯЗАТЕЛЬНО. EFI_HASH_PROTOCOL. Поддержка службы: Hash(). Поддержка хэш-алгоритмов SHA_1 и SHA-256. Должен поддерживать передачу сообщения длиной не менее 10 МБ.
Измеряемая загрузка UEFI

Следующие требования не подразумевают необходимость реализации TCG TPM. Однако они подразумевают потребность в эквивалентных функциональных возможностях для затронутых областей.

Поддержка платформы может быть обеспечена реализацией встроенного ПО доверенного платформенного модуля, выполняющегося в безопасной среде выполнения, наложенной на подсистему криптографического ускорения и используя изолированное хранилище. Корпорация Майкрософт может предоставить эталонное программное обеспечение для такой реализации доверенного платформенного модуля для использования поставщиком. Этот вопрос подлежит дальнейшему обсуждению.

  • Требование 22. ОБЯЗАТЕЛЬНО. Платформа должна соответствовать протоколу EFI, указанному в протоколе EFI доверенной среды выполнения UEFI.

  • Требование 23. ОБЯЗАТЕЛЬНО. Платформа должна соответствовать спецификации платформы TCG EFI со следующими дополнениями:

    • На платформах, поддерживающих интерфейс, определенный в протоколе EFI TrEE, дайджестпубликации PK должен быть расширен на PCR TPM[03] в качестве события EV_EFI_VARIABLE_CONFIG.

    • Дайджест содержимого авторизованной базы данных сигнатур (см. раздел 27.8 спецификации UEFI версии 2.3.1) должен быть расширен в измеряемой загрузке как событие EV_EFI_VARIABLE_CONFIG. Операция расширения должна быть выполнена в TPM PCR[03].

    • Клиент UEFI может считывать и анализировать список сертификатов с помощью переменной EFI_IMAGE_SECURITY_DATABASE и проверять дайджест на соответствие расширенному значению.

    • TCG_PCR_EVENT значения дайджеста должны быть SHA-256, а не SHA-1.

  • Требование 24. ОБЯЗАТЕЛЬНО. Платформа должна реализовать MemoryOverwriteRequestControl, определенный в спецификации по устранению рисков атак на сброс платформы TCG.
Шифрование

  • Требование 25. ОБЯЗАТЕЛЬНО. Платформа должна предоставить EFI_HASH_PROTOCOL (UEFI версии 2.3.1, раздел 27.4) для разгрузки криптографических хэш-операций. Должна поддерживаться SHA-256.

  • Требование 26. ОБЯЗАТЕЛЬНО. Платформа должна поддерживать определенные корпорацией Майкрософт EFI_RNG_PROTOCOL для предварительного чтения ос энтропии.
Защита данных

  • Требование 27. ОБЯЗАТЕЛЬНО. Платформа должна поддерживать переменные EFI с любым сочетанием следующих атрибутов переменных UEFI:

    • EFI_VARIABLE_BOOTSERVICE_ACCESS

    • EFI_VARIABLE_NON_VOLATILE

    • EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS
Другие требования к безопасности

Для Windows на платформах SoC требуются следующие дополнительные требования.

  • Корпорация Майкрософт определила протокол для сбора энтропии с платформы UEFI. Хотя этот протокол не является обязательным для UEFI, он требуется для Windows на платформах SoC. Дополнительные сведения об этом протоколе см. в разделе Протокол сбора энтропии UEFI.

  • Обновления базы данных подписи UEFI. В разделе 27 UEFI 2.3.1 был принят новый механизм обновления переменных, прошедших проверку подлинности. Этот механизм необходим для Windows.

  • Доверенная среда выполнения. Корпорация Майкрософт разработала протокол EFI для взаимодействия с доверенной средой выполнения (TrEE), аналогичной по функциональным возможностям подмножества доверенного платформенного модуля (TCG). Протокол EFI в значительной степени использует "TCG EFI Protocol", версия 1.2, редакция 1.00, 9 июня 2006 г., группа доверенных вычислений.

    Дополнительные сведения см. в статье Протокол EFI доверенной среды выполнения UEFI.

Требования к диспетчеру загрузки встроенного ПО

Диспетчер загрузки встроенного ПО должен поддерживать поведение загрузки по умолчанию, определенное в разделе 3.3 спецификации. Кроме того, для поддержки нескольких загрузочных глобально определенных переменных и требований диспетчера загрузки, указанных в разделе 3.1 спецификации, требуются.

Требования к привязке arm UEFI

Привязка arm UEFI включает требования, относящиеся к платформе Arm, необходимые для соответствия спецификации UEFI. Для Windows требуется все содержимое привязки Arm, применимое к ARMv7. Так как Windows не поддерживает ничего, предшествующее ARMv7, требования в привязке, относящиеся к ARMv6k и ниже, являются необязательными.

Привязка указывает, например, как следует настроить MMU и как следует сопоставить физическую память. Привязка также указывает, что вызовы протоколов и служб UEFI должны выполняться только в ISA Arm. Это означает, что программное обеспечение, работающее в Thumb2 или Thumb, должно вернуться в режим Arm перед вызовом функций UEFI.

Требования к запуску нескольких обработчиков UEFI Arm

Корпорация Майкрософт разработала протокол для запуска нескольких ядер Arm на многопроцессорной платформе UEFI. Этот протокол требуется для windows на платформах Arm, которые не поддерживают интерфейс координации состояния power (PSCI). Платформы, поддерживающие PSCI, не должны использовать этот протокол. Дополнительные сведения об этом протоколе см. в документе Запуск многопроцессоров на платформах на основе Arm UEFI на веб-сайте ACPI Component Architecture (ACPICA).

Требования к настройке платформы

Встроенное ПО отвечает за перевод оборудования системы в четко определенное состояние перед передачой загрузчику ОС. В следующей таблице определены соответствующие требования к настройке платформы.

Требование Описание
Путь загрузки Встроенное ПО должно инициализировать платформу до точки, когда Windows сможет получить доступ к загрузочному устройству через UEFI и загрузить ядро. Все устройства, участвующие в иерархии для чтения с загрузочного устройства, должны быть с часовым и питанием с разумной скоростью, учитывая производительность и питание. Базовое ядро процессора также должно быть с часовым режимом и питанием с разумной скоростью, чтобы система своевременно загружалась без разрядки батареи.
Основные системные ресурсы Основные системные ресурсы, которые предоставляются операционной системе через таблицы ACPI, должны быть включены и тактированы. Основные системные ресурсы включают контроллеры прерываний, таймеры и контроллеры DMA, которыми должна управлять ОС. Кроме того, прерывания должны быть замаскированы вызовом ExitBootServices() до тех пор, пока связанный драйвер устройства в ОС не расключит и повторно не включит прерывания на устройстве. Если прерывания включены во время загрузочных служб, предполагается, что ими управляет встроенное ПО.
Отладка Windows поддерживает отладку через узел USB 3 (XHCI), узел USB 2 (EHCI)1, IEEE 1394, последовательный интерфейс и интерфейс функции USB (а также адаптеры Ethernet PCI). По крайней мере один из них должен быть питанием, тактовой синхронизацией и инициализирован встроенного ПО до передачи ОС. Какой бы вариант ни был предоставлен, он должен иметь предоставленный порт для отладки, а контроллер должен быть сопоставлен в памяти или быть подключен через выделенную (не общую) периферийную шину.
Другие требования к настройке платформы Перед передачой управления загрузчику ОС необходимо выполнить настройку мультиплексирования контактов и панели во встроенном ПО.

Требования к установке

Для Windows требуется, чтобы раздел ОС находился в решении для секционированного хранилища GPT. В качестве хранилища данных можно использовать секционированное хранилище MBR. Как определено в спецификации UEFI, для платформы UEFI требуется выделенный системный раздел. Для Windows требуется выделенный системный раздел, называемый системным разделом EFI (ESP).

Требования к аппаратному интерфейсу тестирования безопасности (HSTI)

Платформа должна реализовать интерфейс тестирования безопасности оборудования, а платформа должна предоставлять общий доступ к документации и средствам, как указано в спецификации тестируемости безопасности оборудования.

Минимальные требования UEFI для Windows на платформах SoC

Требования UEFI для Windows 10 Mobile

Требования UEFI для поддержки флэш-памяти USB