Uefi oprom что это
Перейти к содержимому

Uefi oprom что это

  • автор:

Руководство по проверке UEFI

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

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

Введение

Параметры РОМ (или OpROMs) — это встроенное ПО, выполняемое BIOS КОМПЬЮТЕРА во время инициализации платформы. Они обычно хранятся в подключаемых модулях карта, хотя они могут находиться на системной плате.

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

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

Единый расширяемый интерфейс встроенного ПО (UEFI) поддерживает поддержку параметров УПРАВЛЕНИЯ устаревшим режимом.

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

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

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

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

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

  • Только устаревшие РОМ
  • UEFI Native OpROM
  • Устаревшие РОМ + UEFI EBC OpROM
  • Устаревшие РОМ + UEFI x64 OpROM
  • Устаревшие РОМ + UEFI x64 + UEFI IA32
  • Устаревшие РОМ + UEFI x64 + UEFI IA32 + UEFI EBC OpROM

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

Если для параметра задан формат UEFI, он будет использовать более новый РОМ EFI, если он присутствует, и устаревший РОМ, если он отсутствует.

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

1. UEFI и параметры РОМ

diagram of uefi driver considerations

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

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

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

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

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

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

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

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

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

Спецификация PCI позволяет использовать несколько параметров образов РОМ на одном устройстве. Эти параметры РОМЗ могут быть устаревшими x86 и UEFI. Встроенное ПО UEFI задает политику платформы для выбора параметра РОМ. Это может сделать ДИСК дополнительного адаптера выполняться как собственное устройство управления.

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

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

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

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

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

2. Оператор проблемы

Некоторые сборки 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.

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

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

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

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

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

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

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

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

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

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

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

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

  1. Вставьте надстройку UEFI в pci карта с UEFI Option ROM на тестируемый компьютер. Если вы используете видео PCI карта для тестирования, подключите внешний монитор.
  2. Включите безопасную загрузку с помощью следующих параметров:
    • PK: PK или самозаверяющий тест PK
    • KEK: MS KEK, PK-подписанный Fabrikam тест KEK или другой KEK
    • БАЗА ДАННЫХ: NULL. (Это должно быть NULL.)
    • DBX: NULL.
    • SecureBoot: переменная UEFI должна иметь значение true
  3. Перезагрузка компьютера
  4. Предполагался следующий результат:
    • Если встроенное ПО UEFI реализовано правильно, драйвер UEFI UEFI не загружается, так как наличие параметров РОМ сделает встроенное ПО проверка «Db» для сертификата. Так как параметр Db имеет значение NULL, драйвер UEFI не будет загружаться. Например, если вы используете видео карта для тестирования, вы увидите, что ничего не отображается на экране.
    • Если встроенное ПО не реализовано правильно, драйвер UEFI загружается из параметров, так как встроенное ПО не проверка подписей в «Db». Например, если вы используете видео карта для тестирования, вы увидите, что монитор, подключенный к параметру, карта будет отображаться.

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

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

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

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

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

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

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

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

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

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

Приложение A. Альтернативный подход к тестированию с помощью драйверов РОМ без знака

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

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

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

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

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

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

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

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

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

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

    Создание сертификатов KEK и PK Для этого шага требуется средство makecert.exe, доступное в пакете SDK для Windows.

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 

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

Опция BIOS Boot List Option

Опция Boot List Option — Выбор варианта загрузки определяем режим загрузки и меет два значения «Legacy» — (наследуемый вариант загрузки — режим совместимости) BIOS или «UEFI» (Unified Extensible Firmware Interface — интерфейс между операционной системой и микропрограммами) режим загрузки.

UEFI BIOS поддерживает два режима загрузки: режим загрузки Legacy («Наследие») BIOS и режим загрузки UEFI.

Некоторые устройства и операционные системы пока не поддерживают UEFI на основе BIOS и могут загружаться только с режиме загрузки — Legacy BIOS.

В зависимости от вашей ситуации, вы выбираете какой режим загрузки из UEFI BIOS вы хотите использовать: режим загрузки Наследия — Legacy BIOS или режим UEFI загрузки.

  1. Legacy ( CMS OS или CSM Boot, UEFI and Legacy OS, Legacy OpROM) – выберите режим загрузки Legacy BIOS, чтобы HBAs-адаптеры и некоторые экспресс — модули могли использовать опции ROMs — ПЗУ. При выборе режима загрузки Legacy BIOS, только загрузочные кандидаты поддерживающие режим загрузки Legacy BIOS будут перечислены в списке «Приоритет — Параметры загрузки». НЕ забываем при выборе данной опции
    1) отключить очень капризную опцию Secure Boot — защищенной загрузки. А так же включить модуль
    2) Load Legacy Option Rom — CSM — загрузку модуля совместимости старых ОС.
  2. UEFI (UEFI OS) – выберите режим загрузки UEFI что бы использовать драйверы UEFI. Только устройства, поддерживающие выбранный режим загрузки перечислены на экране выбора источника загрузки BIOS — экране в списке Приоритетов Параметры загрузки.

Опция также может иметь другие названия:

Примечание 1. Если режим загрузки (Boot List Option) изменяется, то выставленная последовательность опроса носителей — дисков — кандидатов от предыдущего режима загрузки не сохраняется..

Примечание 2. Загрузчик операционной системы – это системная программа, которая подготовляет компьютер для загрузки операционной системы (загружает ядро операционной системы в оперативную память, формирует параметры работы ОС…). Запуск загрузчика выполняет BIOS.

Программа Aptio Setup Utility — BIOS фирмы American Megatrends Inc на системных платах Dell Inc.

Название данной опции у данного производителя в данной версии BIOS:

Boot List Option значение по умолчанию [Legacy]

This list specifies the order that the BIOS searches devices when trying to find an operating system to boot.

To change the boot order select the device to be changed in the list on the right hand side, then use the keybaord PgUp/PgDn keys to change the boot order of the device.

The boot devices can also be selectd or de-selectd from the list using the check boxes on left hand side.

Этот список определяет порядок, в котором BIOS ищет устройства при попытке найти операционную систему для загрузки.

Чтобы изменить порядок загрузки выберите желаемое устройство в списке на правой стороне, а затем используя клавиши клавиатуры PgUp / PgDn, измените порядок загрузки устройства.

Загрузочные устройства также могут быть выбраны из списка помощью флажков +/-

Если операционная система установлена ​​с помощью режим загрузки «Наследие» BIOS (Legacy BIOS boot mode) операционная система может быть запущена только в режиме загрузки Legacy.

Если операционная система установлена ​​с помощью режим загрузки UEFI, операционная система может быть запущена только в режиме загрузки UEFI (UEFI boot mode).

Как запускается сервер: UEFI

Ранее мы уже разбирали последовательность запуска сервера на примере устаревшего Legacy. Настало время познакомиться с UEFI поближе.

Первая версия того, что сейчас известно как Unified Extensive Firmware Interface (UEFI), разрабатывалась в 90-е годы прошлого тысячелетия специально под системы на Intel® Itanium® и называлась Intel Boot Initiative, а позже — EFI.

Желание «обновить» процесс загрузки было ожидаемо. PC-BIOS, именуемый ныне Legacy, предлагает работать в 16-битном real mode, адресует всего 1 МБ оперативной памяти, а загрузчик вместе с таблицей разделов должен размещаться в первых 512 байтах накопителя. Более того, PC-BIOS передает управление первому найденному загрузчику без возможности возврата назад. При этом обработку случаев с несколькими операционными системами возлагают на плечи загрузчика.

Ограничение на размер загрузчика диктует использование разметки Master Boot Record (MBR), появившийся в 1983 году. MBR не стандартизирован, однако множество производителей придерживаются «сложившихся традиций». У MBR есть серьезные ограничения: по умолчанию поддерживается только 4 раздела и объем накопителя не более 2.2 ТБ.

В декабре 2000 года была выпущена первая широко распространенная спецификация EFI под версией 1.02. Спустя пять лет Intel передали EFI в UEFI Forum, добавив Unified в название, чтобы подчеркнуть изменения. Спецификация UEFI лежит в открытом доступе и состоит из нескольких документов:

  • ACPI Specification;
  • UEFI Specification;
  • UEFI Shell Specification;
  • UEFI Platform Initialization Specification;
  • UEFI Platform Initialization Distribution Packaging Specification.

UEFI универсален, но в данной статье мы будем опираться на стандарт, поглядывая в сторону процессоров на архитектуре x86_64.

Wake up, Neo!

Последовательность фаз загрузки UEFI (источник UEFI Platform Initialization Specification)
После инициации включения платформы блок питания ждет, пока не завершатся переходные процессы, и после устанавливает сигнал на линию Power_Good. И первым начинает работу не центральный процессор, а автономная подсистема Intel® Management Engine (ME) или аналогичная ей AMD Secure Technology (ST). Эта подсистема проводит собственные операции, а затем подготавливает и запускает первое ядро одного процессора, именуемое Bootstrap Processor (BSP).

В соответствии с принятой терминологией ядро/поток процессора здесь и далее будет называться процессором: начальным (bootstrap processor) или прикладным (application processor).

Как и в Legacy, процессор начинает выполнять первую инструкцию в конце адресного пространства по адресу 0xFFFFFFF0. Эта инструкция — прыжок на первую фазу инициализации платформы — SEC.

Фаза SEC (Security)

В данной фазе должны быть решены следующие задачи:

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

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

Во время фазы SEC не происходит инициализация оперативной памяти. Вместо этого свободный кэш процессора помечается как несбрасываемый, и он превращается во временную оперативную память. Такой режим называется no-eviction mode (NEM). В выделенной памяти создается стек, что позволит модулям из следующих фаз использовать стековые языки программирования до инициализации основной оперативной памяти.

Далее происходит инициализация всех прикладных процессоров (Application Processor, AP) с отправкой им специальной последовательности межпроцессорных прерываний (Inter-Processor Interrupt, IPI). Последовательность Init IPI — Start-up IPI — пробуждает прикладной процессор и запускает на нем самотестирование — Built-In Self-Test (BIST). Результаты тестирования записываются и передаются далее для анализа.

В конце фазы Security необходимо найти раздел Boot Firmware Volume (BFV), на котором располагается исполняемый код следующей фазы, а также по возможности найти другие, неосновные, разделы с кодом (Firmware Volume, FV).

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

В конце выполнения SEC собрана следующая информация:

  • размер и адрес Boot Firmware Volume (BFV);
  • размер и адреса других Firmware Volume (FV);
  • размер и адрес временной оперативной памяти;
  • размер и адрес стека.

Фаза PEI (Pre EFI Initialization)

Фаза PEI на материнской плате SuperMicro
Задача фазы Pre EFI Initialization заключается в сборе информации о подключенных устройствах и подготовке минимально необходимого количества оборудования для запуска процесса полной инициализации.

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

Данная фаза состоит из ядра, называемого PEI Foundation, и подключаемых модулей PEI Module (PEIM). Центральной частью ядра является диспетчер модулей, PEI Dispatcher, который управляет порядком исполнения модулей, а также организует межмодульное взаимодействие (PEIM-to-PEIM Interface, PPI).

Отметим, что фаза SEC исполнялась с флэш-памяти на материнской плате, и только в начале PEI необходимый для этой фазы исполняемый код копируется во временную оперативную память.

Далее к работе приступает PEI Dispatcher. Он запускает PEI модули в конкретном порядке: сначала модули без зависимостей, затем зависящие от первых и так до тех пор, пока модули не закончатся.

Архитектура фазы PEI позволяет разрабатывать собственные модули, которые могут передавать результаты своей деятельности в следующую фазу. Передача информации происходит через специальную структуру данных Hand-off Block (HOB).

В процессе запуска PEI модулей отметим следующие:

  • CPU PEIM — инициализация процессоров;
  • Platform PEIM — инициализация северного (в т.ч. Memory Controller Hub) и южного (I/O Controller Hub) мостов;
  • Memory Initialization PEIM — инициализация основной оперативной памяти и перенос данных из временной памяти в RAM.

Состояние S3 (Suspend to RAM) — это состояние сна, при котором процессор и часть чипсета отключаются с потерей контекста. При пробуждении из такого состояния процессор начинает выполнение как при обычном включении. Но вместо полной инициализации и прохождения всех тестов система ограничивается восстановлением состояния всех устройств.

При запуске из любого другого состояния управление передается в фазу Driver Execution Environment.

Фаза DXE (Driver eXecution Environment)

Инициализация механизма AHCI в фазе DXE
Задача фазы Driver Execution Environment (DXE) сводится к инициализации оставшихся устройств. К моменту старта фазы DXE процессор и основная память уже готовы к работе, а на драйверы DXE не накладываются строгие ограничения по потребляемым ресурсам.

Аналогично PEI Foundation в данной фазе есть собственное ядро — DXE Foundation. Ядро создает необходимые интерфейсы и загружает три вида DXE сервисов:

  • UEFI Boot Services — сервисы времени загрузки;
  • UEFI Runtime Services — сервисы времени исполнения;
  • DXE Services — специальные сервисы, необходимые ядру DXE.

В UEFI нет специализированной фазы, где оборудование проходит POST (Power-On Self-Test). Вместо этого каждый модуль PEI и DXE фазы проводит свой набор тестов и сообщает об этом с помощью POST-кодов пользователю и с помощью HOB в следующие фазы.

Среди множества загружаемых драйверов на процессорах x86_64 стоит уделить внимание драйверу System Management Mode Init (SMM Init). Этот драйвер подготавливает все для работы режима системного управления (System Management Mode, SMM). SMM — это особый привилегированный режим, который позволяет приостановить выполнение текущего кода (в т.ч. операционную систему) и выполнить программу из защищенной области памяти SMRAM в собственном контексте.

Режим SMM неофициально считается кольцом защиты с номером -2. Ядро ОС работает на 0 кольце, а более ограниченные в правах кольца защиты имеют номер от 1 до 3. Официально нулевое кольцо считается наиболее привилегированным. Тем не менее, гипервизор с аппаратной виртуализацией условно называют кольцом -1, а Intel ME и AMD ST — кольцом -3.

Дополнительно отметим модуль Compatibility Support Module (CSM), который обеспечивает совместимость с Legacy и позволяет загружать ОС без поддержки UEFI. Позднее мы рассмотрим этот модуль подробнее.

После инициализации всего оборудования наступает время выбора загрузочного устройства.

Фаза BDS (Boot Device Select)

В фазе Boot Device Select реализуется политика загрузки приложений UEFI. Несмотря на то, что это отдельная фаза, все сервисы, включая диспетчера, созданные на фазе DXE, остаются доступны.

Цель фазы BDS сводится к выполнению следующих задач:

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

PCIe BIOS карты расширения LSI
Поиском загружаемых областей на устройствах занимается Boot Manager. На некоторых картах расширения, например, на сетевых картах и RAID-контроллерах, может находиться собственный «BIOS», называемый Option ROM, или OpROM. Содержимое OpROM устройств запускаются сразу после обнаружения, а после выполнения управление возвращается в Boot Manager.

Все разделы, на которых находятся загружаемые области, сохраняются в памяти менеджера загрузки и упорядочиваются в соответствии с порядком загрузки. Если ни одного приложения не нашлось, Boot Manager может вызвать диспетчера DXE, на случай если за время поисков диспетчер загрузил дополнительные драйвера и менеджеру загрузки могут «открыться» новые устройства.

Как отмечалось ранее, использование разметки Master Boot Record накладывает ограничения на размер разделов и их количество на накопителе, а также вызывает определенные неудобства в содержании нескольких операционных систем. Решение всех этих проблем является частью спецификации UEFI — GUID Partition Table.

GPT (GUID Partition Table)

GUID Partition Table — это стандартизированный формат размещения таблиц разделов, пришедший на смену устаревшей MBR.

Во-первых, GPT использует адресацию логических блоков (Logical Block Addressing, LBA) вместо адресации «Цилиндр — Головка — Сектор» («Cylinder, Head, Sector», CHS). Смена способа адресации позволяет GPT работать с накопителями объемом до 9.4 ЗБ (9.4 * 10 21 байт) против 2.2 ТБ у MBR.

Во-вторых, таблица разделов претерпела изменения, и теперь в пределах одного накопителя можно создать до 2 64 разделов, хотя операционные системы поддерживают не более 128 в случае Microsoft Windows и 256 в случае Linux.

В-третьих, каждый раздел имеет свой идентификатор типа, который описывает назначение раздела. Так, например, идентификатор C12A7328-F81F-11D2-BA4B-00A0C93EC93B однозначно указывает на системный раздел EFI (EFI System Partition, ESP), с которого Boot Manager может попробовать загрузить приложение.

При разработке GPT не обошли стороной и совместимость с MBR. Дисковые утилиты могли не распознать GPT диск и затереть его. Чтобы избежать этого, при разметке GPT первые 512 байт заполняются защитной MBR (Protective MBR) — разметкой из одного раздела на весь накопитель с системным идентификатором 0xEE. Такой подход позволяет UEFI понимать, что перед ним не настоящий MBR, а старому программному обеспечению без поддержки GPT — видеть раздел с данными неизвестного типа.

В GPT отказались от загрузочной области в пользу ESP-разделов, которые распознаются как загрузочные. Boot Manager собирает информацию обо всех ESP на диске, что позволяет без конфликтов иметь несколько загрузчиков на накопителе, по одному на каждый ESP.

Загрузка операционной системы

После опроса всех устройств и поиска загрузочных областей Boot Manager начинает загружать в порядке приоритета загрузки. В общем случае управление передается в UEFI-приложение, которое начинает выполнять свою логику. Однако для систем с совместимостью с Legacy режимом в списке загрузочных областей может найтись накопитель с разметкой MBR и придется обращаться к CSM, модулю поддержки совместимости.

Модуль CSM позволяет запускать операционные системы, которые не поддерживают UEFI. Для загрузки таких ОС модуль CSM эмулирует окружение, в которое попадает «классическая» ОС:

  • загружает Legacy-драйвер;
  • загружает Legacy BIOS;
  • переводит видеовывод в совместимый с Legacy режим;
  • создает в памяти необходимые для Legacy структуры данных, отсутствующие в UEFI;
  • загружает драйвер CompatibilitySmm для работы SMM в Legacy.

Фаза RT (Run Time)

Начало загрузки ОС или Legacy-загрузчика приводит к началу фазы Run Time. В данной фазе все сервисы DXE (кроме UEFI Runtime Services) перестают быть доступны.

Содержимое фазы RT может быть разным. Здесь может быть привычный по Legacy загрузчик ОС — например, GRUB2 или Windows Boot Manager, который переводит процессор в 64-битный режим и запускает ОС. Но могут быть и самостоятельные приложения или сразу ядро операционной системы.

Ядро Linux начиная с версии 3.3 при наличии флага CONFIG_EFI_STUB превращается в обычное UEFI-приложение и может быть запущено из UEFI без использования сторонних загрузчиков.

Как и в случае с Legacy, загрузчику или самому ядру необходимо перевести процессор в 64-битный режим, загрузить все драйвера, настроить планировщик и запустить init. Init, в свою очередь, запускает процессы в пространстве пользователя, после чего появляется окно логина в ОС.

Заключение

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

Как Вы думаете, как скоро получится полностью уйти от Legacy?
Пишите свое мнение в комментариях.

Эксплуатация подписанных загрузчиков для обхода защиты UEFI Secure Boot

Прошивки современных материнских плат компьютера работают по спецификации UEFI , и с 2013 года поддерживают технологию проверки подлинности загружаемых программ и драйверов Secure Boot, призванную защитить компьютер от буткитов . Secure Boot блокирует выполнение неподписанного или недоверенного программного кода: .efi-файлов программ и загрузчиков операционных систем, прошивок дополнительного оборудования (OPROM видеокарт, сетевых адаптеров).
Secure Boot можно отключить на любой магазинной материнской плате, но обязательное требование для изменения его настроек — физическое присутствие за компьютером. Необходимо зайти в настройки UEFI при загрузке компьютера, и только тогда получится отключить технологию или изменить её настройки.

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

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

Подписанные загрузчики загрузчиков

Итак, чтобы загрузить Linux при включенном Secure Boot, нужен подписанный загрузчик. Microsoft запретила подписывать ПО, лицензированное под GPLv3, из-за запрета тивоизации правилами лицензии, поэтому GRUB подписать не получится.
В ответ на это, Linux Foundation выпустили PreLoader, а Мэтью Гарретт написал shim — маленькие начальные загрузчики, проверяющие подпись или хеш следующего загружаемого файла. PreLoader и shim не используют сертификаты UEFI db , а содержат базу разрешенных хешей (PreLoader) или сертификатов (shim) внутри себя.
Обе программы, помимо автоматической загрузки доверенных файлов, позволяют загружать и любые ранее недоверенные файлы в режиме Secure Boot, но требуют физического присутствия пользователя: при первом запуске необходимо выбрать добавляемый сертификат или файл для хеширования в графическом интерфейсе, после чего данные заносятся в специальную переменную NVRAM материнской платы, которая недоступна для изменения из загруженной операционной системы. Файлы становятся доверенными только для этих пред-загрузчиков, а не для Secure Boot вообще, и запустить их без PreLoader/shim всё равно не получится.

Действия, необходимые для запуска недоверенной программы через shim.

Действия, необходимые при первом запуске недоверенной программы через shim.

Все современные популярные дистрибутивы Linux используют shim, из-за поддержки сертификатов, которая позволяет легко обновлять следующий загрузчик без необходимости взаимодействия с пользователем. Как правило, shim используется для запуска GRUB2 — наиболее популярного бутлоадера в Linux.

GRUB2

Чтобы злоумышленники втихую не наделали делов с помощью подписанного загрузчика какого-либо дистрибутива, Red Hat сделал патчи для GRUB2, блокирующие «опасные» функции при включенном Secure Boot: insmod/rmmod, appleloader, linux (заменён linuxefi), multiboot, xnu, memrw, iorw. К модулю chainloader, загружающему произвольные .efi-файлы, дописали собственный загрузчик .efi (PE), без использования команд UEFI LoadImage/StartImage, а также код валидации загружаемых файлов через shim, чтобы сохранялась возможность загрузки файлов, доверенных для shim, но не доверенных с точки зрения UEFI. Почему сделали именно так — непонятно; UEFI позволяет переопределять (хукать) функции проверки загружаемых образов, именно так работает PreLoader, да и в самом shim такая функция имеется, но по умолчанию отключена.

Так или иначе, воспользоваться подписанным GRUB из какого-то дистрибутива Linux не получится. Для создания универсальной загрузочной флешки, которая бы не требовала добавление ключей каждого загружаемого файла в доверенные, есть два пути:

  • Использование модифицированного GRUB, загружающего EFI-файлы своими силами, без проверки цифровой подписи, и без блокирования модулей;
  • Использование собственного пред-загрузчика (второго), переопределяющего функции проверки цифровой подписи UEFI (EFI_SECURITY_ARCH_PROTOCOL.FileAuthenticationState, EFI_SECURITY2_ARCH_PROTOCOL.FileAuthentication)

Итого, архитектура флешки получилась следующая:

 ______ ______ ______ ╱│ │ ╱│ │ ╱│ │ /_│ │ → /_│ │ → /_│ │ │ │ → │ │ → │ │ │ EFI │ → │ EFI │ → │ EFI │ │_______│ │_______│ │_______│ BOOTX64.efi grubx64.efi grubx64_real.efi (shim) (FileAuthentication (GRUB2) override) ↓↓↓ ↑ ↑ ______ ↑ ╱│ │ ║ /_│ │ ║ │ │ ═══════════╝ │ EFI │ │_______│ MokManager.efi (Key enrolling tool)

Super UEFIinSecureBoot Disk — образ диска с загрузчиком GRUB2, предназначенным для удобного запуска неподписанных efi-программ и операционных систем в режиме UEFI Secure Boot.

Диск можно использовать в качестве основы для создания USB-накопителя с утилитами восстановления компьютера, для запуска различных Live-дистрибутивов Linux и среды WinPE, загрузки по сети, без отключения Secure Boot в настройках материнской платы, что может быть удобно при обслуживании чужих компьютеров или корпоративных ноутбуков, например, при установленном пароле на изменение настроек UEFI.

Образ состоит из трех компонентов: предзагрузчика shim из Fedora (подписан ключом Microsoft, предустановленным в подавляющее большинство материнских плат и ноутбуков), модифицированного предзагрузчика PreLoader от Linux Foundation (для отключения проверки подписи при загрузке .efi-файлов), и модифицированного загрузчика GRUB2.

Во время первой загрузки диска на компьютере с Secure Boot необходимо выбрать сертификат через меню MokManager (запускается автоматически), после чего загрузчик будет работать так, словно Secure Boot выключен: GRUB загружает любой неподписанный .efi-файл или Linux-ядро, загруженные EFI-программы могут запускать другие программы и драйверы с отсутствующей или недоверенной подписью.

Для демонстрации работоспособности, в образе присутствует Super Grub Disk (скрипты для поиска и загрузки установленных операционных систем, даже если их загрузчик поврежден), GRUB Live ISO Multiboot (скрипты для удобной загрузки Linux LiveCD прямо из ISO, без предварительной распаковки и обработки), One File Linux (ядро и initrd в одном файле, для восстановления системы), и несколько UEFI-утилит.

Диск совместим с UEFI без Secure Boot, а также со старыми компьютерами с BIOS.

Подписанные загрузчики

Мне было интересно, можно ли как-то обойти необходимость добавления ключа через shim при первом запуске. Может, есть какие-то подписанные загрузчики, которые позволяют делать больше, чем рассчитывали авторы?
Как оказалось — такие загрузчики есть. Один из них используется в Kaspersky Rescue Disk 18 — загрузочном диске с антивирусным ПО. GRUB с диска позволяет загружать модули (команда insmod), а модули в GRUB — обычный исполняемый код. Пред-загрузчик у диска собственный.

Разумеется, просто так GRUB из диска не загрузит недоверенный код. Необходимо модифицировать модуль chainloader, чтобы GRUB не использовал функции UEFI LoadImage/StartImage, а самостоятельно загружал .efi-файл в память, выполнял релокацию, находил точку входа и переходил по ней. К счастью, почти весь необходимый код есть в репозитории GRUB’а с поддержкой Secure Boot от Red Hat, единственная проблема: код парсинга заголовка PE отсутствует, заголовок парсит и возвращает shim, в ответ на вызов функции через специальный протокол. Это легко исправить, портировав соответствующий код из shim или PreLoader в GRUB.

Так появился Silent UEFIinSecureBoot Disk. Получившаяся архитектура диска выглядит следующим образом:

 ______ ______ ______ ╱│ │ ╱│ │ ╱│ │ /_│ │ /_│ │ → /_│ │ │ │ │ │ → │ │ │ EFI │ │ EFI │ → │ EFI │ │_______│ │_______│ │_______│ BOOTX64.efi grubx64.efi grubx64_real.efi (Kaspersky (FileAuthentication (GRUB2) Loader) override) ↓↓↓ ↑ ↑ ______ ↑ ╱│ │ ║ /_│ │ ║ │ │ ═══════════╝ │ EFI │ │_______│ fde_ld.efi + custom chain.mod (Kaspersky GRUB2)

Заключение

В этой статье мы выяснили, что существуют недостаточно надежные загрузчики, подписанные ключом Microsoft, разрешающим работу в режиме Secure Boot.
С помощью подписанных файлов Kaspersky Rescue Disk мы добились «тихой» загрузки любых недоверенных .efi-файлов при включенном Secure Boot, без необходимости добавления сертификата в UEFI db или shim MOK.
Эти файлы можно использовать как для добрых дел (для загрузки с USB-флешек), так и для злых (для установки буткитов без ведома владельца компьютера).
Предполагаю, что сертификат Касперского долго не проживет, и его добавят в глобальный список отозванных сертификатов UEFI, который установят на компьютеры с Windows 10 через Windows Update, что нарушит загрузку Kaspersky Rescue Disk 18 и Silent UEFIinSecureBoot Disk. Посмотрим, как скоро это произойдет.

Про ZeroNet

ZeroNet — очень мощная система создания децентрализованных распределенных динамических веб-сайтов и сервисов. При посещении какого-либо ресурса, пользователь начинает его скачивать и раздавать, как в BitTorrent. При этом, возможно создание полноценных ресурсов: блогов с комментариями, форумов, видеохостингов, wiki-сайтов, чатов, email, git.
ZeroNet разделяет понятия кода и данных сайта: пользовательские данные хранятся в .json-файлах, а при синхронизации импортируются в sqlite-базу данных сайта со стандартизированной схемой, что позволяет делать умопомрачительные вещи: локальный поиск текста по всем когда либо открытым сайтам за миллисекунды, автоматический real-time аналог RSS для всех сайтов разом.
Стандартизированная система аутентификации и авторизации (похожа на OAuth), поддержка работы за NAT и через Tor.
ZeroNet очень быстро работает, дружелюбен к пользователю, имеет современный интерфейс и мелкие, но очень удобные фишки, вроде глобального переключения дневной/ночной темы на сайтах.

Я считаю ZeroNet очень недооцененной системой, и намеренно публикую Silent-версию только в ZeroNet Git, для привлечения новых пользователей.

  • uefi
  • uefi secure boot
  • kaspersky
  • kaspersky rescue disk

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *