Secure boot mode custom что это: Secure Boot — отключение защищенной загрузки (с фото)

ESP32: процесс запуска приложения | arm

В этой документации (перевод [1]) объясняется, что происходит перед тем, как будет запущена функция app_main приложения ESP-IDF.

На высоком уровне процесс запуска (startup) можно рассматривать следующим образом:

1. First stage bootloader. Это код загрузчика первой стадии, находящийся в ROM. Он загружает из SPI-flash образ загрузчика второй стадии в ОЗУ (IRAM и/или DRAM). Код загрузчика второй стадии находится в SPI-flash со смещением 0x1000.

2. Second stage bootloader. Это загрузчик второй стадии, он загружает из flash таблицу разделов [2] и образ основного приложения. Включает в себя как сегменты кода в ОЗУ, так и сегменты только для чтения, отображаемые в адресное пространство CPU через кэш flash.

3. Application startup. В этой точке запускается второй CPU и планировщик FreeRTOS [3].

Этот процесс запуска описывается в последующих секциях.

[First stage bootloader]

После сброса SoC немедленно запустится ядро PRO CPU и начнет выполнить код по вектору сброса (reset vector), в то время как APP CPU будет удерживаться в состоянии сброса. Во время процесса startup ядро PRO CPU делает всю начальную инициализцию. Сброс APP CPU снимается функцией call_start_cpu0, вызываемой кодом startup приложения. Код вектора сброса находится в mask ROM кристалла ESP32, и он не может быть модифицирован.

Код startup, вызываемый вектором сброса, определяет режим загрузки (boot mode) путем проверки регистра GPIO_STRAP_REG для оценки состояния ножек управления загрузкой (bootstrap pin states). В зависимо от причины сброса, может происходить следующее:

1. Сброс из состояния глубокого сна (deep sleep reset): если значение в RTC_CNTL_STORE6_REG ненулевое, и значение CRC памяти RTC в RTC_CNTL_STORE7_REG правильное, то используется RTC_CNTL_STORE6_REG в качестве адреса точки входа, и на него делается безусловный переход. Если RTC_CNTL_STORE6_REG равно 0, или RTC_CNTL_STORE7_REG содержит неправильную CRC, или код, на который указывает RTC_CNTL_STORE6_REG, выполняет возврат, то выполняется такая же загрузка, как загрузка после сброса/включения питания (power-on reset). Замечание: для запуска пользовательского кода в этой точке предоставляется механизм заглушки глубокого сна (deep sleep stub mechanism). Подробности см. в документации [4].

2. Для сброса от включения питания (power-on reset), программного сброса (software SOC reset) и сброса от сторожевого таймера (watchdog SOC reset): проверяется регистр GPIO_STRAP_REG, чтобы определить, запрашивается ли пользовательский режим загрузки (custom boot mode, такой как UART Download Mode). Если этот случай, то custom loader mode выполняется из ROM. Иначе происходит такая же загрузка, как для программного сброса (software CPU reset). Проконсультируйтесь с даташитом ESP32 для получения описания режимов загрузки кристалла (SoC boot modes), и как их запускать.

3. Для программного сброса (software CPU reset) сброса от сторожевого таймера (watchdog CPU reset): конфигурируется SPI flash на основе значений EFUSE, и делается попытка загрузить код из flash. Этот шаг более подробно описан далее.

Важное замечание: во время режимов нормальной загрузки RTC watchdog разрешен, так что если процесс загрузки прервется или будет приостановлен, то сторожевой таймер автоматически сбросит SOC, и процесс загрузки запустится заново. Это может привести к тому, что SoC переключится в новый режим загрузки, если состояние ножек управления загрузкой (strapping GPIO) поменялось.

Двоичный образ второй стадии загрузки грузится из flash с адреса 0x1000. Если используется Secure Boot, то первый сектор flash 4 kB используется для хранения secure boot IV и цифровой подписи (digest) образа загрузчика (bootloader image). Иначе этот сектор не используется.

[Second stage bootloader]

В ESP-IDF двоичный образ, находящийся в памяти SPI-flash со смещением 0x1000, является загрузчиком второй стадии (second stage bootloader). Исходный код загрузчика второй стадии находится в директории components/bootloader среды разработки ESP-IDF [5]. Загрузчик второй стадии в ESP-IDF используется для добавления гибкости в распределении пространства flash-памяти (с помощью таблицы разделов), что позволяет осуществлять различные потоки загрузки, связанные с шифрованием (flash encryption), безопасной загрузкой (secure boot) и обновлением по радио (over-the-air updates, OTA).

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

Загрузчик второй стадии считывает таблицу разделов, которая по умолчанию находится в памяти flash со смещением 0x8000 (это значение конфигурируется). Подробную информацию см. в описании таблицы разделов [2]. Загрузчик в этой таблице находит разделы factory и OTA app. Если были найдены разделы OTA, то загрузчик сверяется с информацией, записанной в разделе otadata, чтобы определить, из какого раздела следует загружать образ приложения. Для дополнительной информации см. описание технологии OTA [6].

Полное описание опций конфигурации, доступных для загрузчика ESP-IDF, см. в документации [7].

Для выбранного раздела загрузчик второй стадии считывает двоичный образ из flash по одному сегменту за один раз:

• Для сегментов с адресом загрузки во внуреннее ОЗУ IRAM (Instruction RAM) или DRAM (Data RAM), содержимое копируется из flash в адрес загрузки.
• Для сегментов, у которых адрес загрузки находится в регионах DROM (данные сохранены в flash) или IROM (код выполняется из flash), конфигурируется flash MMU для предоставления корректного отображения областей flash в адрес загрузки.

Обратите внимание, что загрузчик второй стадии конфигурирует flash MMU для обоих ядер PRO CPU и APP CPU, однако разрешает flash MMU только для PRO CPU. Причина такого поведения в том, что bootloader второй стадии загружается в регион памяти, который используется как кэш для APP CPU. Задача разрешения кэша для APP CPU перекладывается на приложение.

Как только все сегменты были обработаны — т. е. код был загружен, и flash MMU настроен — загрузчик второй стадии проверяет целостность загруженного приложения, затем выполняет безусловный переход на точку входа в приложения, которая находится а заголовке двоичного образа.

[Application startup]

Application startup обозначаются все процессы, которые происходят между моментом перехода на точку входа в приложение и моментом запуска функции app_main, которая находится в теле главной задачи FreeRTOS (main task). Процессы application startup делятся на 3 стадии:

• Инициализация порта поддержки аппаратуры и базовой среды выполнения кода языка C (C runtime environment).
• Инициализация системных программных сервисов и FreeRTOS.
• Запуск main task и вызов функции app_main.

Важное замечание: понимание всех стадий инициализации приложения ESP-IDF не является обязательным требованием для создания корректно работающего приложения. Чтобы понимать инициализацию с точки зрения разработчика, пропустите дальнейшее описание до секции «Запуск main task».

Инициализация порта поддержки аппаратуры. Точка входа в приложение ESP-IDF вызывает функцию call_start_cpu0, код которой находится в components/esp_system/port/cpu_start.c. Эта функция выполняется загрузчиком второй стадии, и из неё никогда не делается возврат.

Эта функция инициализации слоя порта настраивает базовый C Runtime Environment (CRT) и выполняет начальную конфигурацию внутренней аппаратуры SoC:

• Переконфигурирует исключения CPU для приложения, что позволяет запускаться обработчикам прерываний приложения, и инициирует обработку неустранимых ошибок (Fatal Errors) в соответствии с опциями, сконфигурированными для приложения вместо того, чтобы использовался упрощенный обработчик ошибок, предоставленный кодом из ROM.
• Если опция CONFIG_BOOTLOADER_WDT_ENABLE не установлена, то сторожевой таймер (RTC watchdog) будет запрещен.
• Инициализируется внутренняя память (data & bss).
• Завершение конфигурирования кэша MMU.
• Разрешение PSRAM, если это сконфигурировано.
• Настраивается тактирование CPU на частоты, сконфигурированные для проекта.
• Переконфигурируется main SPI flash на основе настроек из заголовка приложения (app header). Это необходимо для обеспечения совместимости с версиями загрузчика до ESP-IDF V4.0, см. секцию «Совместимость загрузчика» документации [7].
• Если приложение сконфигурировано для работы на нескольких ядрах, запускается другое ядро и происходит ожидание завершения его инициализации (происходит аналогично инициализации «слоя порта» в функции call_start_cpu1).

Как когда call_start_cpu0 завершает все эти операции, она вызывает инициализацию «системного слоя» (system layer) в функции start_cpu0, которая находится в components/esp_system/startup.c. Другие ядра будут также завершать инициализацию слоя порта и вызывать start_other_cores, которая находится в том же файле.

Инициализация системы. Основную инициализацию системы выполняет функция start_cpu0. По умолчанию эта функция получает weak-линковку на функцию start_cpu0_default. Это значит, что эту функцию можно переопределить в коде пользователя, чтобы добавить дополнительные шаги по инициализации.

Стадия первичной инициализации системы включает следующие действия:

• Вывод в лог информации о приложении (project name, App Version, и т. п.), если это разрешено уровнем лога по умолчанию.
• Инициализируется управление кучей (heap allocator). До этой точки все выделения памяти должны быть либо статическими, либо память должна выделяться через стек.
• Инициализация компонента newlib syscalls и функций времени.
• Конфигурируется детектор сбоя по питанию (brownout detector).
• Настраиваются libc-потоки ввода/вывода stdin, stdout и stderr в соответствии с конфигурацией последовательной консоли.
• Выполняются проверки, связанные с обеспечением безопасности, включая прошивку efuses, которые должны быть прошиты для этой конфигурации (это включает запрет режима загрузки ROM на ESP32 V3, CONFIG_ESP32_DISABLE_BASIC_ROM_CONSOLE).
• Инициализируется поддержка SPI flash API.
• Производится вызов глобальных конструкторов C++ и любых других функций C, помеченных как __attribute__((constructor)).

Вторичная инициализации системы позволяет настроить отдельные компоненты. Если у компонента есть функция инициализации, анонсированная макросом ESP_SYSTEM_INIT_FN, то она будет вызвана как часть процесса вторичной инициализации.

Запуск main task. После того, как все другие компоненты были инициализированы, создается main task, и запускается планировщик FreeRTOS. После некоторых подготовительных действий (необходимых для запуска планировщика), main task запустит функцию app_main из кода firmware. Содержимое функции определяется разработчиком приложения, в ней может находится как основной алгоритм приложения, так и создаваться другие задачи приложения.

Задача main task, которая запускает функцию app_main, имеет фиксированный приоритет RTOS (на единицу выше минимального приоритета), и конфигурируемый размер стека. Привязка main task к определенному ядру (core affinity) также конфигурируется: CONFIG_ESP_MAIN_TASK_AFFINITY.

В отличие от обычных задач FreeRTOS (которые реализованы как традиционные main-функции языка C), задаче app_main разрешено выполнять возврат. Если это произошло, то задача очищается, и система FreeRTOS продолжает выполнять запущенные из тела app_main задачи традиционным для RTOS образом. Таким образом, можно реализовать app_main либо как функцию, которая просто создает все другие задачи приложения, либо можно использовать app_main для выполнения самого кода приложения.

Second core startup. Это процесс запуска второго ядра APP CPU, который происходит аналогично, однако он несколько проще, чем запуск первого ядра:

Когда работает инициализация системы, код PRO CPU устанавливает точку входа для APP CPU, снимает сброс для APP CPU и ждет установки глобального флага, который должен установить APP CPU (установка флага покажет, что ядро APP CPU запустилось). Как только это было выполнено, APP CPU делает переход в функцию call_start_cpu1, которая находится в components/esp_system/port/cpu_start.c.

В течение выполнения инициализации, которую ядро PRO CPU делает в коде start_cpu0, ядро APP CPU выполняет функцию start_cpu_other_cores. Подобно start_cpu0, эта функция также ликована как weak, и её реализация по умолчанию находится в функции start_cpu_other_cores_default (эта функция может быть заменена пользователем на другую функцию приложения с таким же именем).

Функция start_cpu_other_cores_default делает некоторую специфичную для ядра системную инициализацию и ждет, когда ядро PRO CPU запустит планировщик FreeRTOS, в этот момент выполняется esp_startup_start_app_other_cores. Это другая weak-линкованная функция, реализация которой находится в esp_startup_start_app_other_cores_default.

По умолчанию esp_startup_start_app_other_cores_default ничего не делает, просто прокручивает цикл ожидания (busy-waiting loop) до тех пор, пока планировщик PRO CPU не вызовет прерывание для запуска планировщика на APP CPU.

[Словарик]

APP CPU, PRO CPU условное обозначение двух ядер ESP32, на которые в примерах среды разработки ESP-IDF возлагаются различные задачи приложения.

MMU Memory Management Unit, блок управления памятью.

OTA Over The Air, технология загрузки (обновления) по радиоканалу.

PSRAM Pseudostatic RAM (которая также может называться PSDRAM) это динамическое ОЗУ со встроенным контроллером обновления и схемой управления адресами, которые предоставляют интерфейс доступа, аналогичные статическому ОЗУ (static RAM, SRAM).

RTC Real Timer Clock, таймер реального времени.

SoC System on Chip, система на кристалле.

SRAM static RAM, статическое ОЗУ.

[Ссылки]

1. ESP32 Application Startup Flow site:docs. espressif.com.
2. ESP32: таблицы разделов.
3. ESP-IDF FreeRTOS Task API.
4. ESP32 Deep Sleep Wake Stubs site:docs.espressif.com.
5. Установка среды разработки ESP-IDF для ESP32.
6. ESP32: обновление по радиоканалу (OTA).
7. ESP32 Bootloader.
8. ESP32 How To Use PSRAM site:thingpulse.com.

Ошибки при установке Windows 10 и как их устранить

Главная » Windows 10

Автор: admin

Microsoft сейчас активно агитирует пользователей переходить на новую финальную версию своей операционной системы Windows 10. Улучшенная производительность, новые возможности, дизайн и даже возможность бесплатной активации делают новую ОС очень привлекательной для пользователя. Но, как часто это бывает с софтом, новая система нередко не может установиться из-за различных проблем. Ниже мы разберем самые распространенные случаи, когда при установке или обновлении до Windows 10 выдает ошибку, а также расскажем, как с ними бороться при каждом коде.

Содержание

• 1 Ошибка c1900101-2000c
• 2 Ошибка 0xc1900101 0x20017
• 3 Ошибка 0x8007025d
• 4 Ошибка c1900107
• 5 Общие советы
• 6 Вывод

Ошибка c1900101-2000c

Первой в списке мы поместим достаточно распространенную ошибку обновления, а именно ошибку c1900101 2000c. Ошибка, маркированная подобным образом, возникает при попытке обновиться с 7 или 8 версии Windows до 10. Проблема кроется в повреждении компонентов обновления. Посоветовать здесь можно, во-первых заново скачать образ, во-вторых обновить все драйвера и проверить систему на вирусы. Вообще, гораздо лучшим решением будет установка 10-ки с нуля, нежели обновление.

Ошибка 0xc1900101 0x20017

Ошибка с кодом 0x20017 также касается желающих обновиться с 7 или 8 версии. Ошибка 0xc1900101 0x20017 прерывает обновление, но, к счастью, возвращает систему в исходное состояние, то есть в то, которое было до попытки обновления.

Причиной этой ошибки мы считаем конфликт новой системы с установленными антивирусами и другими приложениями, отвечающими за безопасность. Также возможна несовместимость с драйверами или «железом» пользователя. Отключите перед обновлением антивирус, подключитесь к интернету с помощью кабеля (используйте проводное соединение, а не WI-FI), отключите все устройства, кроме клавиатуры и мышки. Сделали? Теперь воспользуемся командной строкой. Введите «sfc /scannow», после чего поврежденные системные файлы восстановятся, и можно будет продолжать обновление без 0xc1900101 0x20017 проблемы.

Ошибка 0x8007025d

Ошибка 0x80070003 0x8007025d. Такая неприятность возникает из-за проблем с загрузочным сектором. Отформатируйте нужный вам диск при установке, обновите BIOS, проверьте на ошибки оперативную память, проверьте подключение жесткого диска к материнской плате. Докачать и проверить файлы можно с помощью команды wuauclt.exe/updatenow .

Ошибка c1900107

Еще одна распространенная проблема: ошибка c1900107. Хорошим решением при c1900107 будет настройка BIOS, а именно раздела Boot. Ошибка может возникнуть из-за функции Secure boot, которая предотвращает запуск неавторизованной системы, когда включается компьютер. Поэтому не работает загрузка системы с флешки или оптического диска. Рассмотрим, как отключить эту функцию:

1. Заходим в BIOS.
2. Выбираем Security Boot Parameters. В типе операционной системы выбираем Windows 8 UEFI, при этом не важно, какую систему вы хотите установить. Это актуально для новых версий БИОСа.
3. В безопасном режиме загрузке нужно выбрать режим Custom.
4. Щелкаем на управление ключами, Provisioning отключаем, нажимаем на безопасную загрузку ключей, чтобы старые все старые ключи удалить.
5. Вставьте флешку и сохраните настройки. Только перед этим выставьте приоритеты загрузки. Всё, c1900107 ошибка должна исчезнуть.

Впрочем, причина ошибки c1900107 может быть и более простой: все тот же антивирус, либо у вашей учетной записи могут отсутствовать права на обновление и изменение системы.

Общие советы

Практически все вышеперечисленные ошибки возникают именно во время обновления до Windows 10. Поэтому лучше установить систему начисто. Чтобы система установилась правильно, задайте себе следующие вопросы:

1. Правильно ли я настроил БИОС? Нужно выставить загрузку с флешки или диска приоритетной. На флешке должен быть образ с Windows.
2. Исправен ли носитель? Не поврежден ли дисковод, USB порт или оперативная память. Убедитесь в целостности и неповрежденности образа.
3. Исправен ли компьютер? Могут быть проблемы с жестким диском, материнской платой, оперативной платой, жёстким диском или процессором. Если что-то неисправно — отремонтируйте или поменяйте деталь. Есть также специальные утилиты, проверяющие состояние комплектующих.
4. Соответствует ли компьютер минимальным требованиям, выставляемым системой Windows 10? Операционка требует минимум 16 гигабайт места на жестком диске, не менее 2 гигабайт оперативной памяти и процессор с тактовой частотой не менее 1GHz. Но это требования только для установки! Для комфортной работы потребуется конфигурация в два раза мощнее.

Вывод

Windows 10 — система будущего, и пусть вас не пугают возможные ошибки при установке. Microsoft активно работает над устранением ошибок и ведет разъяснительную работу с пользователями, помогая им решить возникающие проблемы. Плюсом является также и возможность «переезда» с лицензионной 7 или 8 на 10. До 29 июля 2016 года есть возможность оставить новую десятку навсегда, без необходимости платить за нее.

6

Понравилась статья? Поделиться с друзьями:

Исследователь утверждает, что безопасная загрузка Windows 11 нарушена на сотнях материнских плат MSI

• Apple M2 Ультра
• Моторола Разр
• Dell XPS 15 9530
• Райзен 5600X3D
• GeForce RTX 4070
• ЧатGPT

homeIT InfrastructureSecurity

Среди требований для установки Windows 11 есть две функции безопасности: доверенный платформенный модуль (TPM) версии 2. 0 и безопасная загрузка. Как мы задокументировали ранее, можно обойти эти требования и в любом случае принудительно установить или обновить Windows 11. Microsoft даже опубликовала взлом реестра, чтобы предоставить пользователям эту возможность. Тем не менее, если вы выполните эту установку без TPM 2.0 или безопасной загрузки, и меню установки, и операционная система протестуют на разных этапах пути, поскольку Microsoft действительно хочет, чтобы эти функции безопасности присутствовали и были активны.

Производители компьютерного оборудования также работают над соблюдением новых стандартов безопасности Microsoft, включая и активируя TPM 2.0 и безопасную загрузку по умолчанию. Однако, согласно новым выводам исследователя безопасности, настройки безопасной загрузки по умолчанию на материнских платах MSI эффективно обманывают Windows 11 и потенциально дают пользователям ложное чувство безопасности.

BIOS MSI показывает, что безопасная загрузка включена с пользовательскими настройками (источник: Давид Потоцкий). эти подписи подтверждают, что производителю оригинального оборудования (OEM) доверяет программное обеспечение. Эта функция предназначена для предотвращения запуска особо вредоносных и устойчивых вредоносных программ во время загрузки системы.

Владельцы материнских плат MSI могли заметить, что безопасная загрузка включена по умолчанию как в BIOS, так и в Windows. Однако, как недавно обнаружил Давид Потоцкий, этих индикаторов недостаточно, чтобы убедиться, что безопасная загрузка работает правильно. Как вы можете видеть на изображении выше, в то время как безопасная загрузка помечена как «Включена» в BIOS, для режима безопасной загрузки установлено значение «Пользовательский», активируя группу подменю с дополнительными настройками безопасной загрузки.

Пользовательские настройки, которые сводят на нет предполагаемое поведение безопасной загрузки (источник: Давид Потоцкий)
Одно из этих подменю, озаглавленное «Политика выполнения образов», содержит правила, определяющие, при каких обстоятельствах безопасная загрузка разрешает запуск программного обеспечения при загрузке системы. Чтобы безопасная загрузка работала должным образом, эти правила должны быть установлены на «Запретить выполнение», что предотвратит запуск программного обеспечения при нарушении безопасности.

Однако, согласно исследованию Дэвида Потоцкого, в конфигурации по умолчанию для широкого спектра материнских плат MSI все эти правила установлены на «Всегда выполнять». Этот вариант эффективно обходит безопасную загрузку, так как система будет запускать любое программное обеспечение при загрузке независимо от того, имеет ли оно подпись, которую безопасная загрузка распознает как безопасную. Таким образом, многие материнские платы MSI, кажется, удовлетворяют требования безопасности Windows 11, помечая безопасную загрузку как «Включено», при этом работая в соответствии с правилами с тем же эффектом, как если бы безопасная загрузка была отключена.

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

Настройка безопасной загрузки Dell EMC PowerEdge UEFI: уменьшение поверхности атаки благодаря полному контролю над сертификатами

Главная
>

Серверы
>

Кибербезопасность PowerEdge
>

Напрямую от разработчиков: технические примечания
>

Настройка защищенной загрузки Dell EMC PowerEdge UEFI: уменьшение поверхности атаки благодаря полному контролю над сертификатами

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

Инструменты управления системой Dell EMC позволяют удалять сертификат ЦС UEFI и добавлять пользовательские записи политики безопасной загрузки. Это облегчает точную авторизацию загрузчиков операционной системы, гипервизоров и микропрограмм устройств ввода-вывода.

В то время как традиционная безопасность центра обработки данных сосредоточена на операционной системе, приложениях, физическом и сетевом уровнях, новые развивающиеся угрозы требуют особого внимания к микропрограмме сервера. Серверы Dell EMC включают безопасную загрузку UEFI для проверки подлинности и авторизации встроенного ПО. Помимо стандартных возможностей настройки безопасной загрузки UEFI для операционных систем (ОС) и гипервизоров (HV), Dell EMC теперь предлагает полные возможности настройки для устройств ввода-вывода. Dell EMC осознает риски, связанные с использованием стандартных ключей подписи UEFI Secure Boot, которые в настоящее время широко используются в отрасли. Для клиентов, которые хотят избежать стандартных ключей из-за некоторых рисков, которые они представляют, Dell EMC предоставляет полные возможности настройки для безопасной загрузки UEFI, предоставляя владельцам систем возможность исключить зависимость от отраслевых ключей и отраслевых центров сертификации.

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

Снижение риска с помощью стандартной безопасной загрузки UEFI

Устаревшие интерфейсы базовой системы ввода/вывода (BIOS) содержат уязвимости с высоким риском и заменяются унифицированным расширяемым интерфейсом встроенного ПО (UEFI). Серверы PowerEdge, поддерживающие UEFI Secure Boot, общеотраслевой стандарт безопасности в предзагрузочной среде, проверяют криптографические подписи драйверов UEFI и другого кода, загружаемого перед запуском ОС. К ним относятся загрузчики ОС и драйверы UEFI для карт PCIe и запоминающих устройств.

Безопасная загрузка — это функция, добавленная в спецификацию UEFI версии 2.3.1. Системный администратор определяет политику безопасной загрузки, которую BIOS применяет к модулям предзагрузочного кода. BIOS использует политику, чтобы определить, следует ли доверять модулям кода. Если какой-либо модуль не соответствует политике, системный BIOS не загружает и не выполняет модуль.

Стандартная политика безопасной загрузки содержит сертификаты отраслевого стандарта, которые авторизуют все сторонние поддерживаемые предзагрузочные микропрограммы, такие как загрузчики ОС, гипервизоры (HV) и устройства ввода-вывода, для этой системы.

Несмотря на то, что стандартная политика безопасной загрузки обеспечивает простой способ развертывания безопасной загрузки UEFI, она по-прежнему сопряжена с риском. Стандартная политика авторизует многие двоичные файлы прошивки, используя только несколько стандартных сертификатов. Эта широкая авторизация подвергает систему широкому набору потенциальных уязвимостей (таких как недавняя уязвимость GRUB2 «BootHole», обсуждаемая ниже).

 

Некоторые владельцы систем снижают риски стандартной политики безопасной загрузки, настраивая политику в соответствии с использованием ОС. Например, если сервер предназначен для загрузки только одной ОС, администраторы удаляют сертификаты , авторизующие другие ОС. Другие владельцы систем, которые разрабатывают пользовательские компоненты ОС (ядра или загрузчики), подписывают компоненты своими ключами. В этом случае владелец системы заменяет стандартные сертификаты в политике пользовательскими сертификатами. Таким образом, пользовательская политика безопасной загрузки снижает риск, разрешая только определенные загрузчики ОС и HV. Серверы Dell EMC поддерживают эти основные настройки.

Однако, как показано на рисунке выше, такие настраиваемые политики по-прежнему включают отраслевые ключи, которые доверяют широкому спектру прошивок устройств ввода-вывода с подписью. Сертификат UEFI CA — часть стандартной политики безопасной загрузки — используется в отрасли для авторизации прошивки устройства ввода-вывода и «прокладки» (начальный загрузчик в дистрибутивах Linux). Удаление сертификата ЦС UEFI желательно, но это создает некоторые проблемы, поскольку получение встроенного ПО ввода-вывода и подписание его пользователем затруднено.

Подход Dell EMC к полной настройке

Dell EMC предоставляет возможности полной настройки для безопасной загрузки UEFI, устраняя зависимость от отраслевых ключей и отраслевых центров сертификации. Эти возможности включают в себя инструменты удаленного управления для авторизации встроенного ПО определенных устройств ввода-вывода и предзагрузочных двоичных файлов. С помощью этих инструментов владельцы систем могут легко настроить свою политику, удалив сертификат ЦС UEFI и добавив вместо него пользовательские записи. Недавний отчет Агентства национальной безопасности правительства США (NSA) документирует тему повышения безопасности серверного оборудования, в частности, упоминает использование PowerEdge UEFI Secure Boot Customization как метода, который обеспечивает значительно более высокий уровень безопасности наряду с гибкостью для поддержки нескольких операционных систем.

Обратите внимание, что Dell EMC разрешает удаление сертификата ЦС UEFI независимо от того, решит ли владелец системы использовать свою собственную инфраструктуру открытых ключей (PKI). Владельцы систем, которые поддерживают свои собственные PKI, полагаются только на записи пользовательской политики (см. пятый уровень на рисунке выше). Другие владельцы систем, которые не поддерживают свою собственную инфраструктуру PKI, могут доверять ключам поставщика ОС и по-прежнему использовать подход Dell EMC для авторизации встроенного ПО определенных устройств ввода-вывода (см. четвертый уровень на рисунке выше). Таким образом, владельцы систем без собственной PKI могут снизить риск сертификата UEFI CA.

Сертификат операционной системы	Авторизация прошивки устройства ввода-вывода	9002 3 Возможна ли такая конфигурация на серверах Dell EMC?
Microsoft	Стандартный (UEFI CA)	Да 9 0086
Microsoft	Индивидуальный	Да
VMWare / ESXi	Стандарт (UEFI CA)	Да
VMWare / ESXi	Индивидуальный	900 23 Да
Linux (UEFI CA)	Стандарт (UEFI CA)	Да
Linux (UEFI CA)	Индивидуальный	Да
0086	Стандартный (UEFI CA)	Да
Linux (Пользовательский CA / PKI)	Индивидуальные	Да

привлекательно для владельцев систем, которым нужен точный контроль над авторизацией прошивки. При обнаружении уязвимостей в микропрограммах или загрузчиках с промышленной подписью точный метод авторизации Dell EMC может помочь устранить уязвимость, как в случае с уязвимостью GRUB2 BootHole.

В июле 2020 года исследователи обнаружили уязвимость переполнения буфера в загрузчике GRUB2 Linux , которая позволяет выполнять произвольный код в GRUB2. Эта уязвимость, получившая название «BootHole», имеет большое значение, поскольку GRUB2 обычно запускается загрузчиком ранней стадии «shim», авторизованным сертификатом ЦС UEFI. Таким образом, злоумышленники могут изменить процесс загрузки, даже если включена безопасная загрузка UEFI. Эксплойт возможен как в системах Linux, так и в Windows.

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

 

В заключение

Настройка безопасной загрузки Dell EMC UEFI служит для минимизации поверхности атаки в предзагрузочном микропрограммном обеспечении.