Launch pxe oprom в биосе что это

Launch pxe oprom в биосе что это

Сообщения: 513
Благодарности: 3

Конфигурация компьютера
Процессор: QuadCore Intel Core i7-2600, 3500 MHz (35 x 100)
Материнская плата: Gigabyte GA-P67A-UD5-B3
Память: 12 GB (DDR3-1333 DDR3 SDRAM)
HDD: Corsair force GT 3 — 120gb x 2 (RAID 0), MyBookLive 3 TB
Видеокарта: NVIDIA GeForce GTX 580
Звук: Realtek
Блок питания: Thermaltake Purepower RX 700W
CD/DVD: оно еще выпускается?
Монитор: LG Flatron E2340T
ОС: Windows 7, x64
Индекс производительности Windows: 7,6, произв.графики 7.8

вообщем лаптоп — пациент.
BIOS: Aptio Setup Utility

Launch CSM: Enabled
Boot option filter: Legacy Only
Launch PXE OpROM policy:
Launch Storage OpROM policy
Launch Video OpROM policy
Other PCI device ROM priority:

вообщем где упоминание про видео, было выбрано Do not lounch или UEFI точно не помню.
теперь ноут запускается, но экран выключен, до винды добратся не могу, не стратует. F11,F9, del при запуске пробовал, ни загрузочные диски, ни БИОС не стартует.

по HDMI пробовал подрубиться, не видит устройство.

подскажите, как вырулить из ситуации.

Realtek PXE OPROM что это в биосе?

Всем привет Увидели пункт Realtek PXE OPROM в биосе и теперь думаете что это такое? Значит ребята, пункт Realtek PXE OPROM это функция загрузки операционки по сети. Также нашел инфу, что данная функция является аналогом такой штуки как BootROM

Вот еще нашел инфу, так бы сказать ориентированную на спецов. Пишется что Realtek PXE OPROM это опция доступа к коду среды PXE, который записан во флеш-памяти сетевой карты. При помощи данного когда можно выполнить загрузку или установку операционной системы. Короче винда может загрузиться по сети, и при этом не нужно ни жесткого диска ни CD/DVD диска, ни флешки, вообще ничего не нужно. Вообще тема эта интересная и фантастическая, если можно так сказать

Еще я узнал, что опция может также называться и LAN Option ROM, OnBoard LAN Boot ROM, Intel PXE OPROM, Boot From Onboard LAN. Эта опция может принимать два значения, это Disabled (отключено) ну и Enabled (включено).

Вот пример как отображается опция PXE OPROM в биосе устаревшего образца:

Ну и еще пример:

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

Руководство по выбору ПЗУ для проверки UEFI

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

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

Введение

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

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

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

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

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

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

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

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

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

• Только для ПЗУ прежних версий
• UEFI Native OpROM
• Устаревшая версия ПЗУ + UEFI EBC OpROM
• Устаревшая версия ПЗУ + UEFI x64 OpROM
• Устаревшая версия ПЗУ + UEFI x64 + UEFI IA32
• Устаревшая версия ПЗУ + UEFI x64 + UEFI IA32 + UEFI EBC OpROM

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

Если для параметра Option ROM задано значение Совместимо с UEFI, он будет использовать более новый ПЗУ EFI , если таковой имеется, и устаревший ПЗУ, если он отсутствует.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Оператор задачи

Некоторые сборки BIOS UEFI с поддержкой безопасной загрузки, включая 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, которое неправильно выполняет проверку подписанных драйверов в дополнительных ПЗУ для периферийных устройств надстроек. Это не идеальное значение для любой системы, реализующих функции безопасной загрузки 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, который не подписан. Кроме того, встроенное ПО для обеспечения совместимости с работой существующих карт может иметь уязвимость системы безопасности, которая не проверяет параметры ПЗУ.

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

Однако если у вас есть настольный компьютер, системная плата или сервер с BIOS UEFI и реализована безопасная загрузка, это может быть затронуто. На выделенном 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. Включите безопасную загрузку с помощью следующих параметров:
   • PK: ваш PK или самозаверяющий тестовый PK
   • KEK: MS KEK, подписанный PK fabrikam test KEK или другой KEK
   • БАЗА ДАННЫХ: NULL. (Это значение должно иметь значение NULL.)
   • DBX: NULL.
   • SecureBoot: переменная UEFI должна иметь значение true.
3. Перезагрузка компьютера
4. Предполагался следующий результат:
   • Если встроенное ПО UEFI реализовано правильно, драйвер дополнительного ПЗУ UEFI не загружается, так как наличие дополнительного ПЗУ сделает встроенное ПО проверка «Db» для сертификата. Так как «Db» имеет значение NULL, драйвер UEFI не сможет загрузиться. Например, если вы используете видео карта для тестирования, вы увидите, что на экране ничего не отображается.
   • Если встроенное ПО реализовано неправильно, драйвер UEFI загрузится из дополнительного ПЗУ, так как встроенное ПО не проверка для подписей в базе данных. Например, если вы используете видео карта для тестирования, вы увидите, что монитор, подключенный к дополнительному ПЗУ, карта будет иметь дисплей.

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

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

Вы также можете ссылаться на Приложение А для другого подхода к выполнению приведенного выше теста. Этот подход не требует установки для базы данных значения Null, но требуется неподписанный драйвер ПЗУ 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 (загрузка или выгрузка файла драйвера). Затем поместите подписанный драйвер в объединенное дополнительное ПЗУ.

Вы можете направить 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
• Ресурсы IHV UEFI @ intel.com
• Используйте список рассылки TianoCore edk2-devel для поддержки других разработчиков UEFI.
• TechNet: рекомендации по корпоративной безопасности: стратегии безопасности
• Спецификация UEFI errata C
• Группа доверенных вычислений
• Пакет средств разработки Tianocore UEFI
• Встроенное ПО UEFI
• Intel Press: Beyond BIOS 2nd Edition
• Руководство по созданию ключей безопасной загрузки и управлению ими
• Проверка функциональных возможностей платформы обновления встроенного ПО Windows UEFI

Приложение А. Альтернативный подход к тестированию с использованием неподписанных драйверов ПЗУ

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

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

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

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

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

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

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

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

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

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

Создание сертификатов 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 

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 = "" $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 

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 = "" $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 

Примечание Помните, что если тестовый ЦС KEK Fabrikam является единственным ЦС 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." 

что такое в биос — Realtek PXE OPROM

Функция сетевого контроллера, позволяющая загружать ОС по сети.

Остальные ответы

Realtek PXE OPROM является аналогом BootROM (загрузки ОС по сети).

Realtek PXE OPROM — это загрузка ОС по сети

Технология PXE (Preboot eXecution Environment) — это специальная среда для установки или загрузки системы в BIOS с использованием только сетевой карты.

Похожие вопросы

Ваш браузер устарел

Мы постоянно добавляем новый функционал в основной интерфейс проекта. К сожалению, старые браузеры не в состоянии качественно работать с современными программными продуктами. Для корректной работы используйте последние версии браузеров Chrome, Mozilla Firefox, Opera, Microsoft Edge или установите браузер Atom.