Главная » Windows 10 » Режим bios устаревший windows 10 как исправить

Режим bios устаревший windows 10 как исправить


Как исправить ошибку ACPI_BIOS_ERROR в Windows 10

Одной из ошибок, которых больше всего боятся пользователи операционной системы от Microsoft являются знаменитый синий экран или экраны смерти. Из наиболее широко распространенных является ошибка ACPI_BIOS_ERROR, сопровождается значением 0x000000A5. Если вы из тех, кто столкнулся с этой ошибкой, мы покажем ниже, некоторые действия или рекомендации для устранения этой ошибки.

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

Устраним и исправим ACPI_BIOS_ERROR в Windows 10

Шаг 1. Первое что нужно сделать это проверить драйвера на совместимость и обновить их. Можете попробовать запустить тестовый режим и поработать в нем некоторое время для выявления причины. Лучшим способом является проверка активации драйверов, чтобы точно узнать какой именно драйвер вызывает синий экран.

Шаг 2. Является сам устаревший BIOS, который нужно обновить с официальных источников. Посмотрите версию своего БИОСА или UEFI, перейдите на официальный сайт и скачайте там файл обновления. После скачивания, обычно ZIP-файла, внутри находиться setup.exe для установки. Если не оказалось более новой прошивки чем у стоит уже, то смотрите ниже.

Шаг 3. BIOS старой версии может быть еще несовместим с ACPI, для этого нам нужно отключить режим ACPI в БИОСЕ. Для этого вам нужно будет зайти в БИОС, перейти в параметр электроэнергией, электропитания, и отключить режим ACPI.

Шаг 4.  Ошибка ACPI_BIOS_ERROR может быть вызвана неисправностью ОПЕРАТИВНОЙ памяти, дополненных различными утилитами для оптимизации. Проверьте на всякий случай оперативную память на ошибки. Попробуйте достать одну планку ОЗУ, поработавши некоторое время с ней, потом вторую.

Шаг 5. Ошибка вызвана убитым или захламленным винчестером, ошибках в секторах. Попробуйте почистить вашу систему от всяких остаточных файлов и мусора.   Проверьте локальные диски на системные ошибки, нажав правой кнопкой мыши на локальном системном диске, выбрав свойства > сервис > проверить.

Смотрите еще:

comments powered by HyperComments Сообщи об ошибке

mywebpc.ru

WinPE: загрузка в режиме UEFI или устаревшем режиме BIOS

После загрузки Windows PE на компьютере с UEFI может понадобиться проверить, загружается ил компьютер в режиме UEFI или в режиме совместимости BIOS.

Например, для запуска программы установки Windows в Windows PE требуется соответствующий режим встроенного ПО.

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

Загрузка в режиме UEFI

  • При загрузке компьютера вам, возможно, потребуется вручную выбрать корневые файлы UEFI: \EFI\BOOT\BOOTX64.EFI.

    1. Загрузите компьютер и нажмите клавишу, открывающую меню встроенного ПО (например: Esc, F2, F9, F12).

    2. Найдите параметр встроенного ПО, позволяющий выбрать корневой файл. Например: Boot to file (Загрузить из файла), Boot to EFI file (Загрузить из файла EFI).

    3. Выберите файл на USB-накопителе \EFI\BOOT\BOOTX64.EFI.

Как узнать, в каком режиме загружена среда предустановки Windows — в BIOS или UEFI?

  1. Проверьте значение реестра HKLM\System\CurrentControlSet\Control\PEFirmwareType, чтобы узнать, загружается ли компьютер в режиме UEFI или BIOS. Примечание. Чтобы получить это значение, возможно, потребуется выполнить команду wpeutil UpdateBootInfo.

    reg query HKLM\System\CurrentControlSet\Control /v PEFirmwareType

    Она возвращает 0x1, если компьютер загружен в режиме BIOS, и 0x2 — если в режиме UEFI.

    Образец сценария:

    wpeutil UpdateBootInfo for /f "tokens=2* delims= " %%A in ('reg query HKLM\System\CurrentControlSet\Control /v PEFirmwareType') DO SET Firmware=%%B :: Note: delims is a TAB followed by a space. if %Firmware%==0x1 echo The PC is booted in BIOS mode. if %Firmware%==0x2 echo The PC is booted in UEFI mode.

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

    • Загрузка в режиме UEFI: для предотвращения Windows PE загрузки в режиме BIOS удалите файл bootmgr в корне носителя.

    • Загрузка в режиме BIOS: для предотвращения Windows PE загрузки в режиме UEFI удалите папку efi в корне носителя.

Связанные разделы

WinPE для Windows 10 Установка Windows: применение стиля разделов MBR или GPT Параметры командной строки Wpeutil Встроенное ПО UEFI

msdn.microsoft.com

Как обновить "биос"

В этой статье мы будем рассматривать инструкции, которые позволят вам обновить "биос". Именно эта информация интересует многих людей. При этом даже опытные пользователи не могут внятно объяснить, для чего нужна данная операция. Ниже будет предоставлен краткий экскурс по основным понятиям. Также будет дано объяснение, зачем обновлять "биос" и чем это опасно.

Основные сведения. "Биос" – это специальная базовая система, которая позволяет осуществлять операции ввода и вывода. Данное программное обеспечение хранится в каждом компьютере на отдельной детали. При включении ПК "биос" загружается в первую очередь. С помощью этой микропрограммы производится синхронизирование других программ со всеми устройствами. И как вы, наверное, уже догадались, без рабочего "биоса" сам компьютер включаться не будет.

Важность и опасность операции. Обсуждаемая микропрограмма помогает компьютеру правильно взаимодействовать с программной частью. Как это бывает довольно часто, встраиваемая версия "биоса" быстро устаревает. Из-за этого возникают некоторые проблемы с работой отдельных деталей. Разработчики стараются исправить эти недочеты, выпуская обновления. Кроме того, проблемы проявляются при интеграции новых деталей. Ведь часто бывает, что старые версии "биоса" не опознают новые устройства. Но стоит заметить, что не рекомендуется изменять микропрограмму без особой надобности. Ведь при неправильно проведенной операции обновления возможны непоправимые последствия. Вплоть до полного уничтожения ПК. В таких ситуациях вам смогут помочь только в профессиональном сервисном центре.

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

2-ой способ. В некоторых ситуациях можно обновить "биос" посредством стандартных программ. То есть в данном случае вам потребуется только подключение к интернету. Вам не нужно знать версию текущей прошивки и волноваться о соответствии. Программа самостоятельно подберет необходимое обновление. Чтобы запустить эту утилиту, нужно включить компьютер в режиме тестирования. В большинстве случаев это можно совершить, нажав на клавиатуре кнопку F6.

3-ий способ. Легче всего обновить "биос" через специализированный софт. В данной ситуации вам не нужно даже входить в BIOS. Достаточно установить программу на свой компьютер и следовать всем назначенным инструкциям. Рекомендуется использовать только официальное ПО, которое распространяется разработчиками вашей материнской платы. Чтобы обновить "биос" ASUS с флешки, необходимо сначала загрузить все программное обеспечение на электронный носитель, а затем подключить его к ПК.

fb.ru

Invalid partition table при загрузке с флешки Windows 10 и 7

При попытке установки ОС Windows 7, 10 c флеш-накопителя, пользователь может столкнуться с сообщением «Invalid partition table», при этом инсталляция операционной системы на ПК прекращается. Данная проблема обычно связана с некорректно созданной инсталляционной флешкой, устаревшим БИОСом и ещё рядом причин, вызывающих появление указанной дисфункции. В данном материале я расскажу, что такое Invalid partition table при загрузке с флешки Windows 10 и 7, каковы её причины, и как исправить ошибку на вашем ПК.

Ошибка «Invalid partition table» на экране монитора

Что такое «Invalid partition table»?

Перевод «Invalid partition table» звучит как «некорректная таблица разделов», обычно обозначая ситуацию, когда система обратилась к флеш-накопителю за нужными для инсталляции данными, но из-за ряда причин не смогла это осуществить. Среди таких причин я бы отметил следующие:

  • Загрузочная флешка создана некорректно (неверно выбрана файловая система при форматировании флешки, использовано сомнительное программное обеспечение и др.);
  • Загрузочная флешка аппаратно неисправна;
  • Некорректные настройки БИОСа;
  • Используемый в компьютере БИОС устарел, и необходимо его обновление.

    Изучаем причины ошибки «Invalid partition table»

Как исправить «Invalid partition table» при установке с флешки

Чтобы избавиться от ошибки «Invalid partition table» рекомендую выполнить следующее:

  • Проверьте аппаратную работоспособность флеш-накопителя. Попробуйте запустить его на другом компьютере, и убедитесь, что инсталляция с него возможна. Если рассматриваемая мной ошибка возникла и там, тогда есть вероятность, что ваша флешка аппаратно неисправна, или создана некорректно, или используемая на флешке файловая система не подходит для обеих машин. Также рекомендуется попробовать флешку от другого производителя в указанной установке ОС;
  • Проверьте состояние жёстких дисков ПК. Перейдите в БИОС и убедитесь, что компьютер видит жёсткий диск. Если нет, то, возможно, или отошли соответствующие шлейфы к винчестеру, или жёсткий диск неисправен;

    Компьютер не видит жёсткий диск

  • Установите флеш-накопитель как загрузочный в БИОС. Перейдите в БИОС, и последовательности загрузочных дисков установите вашу флешку первой в списке (в разделе БИОСа «Advanced Bios Features», в пункте «Hard Disk Boot Priority», установите первым «HDD USB» или «USB-ZIP»), это может помочь пофиксить ошибку «Invalid partition table» на ПК. Также на некоторых машинах помогала установка первым приводом CD-ROM, попробуйте и этот вариант;

    Измените ранжирование загрузочных устройств на необходимое

  • Измените специфику выбранного режима загрузки. Перейдите в БИОС, и смените значение параметра «UEFI/BIOS Boot Mode» с «Legacy Boot» на «UEFI». Сохраните выполненные изменения (обычно нажав на F10), и попробуйте вновь загрузиться с флешки. Если у вас стоял режим «UEFI» по умолчанию, попробуйте сменить его на «Legacy Boot», и попробовать вновь выполнить инсталляцию. Если смена режима загрузки не помогла, верните режим, используемый по умолчанию, сохраните изменения, и переходите к следующим пунктам;

    Попробуйте изменить значение с «Legacy Boot» на «UEFI», и наоборот

  • Выполните корректное создание загрузочной флешки с помощью программы «UltraISO». В частности, можно воспользоваться подробным мануалом с сайта notebookclub.org. После создания загрузочной флешки и запуска с неё появляется логотип Виндовс, и ситуация может законсервироваться на 10-20 мин. (пугаться не следует, в конце концов инсталляция продолжится);
  • Самостоятельно подготовьте флешку к установке. Подключите флешку к ПК, запустите командную строку от имени администратора, и в ней последовательно наберите следующие команды, не забывая нажимать на ввод после каждой команды:

DISKPART LIST DISK — (Посмотрите, под каким номером будет расположен флеш-накопитель); SELECT DISK N — (вместо N укажите номер флеш-накопителя); DETAIL DISK — (покажет информацию о выбранном вами диске, подтвердив, что вы выбрали диск правильно); CLEAN ALL  — (очистит все данные на флешки); CREATE PARTITION PRIMARY — (создаст основной раздел на флешке); FORMAT FS=NTFS — (форматирование в NTFS); ACTIVE — (раздел сможет содержать загрузочные файлы для установки ОС); ASSIGN EXIT — (выходим из DISKPART); EXIT — (выходим из командной строки).

После этого вновь попытайтесь установить на флешку инсталляцию ОС Windows 7, 10, и выполнить установку Windows 7,10 на ПК.

  • Обновите ваш БИОС на более новую версию (при наличии). Иногда, возникновение ошибки «Invalid partition table при загрузке с флешки Windows 10 и 7» вызвано именно устаревшей версией БИОСа, и его обновление поможет избавиться от ошибки «Invalid partition table» на вашем ПК.

    Обновите БИОС с помощью соответствующего инструментария

Заключение

Ошибка «Invalid partition table при загрузке с флешки Windows 10 и 7» может возникнуть из-за различных причин, самой массовой из которых является некорректное создание загрузочной флешки самим пользователем. Рекомендую воспользоваться приведёнными выше советами, они позволят создать работающую загрузочную флешку, а затем и провести с неё корректную установку ОС на ваш компьютер.

EasyWebScripts.net

Руководство по проверке дополнительных ПЗУ утверждения UEFI

Вишал Манан, архитектор, консультант изготовителей оборудования, [email protected]

Джеремая Кокс, старший специалист SDET, группа безопасности и учетных данных Windows, [email protected]

Тони Лин, специалист инженерной службы, экосистема планирования TW-WIN, [email protected]

Версия 1.3

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

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

На этой странице:

Введение

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

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

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

Единый интерфейс EFI (UEFI) поддерживает устаревший режим дополнительных ПЗУ.

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

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

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

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

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

  • Только устаревшие ПЗУ

  • Собственные дополнительные ПЗУ UEFI

  • Устаревшие ПЗУ + дополнительные ПЗУ EBC UEFI

  • Устаревшие ПЗУ + 64-разрядные дополнительные ПЗУ UEFI

  • Устаревшие ПЗУ + 64-разрядные UEFI + UEFI IA32

  • Устаревшие ПЗУ + 64-разрядные UEFI + UEFI IA32 + дополнительные ПЗУ EBC UEFI

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

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

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

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

Рисунок 2. Безопасность драйверов UEFI (источник: UEFI 2.3.1 с поправкой C)

Из раздела 31.1.4 в 2.3.1 с поправкой C UEFI:

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

Это включает в себя следующее.

  • Защита области хранения драйверов.

  • Защита средств выбора драйверов.

  • Защита среды выполнения этих драйверов от непроверенных драйверов.

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

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

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

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

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

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

Спецификация PCI допускает использование нескольких образов дополнительных ПЗУ на одном устройстве. Эти дополнительные ПЗУ могут оказаться устаревшими 86-разрядными и UEFI. Встроенное ПО UEFI устанавливает политику платформы для выбора дополнительных ПЗУ. Благодаря этому дополнительное ПЗУ адаптера может выполняться как его собственное устройство управления.

Встроенное ПО проверяет подписи на этапах BDS и DXE. Последовательность событий выглядит следующим образом.

  1. Инициализация PCI и дифференциация шин

  2. Проба устройств PCI для дополнительных ПЗУ

  3. Сопоставление найденных дополнительных ПЗУ в памяти

  4. Этап DXE: загрузка драйверов UEFI в ПЗУ

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

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

Из спецификации UEFI 2.3.1 Eratta C:

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

2. Описание проблемы

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

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

Такая уязвимость присутствовала также в EDK II и UDK2010 по состоянию на август 2013 г. Отдел обслуживания источника осведомлен об этой проблеме, ошибка зафиксирована. Любое встроенное ПО, полученное из EDK II или UDK2010, необходимо проверить на предмет того, как управляется проверка дополнительного ПЗУ. Реакция на событие проверки дополнительного ПЗУ контролируется значением PCD PcdOptionRomImageVerificationPolicy в пакете 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.

Примечание  

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

Компьютер 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, описанные в разделе 7.2 спецификации UEFI 2.3.1 с поправкой C.

4. Как выполнить проверку?

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

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

  • ПК для проверки со встроенным ПО UEFI

  • Устройство PCI с дополнительным ПЗУ на ПК для проверки (например, видеоадаптер)

  • Убедитесь, что безопасная загрузка включена

Действия для выполнения проверки

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

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

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

    • PK — ваш PK или самозаверяющий тестовый PK

    • KEK — Microsoft KEK, тестовый KEK Fabrikam, подписанный с использованием PK, или другой KEK

    • DB — NULL. (Этот параметр иметь значение «NULL»).

    • DBX — NULL.

    • SecureBoot — эта переменная UEFI должна иметь значение «true»

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

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

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

    • Если встроенное ПО реализовано неправильно, драйвер UEFI загрузится из дополнительного ПЗУ, поскольку встроенное ПО не проверяет подписи в параметре DB. Например, если для проверки используется видеоадаптер, на монитор, прикрепленный к адаптеру дополнительного ПЗУ, будет выведено изображение.

Примечание  

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

См. примеры сценариев создания PK и KEK, доступные в WHCK. Можно загрузить сценарии здесь: https://go.microsoft.com/fwlink/?LinkId=321292. Приложение B содержит образцы сценариев и дополнительные сведения.

См. также другой вариант проведения описанной выше проверки в Приложении A. Этот подход не требует установки для параметра DB значения «Null», но для выполнения проверки потребуется драйвер дополнительного ПЗУ UEFI без подписи, приобретенный у независимого поставщика оборудования.

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

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

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

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

В случае если имеются неподписанные драйверы на дополнительных ПЗУ UEFI, прочтите ниже информацию о том, как это исправить.

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

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

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

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

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

6. Ресурсы

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

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

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

  • ПК для проверки со встроенным ПО UEFI

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

  • Убедитесь, что безопасная загрузка включена

  • Средства от IHV для обнаружения подписи драйвера дополнительного ПЗУ, если не очевидно — подписан ли драйвер дополнительного ПЗУ или нет

Если встроенное ПО реализовано правильно и дополнительное ПЗУ не имеет подписи, проверка платы встроенным ПО должна завершиться ошибкой, и драйвер не должен быть загружен. Компьютер должен сообщить код ошибки, например EFI_IMAGE_EXECUTION_AUTHENTIC_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=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

    Можно использовать собственный PK или сценарии из WHCK по этому адресу: https://go.microsoft.com/fwlink/?LinkId=321292

    Образец предоставлен ниже.

    # 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 от OEM

    Можно использовать собственный KEK от OEM или сценарии из WHCK. Можно также использовать файл Fabrikam_PK_SigList.bin с сайта https://go.microsoft.com/fwlink/?LinkId=321292 вместо создания собственного тестового KEK.

    Образец предоставлен ниже.

    # 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. Установите для параметра DB значение «Null» и задайте KEK и PK

    Прежде всего данный сценарий выполняет установку параметра DB в значение «Null».

    Примечание  

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

    # Prior to script execution, run "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 Обзор безопасной загрузки Проверка функциональности платформы обновления встроенного ПО UEFI в Windows

msdn.microsoft.com

Смотрите также