Legacy oprom что это: ✅ Управление опциями загрузки и политики oprom

Содержание

Руководство по выбору параметра проверки UEFI


  • Статья


  • Чтение занимает 16 мин


Версия 1.3

Этот документ помогает изготовителям оборудования и ODM проверить, проверяет ли встроенное ПО подписи параметров РОМ в рамках цепочки доверия безопасной загрузки.

В этом руководстве предполагается, что вы знаете основы UEFI, базовое понимание безопасной загрузки (главы 1, 2, 13, 20 и 27 спецификации UEFI) и модель безопасности PKI.

Введение

Параметры ROM (или OpROM) — это встроенное ПО, выполняемое BIOS компьютера во время инициализации платформы. Они обычно хранятся на карте подключаемого модуля, хотя они могут находиться на системной плате.

Устройства, для которых обычно требуются параметры ROM, являются видеоадаптерами, сетевыми адаптерами и драйверами хранения для модулей RAID. Эти варианты ROM также обычно предоставляют драйверы встроенного ПО на компьютере.

К ним относятся различные типы драйверов встроенного ПО, включая устаревшие roms PC-AT, Open Firmware и EFI. Примеры драйверов встроенного ПО включают BIOS видео на видеоадаптерах, загрузочных драйверах PXE для адаптеров Ethernet и драйверах хранения на контроллерах RAID. Как правило, эти устройства имеют параметры ROM, которые предоставляют драйверы встроенного ПО.

Единый расширяемый интерфейс встроенного ПО (UEFI) имеет поддержку параметров ROM в устаревшем режиме.

Согласно последней спецификации UEFI (в настоящее время в версии 2.3.1 Errata C — раздел 2.5.1.2), roms isA (legacy) не являются частью спецификации UEFI. В целях этого обсуждения будут рассматриваться только совместимые с СТАНДАРТом UEFI параметры, совместимые с PCI.

Параметр ROM можно использовать, если невозможно внедрить встроенное ПО устройства в встроенное ПО компьютера. Если параметр rom содержит драйвер, IHV может использовать этот драйвер и держать драйвер и устройство в одном месте.

В этом документе рассказывается о том, почему необходимо проверить параметры ROM и показаны некоторые методы его выполнения.

Поддержка BIOS UEFI и прежних версий BIOS

Многие производители создают устройства, которые включают в себя варианты ROM и встроенное ПО для многих типов компьютеров. Распространенные со списком:

  • Только устаревшие диски
  • UEFI Native OpROM
  • Устаревшие rom + UEFI EBC OpROM
  • Устаревшие rom + UEFI x64 OpROM
  • Устаревшие ДИСКИ + UEFI x64 + UEFI IA32
  • Устаревшие rom + UEFI x64 + UEFI IA32 + UEFI EBC OpROM

BIOS UEFI может загружать и выполнять устаревшие драйверы встроенного ПО, если включен модуль поддержки совместимости (CSM). Обратите внимание, что при включенной безопасной загрузке выполнение модуля поддержки совместимости и устаревших ROM запрещено, так как устаревшие драйверы встроенного ПО не поддерживают проверку подлинности. Если для параметра в конфигурации BIOS задан устаревший ДИСК, он всегда будет использовать устаревшие диски на устройстве.

Если для формата option ROM задано значение UEFI Compatible, он будет использовать более новые диски EFI, если они присутствуют, и устаревшие диски, если они отсутствуют.

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

1. UEFI и параметры ROM

Рис. 2. Вопросы безопасности драйвера UEFI, источник: UEFI 2.3.1 Errata C

Следующий текст возник в UEFI 2.3.1 Errata C, но с тех пор был изменен с помощью аналитических сведений от партнеров:

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

В том числе:

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

Такие компоненты, как Диспетчер удостоверений пользователей, драйверы учетных данных пользователя и драйверы платы, возможно, находятся в безопасном расположении, например защищенном для записи флэш-накопитель, который доверяется политике платформы.

Некоторые другие драйверы могут находиться в незащищенных местах хранения, таких как параметры ROM или раздел жесткого диска, и их можно легко заменить. Эти драйверы должны быть проверены.

Например, политика платформы по умолчанию должна успешно проверить драйверы, перечисленные в параметрах загрузки Driver##### или определить пользователя перед обработкой этих драйверов. В противном случае выполнение драйвера должно быть отложено. Если профиль пользователя изменяется с помощью последующего вызова для определения () или с помощью динамической проверки подлинности, параметры Driver#### могут не обрабатываться повторно.

База данных профиля пользователя закрывается с помощью различных событий сигнала UEFI в зависимости от того, можно ли защитить ее.

Параметры UEFI драйверов & UEFI будут выполняться только для устройств в пути загрузки.

Спецификация PCI позволяет использовать несколько вариантов образов rom на одном устройстве. Эти варианты ROMS могут быть устаревшими x86 & UEFI. Встроенное ПО UEFI задает политику платформы для выбора параметра ROM. Это может сделать диск дополнительного адаптера выполняться в качестве собственного устройства управления.

Встроенное ПО проверяет подписи на этапах BDS и DXE. Ниже представлена последовательность событий.

  1. Инициализация PCI и производных автобусов
  2. Проба устройств PCI для параметров ROM
  3. Найденные roms сопоставляются в памяти
  4. Этап DXE загружает все драйверы UEFI в roms

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

На компьютере с включенной безопасной загрузкой драйверы параметров могут представлять угрозу безопасности, если они не подписаны или не проверены. Проверка подписи для параметров ROM — это требование WHCK. То же самое верно при выполнении параметров обслуживания, чтобы убедиться, что обновление проверено перед установкой.

Из спецификаций и политик программы совместимости оборудования Windows версии 1809:

  1. Проверка целостности кода встроенного ПО со знаком. Встроенное ПО, установленное изготовителем оборудования и защищенное либо доступное только для чтения, либо защищенное процессом обновления встроенного ПО, как определено выше, может считаться защищенным. Системы должны убедиться, что все незащищенные компоненты встроенного ПО, драйверы UEFI и приложения UEFI подписаны с использованием минимальной версии RSA-2048 с SHA-256 (MD5 и SHA-1 запрещены) и убедитесь, что приложения и драйверы UEFI, не подписанные согласно этим требованиям, не будут выполняться (это политика по умолчанию для допустимых алгоритмов подписи). Если подпись изображений не найдена в авторизованной базе данных или найдена в запрещенной базе данных, образ не должен быть запущен, а вместо этого сведения о нем должны быть помещены в таблицу сведений о выполнении образа.

Некоторые сборки UEFI BIOS с поддержкой безопасной загрузки, включая Tiano Core, по умолчанию не прошли проверку подлинности UEFI, так как подписанные параметры UEFI не были доступны во время разработки безопасной загрузки. Это предоставляет уязвимую зону или уязвимость в безопасной загрузке UEFI.

2.1. Уязвимость

Эта уязвимость по-прежнему присутствует в EDK II и UDK2010 по состоянию на август 2013 года. Поддержку источника известно о проблеме, и подается ошибка. Любое встроенное ПО, производное от EDK II и UDK2010, должно проверить, как управляется проверка параметров диска. Поведение проверки параметров диска управляется значением PcdOptionRomImageVerificationPolicy PCD в пакете EDK II SecurityPkg.

Исходный код уязвимости TianoCore — файл SecurityPkg\SecurityPkg. dec:

## Pcd for OptionRom.
  #  Image verification policy settings:
  #  ALWAYS_EXECUTE                         0x00000000
  #  NEVER_EXECUTE                          0x00000001
  #  ALLOW_EXECUTE_ON_SECURITY_VIOLATION    0x00000002
  #  DEFER_EXECUTE_ON_SECURITY_VIOLATION    0x00000003
  #  DENY_EXECUTE_ON_SECURITY_VIOLATION     0x00000004
  #  QUERY_USER_ON_SECURITY_VIOLATION       0x00000005
gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x00|UINT32|0x00000001

Значение по умолчанию (0x00) — это ALWAYS_EXECUTE, что неправильно выполняет проверку подписанных драйверов в параметрах ROM для периферийных устройств надстройки. Это не идеальное значение для любой системы, реализующего функциональность безопасной загрузки UEFI.

Рекомендуемое значение (оптимальная безопасность): DENY_EXECUTE_ON_SECURITY_VIOLATION (0x04)

Рекомендуемое значение (оптимальная гибкость): QUERY_USER_ON_SECURITY_VIOLATION (0x05)

В EDK II & UDK2010 правильная практика написания кода использует механизм переопределения для изменения значений PCD для встроенного ПО платформы. Таким образом, значение для PcdOptionRomImageVerificationPolicy не должно быть изменено в SecurityPkg\SecurityPkg.dec. Значение переопределения должно быть задано в DSC-файле платформы. Ниже приведен пример использования Nt32Pkg\Nt32Pkg.dsc:

[PcdsFixedAtBuild]
gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x04

Переопределение PCD должно быть помещено в [PcdsFixedAtBuild] раздел DSC-файла. Точный механизм переопределения параметров может отличаться в зависимости от средств поставщика BIOS.

Примечание

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

3. Кто пострадал?

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

Ноутбуки, netbook, ультрабуки, & планшеты: большинство из них не затрагиваются. Варианты ROM обычно присутствуют на внутренних шинах, таких как PCI/e, ISA и их производные (ExpressCard, miniPCI, CardBus, PCCard, LPC, ThunderBolt и т. д.). Если ноутбук не имеет таких разоблачен, то его поверхность атаки значительно уменьшается. Кроме того, скорее всего, драйверы UEFI для подключенных ноутбуков интегрированы в основной том встроенного ПО BIOS, а не находятся на отдельном компьютере. Таким образом, большинство ноутбуков не подвергаются риску. Кроме того, если устаревшие параметры ROM отключены, похоже, UEFI поддерживает только roMs на основе PCI.

Однако если у вас есть настольный компьютер, системная плата или сервер с BIOS UEFI и реализация безопасной загрузки, может возникнуть проблема. На выделенном контроллере RAID-контроллера сервера или контроллере хранилища надстроек для SATA, FC и т. д. или сетевых карт Ethernet PCIe могут быть варианты РОМ. Контроллеры надстроек, поддерживающие широкий набор функциональных возможностей на серверах, являются общими, поэтому это особенно относится к пространству сервера.

Это может повлиять на 32-разрядные и 64-разрядные компьютеры, как класс 2, так и класс 3.

Если платформа безопасной загрузки поддерживает параметры ROM с устройств, не подключенных к платформе, и поддерживает возможность проверки подлинности этих параметров, то она должна поддерживать методы проверки параметров РОМ, описанные в разделе UDP и MTFTP, а также проверенные переменные EFI, описанные в спецификации UEFI 2.3.1 Errata C Section 7.2.

4. Как проверить его?

Если вы разрабатываете встроенное ПО и основано на Tiano Core, проверьте наличие уязвимости, упомянутой в разделе 2.1. Если вы используете другое встроенное ПО IBV, обратитесь к ним. Или вы можете сделать тест самостоятельно, как упоминалось ниже.

Кроме этого, вам понадобится следующее ПО:

  • Тестируемый компьютер с встроенного ПО UEFI
  • Устройство PCI с параметром ROM на тестируемом компьютере (например, видеоадаптер)
  • Убедитесь, что безопасная загрузка включена

Действия по тестированию:

  1. Вставьте добавление UEFI на карту PCI с UEFI Option ROM на тестируемый компьютер.

    Если вы используете видеоадаптер PCI для тестирования, подключите внешний монитор.

  2. Включите безопасную загрузку с помощью следующих параметров:

    • PK: ваш PK или самозаверяющий тест PK
    • KEK: MS KEK, PK-signed Fabrikam test KEK или другой KEK
    • DB: NULL. (Это должно быть ЗНАЧЕНИЕ NULL.)
    • DBX: NULL.
    • SecureBoot: переменная UEFI должна иметь значение true

  3. Перезагрузка компьютера

  4. Предполагался следующий результат:

    • Если встроенное ПО UEFI реализовано правильно, драйвер UEFI UEFI не будет загружаться, так как наличие параметра РОМ выполнит проверку встроенного ПО для сертификата. Так как «База данных» имеет значение NULL, драйвер UEFI не сможет загрузиться. Например, если вы используете видеоадаптер для тестирования, вы увидите, что на экране ничего не отображается.
    • Если встроенное ПО не реализовано правильно, драйвер UEFI загружается из параметров РОМ, так как встроенное ПО не проверяет наличие подписей в «Db». Например, если вы используете видеоадаптер для тестирования, вы увидите, что монитор, подключенный к параметру, будет отображаться.

    ! [примечание] Независимо от того, подписан ли драйвер UEFI UEFI, параметр ROM не будет загружаться, если база данных имеет значение NULL и включенА SB (PK и KEK регистрируются).

Ознакомьтесь с примерами сценариев, доступными в WHCK для создания PK и KEK. Приложение Б содержит примеры скриптов и дополнительные сведения.

Вы также можете ссылаться на приложение А для другого подхода к выполнению приведенного выше теста. Этот подход не требует установки для базы данных значения NULL, но требуется драйвер UEFI без знака UEFI из IHV.

5. Исправление

Если приведенный выше тест завершается сбоем, обратитесь к IBV, чтобы получить необходимые версии и настроить их для проверки параметров РОМ. Убедитесь, что встроенное ПО проходит тест. Для компьютеров, которые поставляются, вам потребуется выполнить безопасное обновление встроенного ПО. Ознакомьтесь с публикацией NIST 800-147 и(или) см. Windows 8.1 руководства по созданию и управлению ключами безопасной загрузки.

Вы можете протестировать компьютер и использовать Windows HCK в качестве средства тестирования (а не средства сертификации) для тестирования безопасного обновления встроенного ПО.

5.1. Подписывание драйвера

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

Подписывая каждый параметр драйвера РОМ по отдельности. Это приведет к разрыву формата ПАРАМЕТРОВ PCI. Перед созданием объединенного РОМ параметра необходимо подписать драйвер UEFI.

Перед вставкой драйвера UEFI в OpROM подпишите образ UEFI и протестируйте его с помощью secure Boot ON & OFF в оболочке UEFI (загрузите или выгрузите файл драйвера). Затем переместите подписанный драйвер в объединенный параметр ROM.

Вы можете направить IHV в центр Microsoft SysDev, чтобы получить их параметры UEFI, подписанные через службу, доступную через Центр SysDev.

5.2. Проверка обновления

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

6. Ресурсы

  • Спецификация инициализации платформы UEFI, стандарты тома 5, 1.2.1 Errata A: https://go.microsoft.com/fwlink/p/?linkid=220187
  • Соответствующие сведения из спецификации UEFI 2.3.1:
  • 2.5.1. Проблемы с устаревшими вариантами РОМ
  • 10. Протоколы –модель драйвера UEFI
  • 13.4.2: РОМ параметров PCI
  • 20. Виртуальная машина eFI Byte Code
  • 28. Обзор HII
  • 29. Протоколы HII
  • 30. Обработка конфигурации HII и протокол браузера
  • Центр обучения форума UEFI
  • Ресурсы UEFI IHV @ intel.com
  • Использование списка рассылки TianoCore edk2 для поддержки других разработчиков UEFI
  • TechNet: рекомендации по обеспечению безопасности предприятия: стратегии безопасности
  • Спецификация UEFI errata C
  • Группа доверенных вычислений
  • Пакет средств разработки Tianocore UEFI
  • Встроенное ПО UEFI
  • Intel Press: Beyond BIOS 2nd Edition
  • Руководство по созданию и управлению ключами безопасной загрузки
  • Проверка функциональных возможностей платформы обновления встроенного ПО Windows UEFI

Этот подход основан на получении средств из IHV, чтобы убедиться, что драйвер UEFI UEFI был подписан.

Кроме этого, вам понадобится следующее ПО:

  • Тестируемый компьютер с встроенного ПО UEFI
  • Устройство PCI с неподписанным драйвером ПАРАМЕТРОВ, подключенным к тестируемой пк (например, видеоадаптер)
  • Убедитесь, что безопасная загрузка включена
  • Средства IHV option IHV для обнаружения подписи в драйвере параметров РОМ, если он не очевиден, что драйвер ПАРАМЕТРОВ РОМ подписан или не подписан.

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

Если встроенное ПО реализовано неправильно, этот тест будет работать.

Приложение Б. Скрипты для включения безопасной загрузки с помощью базы данных NULL

Вы можете использовать текущий набор переменных безопасной загрузки (PK и KEK) или создать тестовые переменные для тестирования.

Ниже приведены шаги, используемые для создания тестового PK, KEK и установки значения NULL для базы данных. Убедитесь, что безопасная загрузка не включена; в противном случае для выполнения этих действий потребуются подписанные двоичные файлы UEFI.

Примечание

Мы задаем переменную безопасной загрузки — Db, KEK и PK в обратном порядке, чтобы нам не нужно подписывать двоичные файлы UEFI.

До этого шага компьютер должен находиться в режиме установки.

  1. Создание сертификатов KEK и PK

    Для этого шага требуется средство makecert.exe, доступное в пакете WINDOWS SDK.

    MakeCert.exe -cy authority -len 2048 -m 60 -a sha256  -pe -ss my -n "CN=DO NOT SHIP - Fabrikam Test KEK CA" Fabrikam_Test_KEK_CA.cer
MakeCert.exe -cy authority -len 2048 -m 60 -a sha256  -pe -ss my -n "CN=DO NOT SHIP - Fabrikam Test PK" TestPK.cer

  2. Скрипт для создания тестового PK

    Ниже приведен образец.

    this scripts demonstrates how to format the Platform key
NOTE The PK is actually set in the Enable_OEM_SecureBoot. ps1 script
Import-Module secureboot
$d = (pwd).Path
###############################################################################
Complete the following parameters
###############################################################################
$certname = "TestPK"
TODO change this path to where you have the PK.cer file
This is where you plugin the certificate generated by the HSM
$certpath = $d + "\" + $certname + ".cer"
Each signature has an owner SignatureOwner, which is a GUID identifying the agent which inserted the signature in the database.
Agents might include the operating PC or an OEM-supplied driver or application.
Agents may examine this field to understand whether they should manage the signature or not.
TODO replace with OEM SignatureOwner GUID.
You can use tools like Guidgen.exe tool in SDK or a similar tool to generate a GUID
$sigowner = "55555555-5555-5555-5555-555555555555"
$var = "PK"
$efi_guid = "{8BE4DF61-93CA-11d2-AA0D-00E098032B8C}"
$append = $false
###############################################################################
Everything else is calculated
###############################################################################
Workaround relative path bug
TODO substitute OEM with your OEM name
$siglist =  $certname + "_SigList. bin"
$serialization = $certname + "_SigList_Serialization_for_" + $var + ".bin"
$signature = $serialization + ".p7"
$appendstring = "set_"
$attribute = "0x27"
$example = "Example_SetVariable_Data-" + $certname + "_" + $appendstring + $var + ".bin"
Format-SecureBootUEFI -Name $var -SignatureOwner $sigowner -ContentFilePath $siglist -FormatWithCert -Certificate $certpath -SignableFilePath $serialization -Time 2011-05-21T13:30:00Z  -AppendWrite:$append
OutputFilePath - Specifies the name of the file created that contains the contents of what is set.
If this parameter is specified, then the content are not actually set, just stored into this file.
Please note if -OutputFilePath is provided the PK is not set like in this case. The master script sets it at the end.
Time - you can change the time below as long as it isn't in the future. Nothing wrong with keeping it as is.
Set-SecureBootUEFI -Name $var -Time 2011-05-21T13:30:00Z -ContentFilePath $siglist  -OutputFilePath $example -AppendWrite:$append

  3. Создание тестового KEK или использование собственного KEK изготовителя оборудования

    Для этого вы можете использовать собственный KEK изготовителя оборудования или скрипты из WHCK.

    Ниже приведен образец.

    script to add option OEM KEK
Import-Module secureboot
$d = (pwd).Path
###############################################################################
Complete the following parameters
###############################################################################
$certname = "Fabrikam_Test_KEK_CA"
TODO change this path to where you have the PK.cer file
This is where you plugin the certificate generated by the HSM
$certpath = $d + "\" + $certname + ".cer"
TODO change this path to where you have the OEM_KEK.cer file
Each signature has an owner SignatureOwner, which is a GUID identifying the agent which inserted the signature in the database.
Agents might include the operating system or an OEM-supplied driver or application.
Agents may examine this field to understand whether they should manage the signature or not.
TODO replace with OEM SignatureOwner GUID.
You can use tools like Guidgen.exe tool in SDK or a similar tool to generate a GUID
$sigowner = "00000000-0000-0000-0000-000000000000"
$var = "KEK"
$efi_guid = "{8BE4DF61-93CA-11d2-AA0D-00E098032B8C}"
$append = $false
###############################################################################
Everything else is calculated
###############################################################################
$siglist = $certname + "_SigList. bin"
$serialization = $certname + "_SigList_Serialization_for_" + $var + ".bin"
$signature = $serialization + ".p7"
if ($append -eq $false)
{
$appendstring = "set_"
$attribute = "0x27"
} else
{
$appendstring = "append_"
$attribute = "0x67"
}
$example = "Example_SetVariable_Data-" + $certname + "_" + $appendstring + $var + ".bin"
Format-SecureBootUEFI -Name $var -SignatureOwner $sigowner -ContentFilePath $siglist -FormatWithCert -CertificateFilePath $certpath -SignableFilePath $serialization -Time 2011-05-21T13:30:00Z -AppendWrite:$append
-Time You can change the time below as long as it isn't in the future. Nothing wrong with keeping it as is.
Set-SecureBootUEFI -Name $var -Time 2011-05-21T13:30:00Z -ContentFilePath $siglist -OutputFilePath $example -AppendWrite:$append

  4. Задайте для базы данных значение NULL и задайте KEK и PK

    Первое, что делает этот скрипт, — задать для базы данных значение NULL.

    Примечание

    Помните, что если ЦС Fabrikam Test KEK является единственным центром сертификации KEK (то есть нет ЦС Windows KEK), компьютер может загрузиться в Windows RE.

    Перед выполнением скрипта выполните команду Set-ExecutionPolicy Bypass -Force.

    Import-Module secureboot
try
{
Write-Host "Deleting db..."
Set-SecureBootUEFI -Name db -Time "2011-06-06T13:30:00Z" -Content $null
}
catch
{
}
Write-Host "Setting Fabrikam KEK..."
Set-SecureBootUEFI -Time 2011-05-21T13:30:00Z  -ContentFilePath Fabrikam_Test_KEK_CA_SigList.bin  -Name KEK
Write-Host "Setting self-signed Test PK..."
Set-SecureBootUEFI -Time 2011-05-21T13:30:00Z -ContentFilePath TestPK_SigList.bin  -Name PK
Write-Host "`n... operation complete.  `nSetupMode should now be 0 and SecureBoot should also be 0. Reboot and verify that Windows is correctly authenticated, and that SecureBoot changes to 1."

  5. Подключите карточку параметров и проверьте ее

    Тест должен пройти или завершиться сбоем на основе правильности встроенного ПО. Пример:

    Если параметр РОМ в встроенном ПО реализован правильно и используется видеоадаптер для тестирования, то на подключенном мониторе не должно отображаться.

    Однако если вы используете неправильное встроенное ПО, видеоадаптер должен иметь выходные данные на дисплее.

Руководство по созданию и управлению ключами безопасной загрузки Windows

Общие сведения о безопасной загрузке

Проверка функциональности платформы обновления встроенного ПО Windows UEFI

Supermicro: Intel Rapid Storage — настройка RAID для Legacy и UEFI

  • 2 ноября 2018

Во многих материнках Supermicro есть встроенный софтварный RAID контроллер. Для входя в управление нужно при загрузке нажать Ctrl+I. Но есть ньюанс — управлялка работает только в режиме Legacy. Legacy не поддерживает разделы более 2 Тб, как быть? Расскажу как настроить RAID и для Legacy и в UEFI.

Если вы не планируете разделов более 2 Тб, не заморачивайтесь и настройте загрузку в Legacy.

Legacy

При загрузке жмём DEL и попадаем в BIOS.

В разделе Boot меняем Boot Mode Select на Legacy:

В разделе Advanced выполняем SATA Configuration, Configure SATA as RAID:

Появляются дополнительные пункты настройки. Оставляем SATA RAID Option ROM/UEFI Driver как Legacy:

SATA/sSATA RAID Boot Select меняем на SATA Controller:

Сохраняемся:

Перезагружаем сервер, при загрузке жмём Ctrl+I, попадаем в раздел конфигурации Intel Rapid Storage Technology:

Создаём RAID. Я объединяю 4 диска в RAID0:

Status Normal:

Перезагружаемся, снова входим в BIOS. В разделе Boot в FIXED BOOT ORDER Priorities появляется возможность выбрать Hard Disk:Intel RAID0 — наш новый массив:

Можно пользоваться. Однако, если вы, вдруг, попытаетесь поставить Oracle Linux, то в инсталляторе не сможете создать раздел более 2 Тб. Что делать?

UEFI

Итак, для перехода в UEFi внесём в предыдущую инструкцию некоторые изменения. 

Выполняем все инструкции для Legacy и снова загружаемся в BIOS (Продвинутые могут смерджить инструкции и сократить количество перезагрузок). Вносим изменения в Advanced > SATA Configuration. Меняем  SATA RAID Option ROM/UEFI Driver на EFI:

В Boot > Boot Mode Select ставим DUAL. Можно, наверное, и просто UEFI, но тогда при перезагрузке не сможете попадать в раздел конфигурирования контроллера:

FIXED BOOT ORDER Priorities становится значительно больше. Двигаем все пункты с EFI вверх.

Теперь можно загружать инсталлятор Oracle Linux в режиме UEFI, он нормально видит RAID и может создать раздел более 2 Тб.

Ура, товарищи! Да здравствует то, во имя чего мы все приложили усилия!

 

Теги

  • Supermicro
  • special

💰 Поддержать проект

Похожие материалы

Олег
  • 20 августа 2018
  • Подробнее о Zabbix шаблон для мониторинга сервера Supermicro X10DRi

Делюсь полезным шаблоном для мониторинга сервера Supermicro X10DRi.   Если быть более точным, то у сервера нет имени, у него материнка X10DRi-T и корпус 4 юнита. Только что собрал. В шаблоне 5 приложений, 53 элемента данных, 39 триггеров и 5 графиков. Мониторим по IPMI. 

Теги

  • Zabbix
  • Supermicro
  • special
Олег
  • 13 августа 2018
  • Подробнее о Supermicro — используем слоты Rear 2.5 x 2 как зеркало под ОС

Имеется сервер Supermicro 4U. И серверная полка. Идея в следующем: 2 слота сзади сервера использовать под систему, объединив для отказоустойчивасти в зеркало — RAID1.

Теги

  • Supermicro
  • special
Олег
  • 20 июля 2018
  • Подробнее о Zabbix шаблон для мониторинга сервера Supermicro SYS-6018R-MT

Делюсь полезным шаблоном для мониторинга сервера Supermicro SYS-6018R-MT. В шаблоне 44 элемента данных, 22 триггера и 5 графиков. Мониторим по IPMI.

Теги

  • Zabbix
  • Supermicro
  • special

Чтиво на ночь

UEFI Validation Option ROM Руководство

  • Статья
  • 17 минут на чтение

Версия 1.3

Этот документ помогает OEM- и ODM-производителям подтвердить, что их встроенное ПО проверяет подписи своего дополнительного ПЗУ в рамках цепочки доверия Secure Boot.

В этом руководстве предполагается, что вы знакомы с основами UEFI, базовыми понятиями о безопасной загрузке (главы 1, 2, 13, 20 и 27 спецификации UEFI) и модели безопасности PKI.

Введение

Дополнительные ПЗУ (или OpROM) — это микропрограммы, запускаемые BIOS ПК во время инициализации платформы. Обычно они хранятся на сменной плате, хотя могут располагаться и на системной плате.

К устройствам, для которых обычно требуются дополнительные ПЗУ, относятся видеокарты, сетевые адаптеры и драйверы устройств хранения данных для модулей RAID. Эти дополнительные ПЗУ также обычно предоставляют драйверы прошивки для ПК.

Они включают в себя различные типы драйверов встроенного ПО, в том числе устаревшие версии PC-AT, открытое встроенное ПО и дополнительные ПЗУ EFI. Примеры драйверов встроенного ПО включают Video BIOS на видеокартах, загрузочные драйверы PXE для адаптеров Ethernet и драйверы хранения на контроллерах RAID. Эти устройства обычно имеют дополнительные ПЗУ с драйверами встроенного ПО.

Унифицированный расширяемый интерфейс встроенного ПО (UEFI) поддерживает дополнительные ПЗУ режима Legacy.

В соответствии с последней спецификацией UEFI (в настоящее время в 2.3.1 Errata C — раздел 2.5.1.2), дополнительные ПЗУ ISA (устаревшие) не являются частью спецификации UEFI. В рамках данного обсуждения будут рассматриваться только дополнительные ПЗУ, совместимые с UEFI, на базе PCI.

Дополнительные ПЗУ можно использовать, когда невозможно встроить прошивку устройства в прошивку ПК. Когда дополнительное ПЗУ содержит драйвер, IHV может использовать этот драйвер и хранить драйвер и устройство в одном месте.

В этом документе рассказывается о том, зачем вам нужно проверять дополнительные ПЗУ, и показаны некоторые способы ее выполнения.

Поддержка как UEFI BIOS, так и Legacy BIOS

Многие производители создают устройства с дополнительными ПЗУ и микропрограммами для многих типов ПК. Общие комбо включают в себя:

  • Только старое ПЗУ
  • Собственная оперативная память UEFI
  • Устаревшее ПЗУ + UEFI EBC OpROM
  • Устаревшее ПЗУ + UEFI x64 OpROM
  • Устаревшее ПЗУ + UEFI x64 + UEFI IA32
  • Устаревшее ПЗУ + UEFI x64 + UEFI IA32 + UEFI EBC OpROM

UEFI BIOS может загружать и выполнять устаревшие драйверы встроенного ПО, если включен модуль поддержки совместимости (CSM). Обратите внимание, что когда безопасная загрузка включена, выполнение модуля поддержки совместимости и устаревших ПЗУ запрещено, поскольку устаревшие драйверы встроенного ПО не поддерживают аутентификацию. Если формат дополнительного ПЗУ в конфигурации BIOS установлен на устаревшее ПЗУ, всегда будет использоваться устаревшее ПЗУ. на устройстве.

Если для формата дополнительного ПЗУ установлено значение UEFI Compatible , будет использоваться более новое ПЗУ EFI, если оно имеется, и устаревшее ПЗУ, если оно отсутствует.

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

1. UEFI и дополнительные ПЗУ

Рис. 2. Вопросы безопасности драйвера UEFI, источник: UEFI 2. 3.1 Errata C информация от партнеровf:

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

Сюда входят:

  • Защита области хранения, где хранятся эти драйверы.
  • Защита средств выбора этих драйверов.
  • Защита среды выполнения этих драйверов от непроверенных драйверов.
  • Структуры данных, используемые этими драйверами, не должны быть повреждены неавторизованными драйверами, пока они все еще используются.

Компоненты, такие как User Identity Manager, драйверы учетных данных пользователя и встроенные драйверы, могут быть расположены в безопасном месте, например на защищенном от записи флэш-накопителе, которому доверяет политика платформы.

Некоторые другие драйверы могут находиться в незащищенных местах хранения, таких как дополнительные ПЗУ или разделы жесткого диска, и их можно легко заменить. Эти драйверы должны быть проверены.

Например, либо политика платформы по умолчанию должна успешно проверять драйверы, перечисленные в параметрах загрузки Driver####, либо пользователь должен быть идентифицирован перед обработкой этих драйверов. В противном случае выполнение драйвера следует отложить. Если профиль пользователя изменен с помощью последующего вызова функции Identify() или с помощью динамической аутентификации, параметры Driver#### могут больше не обрабатываться.

База данных профилей пользователей закрывается с использованием различных сигнальных событий UEFI в зависимости от возможности ее защиты.

Драйверы UEFI и дополнительные ПЗУ UEFI будут выполняться только для устройств в пути загрузки.

Спецификация PCI позволяет использовать несколько образов дополнительных ПЗУ на одном устройстве. Эти дополнительные ПЗУ могут быть Legacy x86 и UEFI. Микропрограмма UEFI устанавливает политику платформы для выбора дополнительного ПЗУ. Это может привести к тому, что ПЗУ дополнительного адаптера будет работать как собственное управляющее устройство.

Встроенное ПО проверяет подписи на этапах BDS и DXE. Последовательность событий такова:

  1. Инициализация PCI и производных шин
  2. Пробные устройства PCI для дополнительных ПЗУ
  3. Найденные дополнительные ПЗУ отображаются в памяти
  4. Фаза DXE загружает любые драйверы UEFI в ПЗУ

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

На ПК с включенной безопасной загрузкой драйверы дополнительных ПЗУ представляют угрозу безопасности, если они не подписаны или не проверены. Проверка подписи для дополнительных ПЗУ является требованием WHCK. То же самое верно и при обслуживании дополнительных ПЗУ, чтобы убедиться, что обновление проверено перед установкой.

Из спецификаций и политик программы совместимости оборудования Windows версии 1809:

  1. Проверка целостности кода встроенного ПО . Микропрограмма, установленная OEM и либо доступная только для чтения, либо защищенная с помощью безопасного процесса обновления микропрограммы, как определено выше, может считаться защищенной. Системы должны проверять, что все незащищенные компоненты встроенного ПО, драйверы UEFI и приложения UEFI подписаны с использованием как минимум RSA-2048 с SHA-256 (MD5 и SHA-1 запрещены), а также проверять, что приложения и драйверы UEFI, не подписанные в соответствии с этими требования не будут выполняться (это политика по умолчанию для приемлемых алгоритмов подписи). Если сигнатура изображения не найдена в авторизованной базе данных или обнаружена в запрещенной базе данных, образ не должен запускаться, а вместо этого информация о нем размещается в таблице информации об исполнении образа.

Некоторые сборки UEFI BIOS с поддержкой безопасной загрузки, включая Tiano Core, по умолчанию не аутентифицировали дополнительные ПЗУ UEFI, поскольку подписанные дополнительные ПЗУ UEFI были недоступны во время разработки безопасной загрузки. Это раскрывает поверхность атаки/уязвимость в безопасной загрузке UEFI.

2.1. Уязвимость

Эта уязвимость по-прежнему присутствовала в EDK II и UDK2010 по состоянию на август 2013 г. Разработчикам исходного кода известно об этой проблеме, и сообщение об ошибке было зарегистрировано. Любая прошивка, производная от EDK II и UDK2010, должна проверять, как осуществляется проверка дополнительного ПЗУ. Поведение при проверке дополнительного ПЗУ управляется значением PCD PcdOptionRomImageVerificationPolicy в пакете EDK II SecurityPkg.

Исходный код уязвимости TianoCore находится в файле SecurityPkg\SecurityPkg.dec:

 ## Pcd для OptionRom.
  # Настройки политики проверки изображений:
  #  ALWAYS_EXECUTE                        0x00000000
  #  NEVER_EXECUTE                          0x00000001
  #  ALLOW_EXECUTE_ON_SECURITY_VIOLATION    0x00000002
  #  DEFER_EXECUTE_ON_SECURITY_VIOLATION    0x00000003
  #  DENY_EXECUTE_ON_SECURITY_VIOLATION     0x00000004
  #  QUERY_USER_ON_SECURITY_VIOLATION       0x00000005
gEfiSecurityPkgTokenSpaceGuid. PcdOptionRomImageVerificationPolicy|0x00|UINT32|0x00000001

Значение по умолчанию (0x00) — ALWAYS_EXECUTE, которое не выполняет должным образом проверку подписанных драйверов в дополнительных ПЗУ для дополнительных периферийных устройств. Это не идеальное значение для любой системы, реализующей функциональность безопасной загрузки UEFI.

Рекомендуемое значение (наилучшая безопасность): deny_execute_on_security_violation (0x04)

Рекомендуемое значение (наилучшая гибкость): Query_user_on_security_violation (0x05)

enk eDk прошивка платформы. Таким образом, значение PcdOptionRomImageVerificationPolicy не следует изменять в SecurityPkg\SecurityPkg.dec . Значение переопределения должно быть установлено в файле DSC платформы. Ниже показан пример использования Nt32Pkg\Nt32Pkg.dsc:

 [PcdsFixedAtBuild]
gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x04

Переопределение PCD должно быть помещено в раздел [PcdsFixedAtBuild] файла DSC. Точный механизм переопределения параметров может различаться в зависимости от инструментов поставщика BIOS.

Примечание

Эта уязвимость может существовать в ранних реализациях UEFI Secure Boot BIOS от независимых поставщиков BIOS. Обратитесь к поставщику BIOS, чтобы определить, может ли быть затронута ваша версия.

3. Кто затронут?

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

Ноутбуки, нетбуки, ультрабуки и планшеты: большинство из них не затронуты . Дополнительные ПЗУ обычно присутствуют на шинах объединительной платы, таких как PCI/e, ISA и их производных (ExpressCard, miniPCI, CardBus, PCCard, LPC, ThunderBolt и т. д.). Если на ноутбуке нет ни одного из них, то его поверхность атаки значительно уменьшается. Более того, вполне вероятно, что драйверы UEFI для встроенных компонентов ноутбука интегрированы в основной том прошивки BIOS, а не находятся в отдельном дополнительном ПЗУ. Таким образом, большинство ноутбуков не подвержены риску. Кроме того, когда устаревшие дополнительные ПЗУ отключены, похоже, что UEFI поддерживает только дополнительные ПЗУ на основе PCI.

Однако, если у вас есть настольный компьютер, материнская плата или сервер с UEFI BIOS и безопасная загрузка, вы можете быть затронуты. На выделенном RAID-контроллере сервера или дополнительном контроллере хранилища для сетевых карт SATA, FC и т. д. или Ethernet PCIe могут быть дополнительные ПЗУ. Контроллеры надстроек, поддерживающие широкий спектр функций на серверах, широко распространены, поэтому это особенно относится к серверному пространству.

Это потенциально может повлиять на 32-разрядные и 64-разрядные ПК как класса 2, так и класса 3.

Если платформа с безопасной загрузкой поддерживает дополнительные ПЗУ с устройств, не подключенных к платформе постоянно, и поддерживает возможность проверки подлинности этих дополнительных ПЗУ, то она должна поддерживать методы проверки дополнительных ПЗУ, описанные в разделе «Сетевые протоколы — UDP и MTFTP, а также аутентифицированные переменные EFI». описано в спецификации UEFI 2.3.1 Errata C, раздел 7.2.

4. Как это проверить?

Если вы разрабатываете прошивку и она основана на Tiano Core, пожалуйста, проверьте наличие уязвимости, упомянутой в разделе 2.1. Если вы используете прошивку другого IBV, пожалуйста, уточните у них. Или вы можете сделать тест самостоятельно, как указано ниже.

Вам потребуется следующее:

  • Тестируемый ПК с прошивкой UEFI
  • Устройство PCI с дополнительным ПЗУ на тестируемом ПК (например, видеокарта)
  • Убедитесь, что безопасная загрузка включена

Шаги для тестирования:

  1. Вставьте плату расширения UEFI на PCI с дополнительным ПЗУ UEFI в тестируемый ПК.

    Если вы используете видеокарту PCI для тестирования, подключите внешний монитор.

  2. Включить безопасную загрузку с параметрами ниже:

    • ПК: Ваш ПК или самоподписанный тестовый ПК
    • KEK: MS KEK, тест Fabrikam с подписью PK или другой KEK
    • БД: НУЛЕВОЕ. (Это должно быть NULL.)
    • DBX: НУЛЬ.
    • SecureBoot: для переменной UEFI должно быть установлено значение true

  3. Перезагрузите ПК

  4. Ожидайте следующий результат:

    • Если прошивка UEFI реализована правильно, драйвер дополнительного ПЗУ UEFI не загрузится, так как наличие дополнительного ПЗУ заставит прошивку проверять «Db» на наличие сертификата. Поскольку «Db» имеет значение NULL, драйвер UEFI не загрузится. Например, если вы используете видеокарту для тестирования, вы увидите, что на дисплее ничего не отображается.
    • Если прошивка реализована неправильно, драйвер UEFI загрузится из дополнительного ПЗУ, поскольку прошивка не проверяет подписи в «Db». Например, если вы используете видеокарту для тестирования, вы увидите, что монитор, подключенный к дополнительной карте ПЗУ, будет иметь изображение.

    ![примечание]
    Неважно, подписан ли драйвер дополнительного ПЗУ UEFI или нет, дополнительный ПЗУ не будет загружаться, если DB имеет значение null и включен SB (зарегистрированы PK и KEK).

См. образцы сценариев, доступные в WHCK, для создания PK и KEK. Приложение B содержит примеры сценариев и более подробную информацию.

Вы также можете обратиться к Приложению A, чтобы узнать о другом подходе к выполнению вышеуказанного теста. Этот подход не требует установки для БД значения Null, но требует неподписанного драйвера дополнительного ПЗУ UEFI от IHV.

5. Как это исправить

Если вышеуказанный тест не пройден, обратитесь к своему IBV, чтобы получить необходимые версии и настроить их для проверки дополнительных ПЗУ. Убедитесь, что прошивка проходит тест. Для поставляемых ПК вам необходимо выполнить безопасное обновление прошивки. См. публикацию NIST 800-147 и/или руководство по созданию и управлению ключами безопасной загрузки Windows 8.1.

Вы можете протестировать ПК и использовать Windows HCK в качестве инструмента тестирования (а не инструмента сертификации) для тестирования безопасного обновления микропрограммы.

5.1. Подписание драйвера

Если вы обнаружите, что у вас могут быть неподписанные драйверы на дополнительных ПЗУ UEFI, прочитайте ниже, как это исправить.

Подпишите каждый драйвер дополнительного ПЗУ отдельно. Это нарушит формат PCI Option ROM. Вам нужно только подписать драйвер UEFI перед созданием комбинированного дополнительного ПЗУ.

Прежде чем вставлять драйвер UEFI в OpROM, подпишите образ UEFI и протестируйте его, включив и выключив безопасную загрузку в оболочке UEFI (загрузите/выгрузите файл драйвера). Затем поместите подписанный драйвер в комбинированное дополнительное ПЗУ.

Вы можете направить свой IHV в центр Microsoft SysDev, чтобы подписать дополнительные ПЗУ UEFI через службу, доступную через центр SysDev.

5.2. Проверка обновления

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

6. Ресурсы

  • Спецификация инициализации платформы UEFI, том 5, стандарты, 1. 2.1 Errata A: https://go.microsoft.com/fwlink/p/?linkid=220187
  • Соответствующая информация из спецификации UEFI 2.3.1:
  • 2.5.1: Проблемы с устаревшим дополнительным ПЗУ
  • 10: протоколы — модель драйвера UEFI
  • 13.4.2: Дополнительные ПЗУ PCI
  • 20: Виртуальная машина с байт-кодом EFI
  • 28: Обзор HII
  • 29: Протоколы HII
  • 30: Обработка конфигурации HII и протокол браузера
  • Учебный центр Форума UEFI
  • Ресурсы UEFI IHV @ intel.com
  • Используйте список рассылки TianoCore edk2-devel для получения поддержки от других разработчиков UEFI
  • TechNet: передовой опыт корпоративной безопасности: стратегии безопасности
  • Ошибки спецификации UEFI C
  • Доверенная вычислительная группа
  • Комплект для разработки Tianocore UEFI
  • Прошивка UEFI
  • Intel Press: Beyond BIOS 2nd Edition
  • Руководство по созданию ключей безопасной загрузки и управлению ими
  • Проверка функциональности платформы обновления встроенного ПО Windows UEFI

Этот подход основан на получении инструментов от IHV, чтобы убедиться, что драйвер дополнительного ПЗУ UEFI подписан.

Вам потребуется следующее:

  • Тестируемый ПК с прошивкой UEFI
  • Устройство PCI с неподписанным драйвером дополнительного ПЗУ, подключенным к тестируемому ПК (например, видеокарта)
  • Убедитесь, что безопасная загрузка включена
  • Инструменты Option IHV для обнаружения подписи драйвера дополнительного ПЗУ, если не очевидно, подписан драйвер дополнительного ПЗУ или нет

Если прошивка реализована правильно, а дополнительное ПЗУ не подписано, карта должна не пройти проверку прошивки и не загрузить драйвер на карту. ПК должен сообщить код ошибки, такой как EFI_IMAGE_EXECUTION_AUTH_SIG_FOUND . Если вы используете видеокарту, вы можете увидеть, что на ПК просто черный экран, поскольку драйвер дополнительного ПЗУ не загружен.

Если прошивка реализована неправильно, этот тест будет работать.

Приложение B: Сценарии для включения безопасной загрузки с NULL db

Вы можете либо использовать текущий набор переменных безопасной загрузки (PK и KEK), либо сгенерировать тестовые для проверки.

Ниже приведены шаги, используемые для создания тестовых PK, KEK и установки Db в NULL. Убедитесь, что безопасная загрузка не включена; в противном случае для этих шагов потребуются подписанные bin-файлы UEFI.

Примечание

Мы устанавливаем переменную безопасной загрузки — Db, KEK и PK в обратном порядке, чтобы нам не нужно было подписывать bin-файлы UEFI.

Перед этим ПК должен находиться в режиме настройки.

  1. Создание сертификатов KEK и PK

    Для этого шага требуется инструмент makecert.exe, доступный в Windows SDK.

     MakeCert.exe -cy Authority -len 2048 -m 60 -a sha256 -pe -ss my -n «CN=НЕ ПОСТАВЛЯТЬ — Fabrikam Test KEK CA» Fabrikam_Test_KEK_CA.cer
MakeCert.exe -cy Authority -len 2048 -m 60 -a sha256 -pe -ss my -n "CN=DO NOT SHIP - Fabrikam Test PK" TestPK.cer

  2. Скрипт для создания тестового ПК

    Образец приведен ниже.

     этот скрипт демонстрирует, как отформатировать ключ платформы
ПРИМЕЧАНИЕ Фактически ПК задается в сценарии Enable_OEM_SecureBoot. ps1.
Безопасная загрузка Import-Module
$d = (пароль).Путь
################################################### ##############################
Заполните следующие параметры
################################################### ##############################
$certname = "ТестПК"
TODO измените этот путь на тот, где у вас есть файл PK.cer
Здесь вы подключаете сертификат, сгенерированный HSM.
$certpath = $d + "\" + $certname + ".cer"
У каждой подписи есть владелец SignatureOwner, который представляет собой идентификатор GUID, идентифицирующий агента, вставившего подпись в базу данных.
Агенты могут включать в себя работающий ПК или драйвер или приложение, поставляемые OEM.
Агенты могут изучить это поле, чтобы понять, должны ли они управлять подписью или нет.
TODO заменить на OEM SignatureOwner GUID.
Вы можете использовать такие инструменты, как Guidgen.exe в SDK или аналогичный инструмент для создания GUID.
$sigowner = "55555555-5555-5555-5555-555555555555"
$вар = "ПК"
$efi_guid = "{8BE4DF61-93CA-11d2-AA0D-00E098032B8C}"
$дополнение = $ложь
################################################### ##############################
Все остальное рассчитывается
################################################### ##############################
Обход ошибки относительного пути
TODO заменить OEM на ваше имя OEM
$siglist = $certname + "_SigList. bin"
$serialization = $certname + "_SigList_Serialization_for_" + $var + ".bin"
$подпись = $сериализация + ".p7"
$appendstring = "set_"
$ атрибут = "0x27"
$example = "Example_SetVariable_Data-" + $certname + "_" + $appendstring + $var + ".bin"
Format-SecureBootUEFI -Name $var -SignatureOwner $sigowner -ContentFilePath $siglist -FormatWithCert -Certificate $certpath -SignableFilePath $serialization -Time 2011-05-21T13:30:00Z -AppendWrite:$append
OutputFilePath — указывает имя созданного файла, содержащего содержимое того, что установлено.
Если указан этот параметр, то содержимое на самом деле не устанавливается, а просто сохраняется в этом файле.
Обратите внимание, что если указан параметр -OutputFilePath, PK не устанавливается, как в этом случае. Основной сценарий устанавливает его в конце.
Время — вы можете изменить время ниже, если оно не в будущем. Нет ничего плохого в том, чтобы оставить все как есть.
Set-SecureBootUEFI -Name $var -Time 2011-05-21T13:30:00Z -ContentFilePath $siglist -OutputFilePath $example -AppendWrite:$append

  3. Создайте тестовый KEK или используйте собственный OEM KEK

    Для этого можно использовать собственный OEM KEK или сценарии из WHCK.

    Образец приведен ниже.

    Скрипт

     для добавления опции OEM KEK
Безопасная загрузка Import-Module
$d = (пароль).Путь
################################################### ##############################
Заполните следующие параметры
################################################### ##############################
$certname = "Fabrikam_Test_KEK_CA"
TODO измените этот путь на тот, где у вас есть файл PK.cer
Здесь вы подключаете сертификат, сгенерированный HSM.
$certpath = $d + "\" + $certname + ".cer"
TODO измените этот путь на тот, где у вас есть файл OEM_KEK.cer.
У каждой подписи есть владелец SignatureOwner, который представляет собой идентификатор GUID, идентифицирующий агента, вставившего подпись в базу данных.
Агенты могут включать в себя операционную систему или драйвер или приложение, поставляемые OEM.
Агенты могут изучить это поле, чтобы понять, должны ли они управлять подписью или нет.
TODO заменить на OEM SignatureOwner GUID.
Вы можете использовать такие инструменты, как Guidgen. exe в SDK или аналогичный инструмент для создания GUID.
$sigowner = "00000000-0000-0000-0000-000000000000"
$вар = "КЕК"
$efi_guid = "{8BE4DF61-93CA-11d2-AA0D-00E098032B8C}"
$дополнение = $ложь
################################################### ##############################
Все остальное рассчитывается
################################################### ##############################
$siglist = $certname + "_SigList.bin"
$serialization = $certname + "_SigList_Serialization_for_" + $var + ".bin"
$подпись = $сериализация + ".p7"
если ($append -eq $false)
{
$appendstring = "set_"
$ атрибут = "0x27"
} еще
{
$appendstring = "добавить_"
$ атрибут = "0x67"
}
$example = "Example_SetVariable_Data-" + $certname + "_" + $appendstring + $var + ".bin"
Format-SecureBootUEFI -Name $var -SignatureOwner $sigowner -ContentFilePath $siglist -FormatWithCert -CertificateFilePath $certpath -SignableFilePath $serialization -Time 2011-05-21T13:30:00Z -AppendWrite:$append
-Время Вы можете изменить время ниже, если это не в будущем.  Нет ничего плохого в том, чтобы оставить все как есть.
Set-SecureBootUEFI -Name $var -Time 2011-05-21T13:30:00Z -ContentFilePath $siglist -OutputFilePath $example -AppendWrite:$append

  4. Установите для Db значение Null и установите KEK и PK

    Первое, что делает этот скрипт, устанавливает Db в Null.

    Примечание

    Имейте в виду, что если ЦС Fabrikam Test KEK является единственным присутствующим ЦС KEK (что означает отсутствие ЦС Windows KEK), ПК может загрузиться в Windows RE.

    Перед выполнением скрипта запустите «Set-ExecutionPolicy Bypass -Force»

     Безопасная загрузка модуля импорта
пытаться
{
Write-Host "Удаление базы данных..."
Set-SecureBootUEFI -Name db -Time "2011-06-06T13:30:00Z" -Content $null
}
ловить
{
}
Write-Host "Настройка Fabrikam KEK..."
Set-SecureBootUEFI -Time 2011-05-21T13:30:00Z -ContentFilePath Fabrikam_Test_KEK_CA_SigList.bin -Name KEK
Write-Host "Настройка самоподписанного тестового PK. .."
Set-SecureBootUEFI -Time 2011-05-21T13:30:00Z -ContentFilePath TestPK_SigList.bin -Name PK
Write-Host "`n... операция завершена. `nSetupMode теперь должен быть равен 0, а SecureBoot также должен быть равен 0. Перезагрузитесь и убедитесь, что Windows правильно аутентифицирована, а SecureBoot изменяется на 1."

  5. Вставьте карту дополнительного ПЗУ и проверьте

    Тест должен пройти или не пройти в зависимости от правильности микропрограммы. Например:

    Если дополнительное ПЗУ в прошивке реализовано правильно, и вы используете видеокарту для тестирования, то на подключенном мониторе не должно быть изображения.

    Однако, если вы используете неправильную прошивку, видеокарта должна иметь вывод на дисплей.

Руководство по созданию ключа безопасной загрузки Windows и управлению им

Обзор безопасной загрузки

Проверка функциональности платформы обновления прошивки UEFI Windows

Что вам нужно знать

Перейти к содержимому

Дарек Фэнтон·Категории: Техническое объяснение·Опубликовано: 30 июля 2021 г. ·3,3 мин чтения·

С выпуском Windows 11 в октябре 2021 года требования к оборудованию стали популярной темой. Список минимальных требований для Windows 11 можно найти в нашем блоге о требованиях к оборудованию для Windows 11, но в этом блоге мы сосредоточимся на использовании UEFI для Windows 11. 

Требуется ли для Windows 11 UEFI?

Корпорация Майкрософт решила использовать преимущества UEFI в Windows 11, чтобы обеспечить пользователям повышенную безопасность. Это означает, что Windows 11 ДОЛЖНА работать с UEFI и несовместима с BIOS или устаревшим режимом совместимости. При проверке того, поддерживает ли ваш компьютер Windows 11, вы также должны включить безопасную загрузку, которая является функцией только UEFI.

Поддержка TPM 2.0 также является требованием для Windows 11. Большинство современных процессоров будут иметь встроенный элемент безопасности, поддерживающий спецификацию TPM 2.0 (для Intel это называется «PTT», а для AMD — «fTPM»). Эти функции также может потребоваться включить в меню UEFI, прежде чем система сможет загрузить Windows 11.

Как проверить, используете ли вы UEFI

Вы можете проверить режим установки Windows, прежде чем включать безопасную загрузку, выполнив поиск приложения «Информация о системе» в строке поиска и проверив настройки режима BIOS. Если ваша система сообщает, что она находится в режиме UEFI, значит, все в порядке. Однако, если он не сообщает о том, что находится в режиме UEFI, значит, вы находитесь в режиме, не поддерживаемом Windows 11.

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

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

Microsoft также предоставляет приложение для проверки работоспособности ПК, которое можно использовать для проверки готовности системы к Windows 11.

Разница между BIOS и UEFI

Термины BIOS и UEFI часто используются взаимозаменяемо, но на самом деле это два разных поколения компьютерных инструкций на основе встроенного ПО. BIOS, что означает базовую систему ввода-вывода, является старшим из двух наборов инструкций. В 2007 году BIOS был в значительной степени заменен на UEFI, что означает Unified Extensible Firmware Interface. UEFI предлагает несколько важных преимуществ по сравнению с BIOS, включая расширенные функции безопасности, но многие материнские платы UEFI по-прежнему предлагают поддержку BIOS в устаревшем режиме. Это называется «UEFI с CSM» (модуль поддержки совместимости). Сначала вам может потребоваться отключить CSM, чтобы поддерживать функции безопасной загрузки.

В нашем видеоролике Tech Edge ниже мы разбираем разницу между BIOS и UEFI.

Ключевой вывод об UEFI для Windows 11

Главный вывод здесь заключается в том, что для установки Windows 11 в вашей системе должен быть установлен режим UEFI. Если вы использовали устаревший режим в Windows 10, вам необходимо переключиться в UEFI, а затем выполните новую установку, прежде чем пытаться выполнить обновление до Windows 11.

Если у вас есть какие-либо вопросы о UEFI для Windows 11, свяжитесь с нашей командой для получения помощи сегодня.

Этот блог был первоначально опубликован 30 июля 2021 г. Он был обновлен для содержания 10 сентября 2022 г. hub/what-are-the-windows-11-hardware-requirements/

  • Подробнее о UEFI и BIOS:
    https://www.onlogic.com/company/io-hub/uefi-building-better-bios/
  • Найдите руководства пользователя OnLogic на нашем сайте поддержки:
    https://www. onlogic.com/support/
  • Зачем Windows 11 нужна безопасная загрузка:
    https://nerdschalk.com/why-windows-11-needs-secure-boot/
  • Включение UEFI и безопасной загрузки:
    https://nerdschalk.com/windows-11- без-UEFI-все-вам-нужно-знать/

    • Получайте последние технические обновления

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

    Об авторе: Дарек Фэнтон

    Дарек — менеджер по коммуникациям в OnLogic. Его страсть как к журналистике, так и к технологиям привела его из отделов новостей местных газет в производственный цех IBM. Благодаря своему опыту сбора новостей он всегда находится в поиске новейших технологий и лучших способов поделиться этой информацией с читателями. В дополнение к своей любви к словам, Дарек — меломан, жонглер и большой любитель ужасных шуток.

    Читайте также: