Runtime smm polling что это bios

Runtime SMM (System Management Mode) polling в BIOS относится к методу, который используется для мониторинга и управления состоянием системы во время выполнения. Это позволяет BIOS реагировать на события в реальном времени, такие как изменения в температуре, напряжении или состоянии компонентов, обеспечивая тем самым оптимальную работу и стабильность системы.

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

Технология SMM и ее применение в компьютерной безопасности

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

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

Введение

Архитектура x86 подразумевает наличие как минимум трех различных уровней привилегий для выполнения инструкций процессором [1]. уровни привилегий называются кольцами защиты (англ. protection rings), где код, исполняемый в центральном кольце («ring 0»), обладает наибольшим доступом в операционной системе (ОС), а во внешнем кольце («ring 3») – наименьшим [Там же]. Эти уровни привилегий предназначены для реализации аппаратного разграничения доступа процесса к ресурсам ЭВМ (например, к портам ввода-вывода) и реализованы в ЭВМ в виде различных режимов работы центрального процессора (ЦП).

Помимо обычных уровней привилегий, присущих операционным системам, существуют и более привилегированные уровни доступа, которые имеют еще больший контроль, чем «ring 0». Эти уровни располагаются в отрицательной области чисел и работают с определёнными режимами процессора [Там же]: «ring -1» представляет режим гипервизора, а «ring -2» — режим управления системой (SMM) [1]. Также стоит отметить наличие режима «ring -3», который основывается на технологиях Intel Management Engine (ME) для процессоров Intel и AMD Secure Technology для процессоров AMD [2, 3]. Режимы гипервизора и SMM предполагают использование соответствующих технологий, где применяется выделенная память, недоступная для менее привилегированных режимов, а также программное обеспечение, независимое от операционной системы: ядра, приложения и драйвера.

При этом уже в режиме супервизора (то есть на уровне «ring 0») исполняемые процессором инструкции обладают практически полным доступом к ресурсам ЭВМ, и этот доступ может контролироваться только более привилегированными режимами [1]. Вместе с этим выполнение инструкций в режимах «rings -1, -2, -3» для операционной системы (ОС) прозрачно и не отслеживаемо напрямую [4, 5]. Поэтому, с одной стороны, такие технологии являются ключевыми для атак низкого уровня [6, 7] и могут представлять угрозы для средств защиты информации (СЗИ), функционирующими с привилегиями не ниже «ring 0». А с другой стороны, с помощью таких технологий можно расширить функциональность существующих СЗИ, либо попытаться реализовать полнофункциональное СЗИ на основе таких технологий.

Методы исследования (Research methods)

В данном материале будет обсуждаться исключительно SMM из ранее упомянутых методов, а основная цель исследования заключается в оценивании потенциала применения SMM-технологий в процессе разработки систем защиты информации (СЗИ). В исследовании применяются такие методы, как анализ, абстрагирование, сравнение и эксперимент. Объект исследования – SMM, а предмет – возможности применения SMM-механизмов для создания СЗИ.

Обзор литературы (Literature review)

1. Характеристика SMM

System Management Mode (SMM) является привилегированным режимом выполнения кода у x86 совместимых процессоров (Intel, AMD), впервые реализованный компанией Intel в своих процессорах в середине 90-х годов [8]. С момента создания и до сих пор этот режим используется для совершения действий, которые были бы незаметны и практически не отслеживаемы для ОС, но при этом выполняемый код обладал полным доступом к памяти и всем подключенным устройствам [5].

В начале SMM использовался для управления энергопотреблением компонентов электронных вычислительных машин: обработчики событий в SMM собирали данные о работе устройств, и при длительном отсутствии активности устройства отключались [8]. Таким образом, изначально SMM не занимался вопросами безопасности, а привилегированный режим был необходим для постоянного мониторинга всех устройств ЭВМ. В настоящее время управление энергопотреблением компонентов ЭВМ осуществляется не через SMM, а осуществляется с помощью операционной системы [Там же].

Для активации режима SMM процессора используются системные прерывания управления (SMI), которые могут быть инициированы элементами материнской платы или различными драйверами, приложениями (включая приложения операционной системы) или пользователями с правами администратора в ОС [5]. К распространённым системным SMI, которые поддерживаются в большинстве современных компьютеров (в частности, по данным документации, для ПК с чипсетами серий 8/9/200/300 от Intel [9–10 часть 12.8.3.7, 11–12 часть 5.2.4]), можно отнести следующие прерывания и соответствующие события [5, 9–10 часть 12.8.3.7, 11–12 часть 5.2.4]:

GPIO Unlock SMI – возникает, когда бит Lock (GLE) в регистре управления GPIO становится снятым. Обработчик проверяет, какое ПО инициировало это действие, и в случае его неавторизованности восстанавливает бит;
TCO SMI – создается в результате разных событий. Обработчик прерывания выполняет необходимые действия в зависимости от источника прерывания.
Прерывание возникает благодаря таймеру обратного отсчета Intel TCO watchdog, когда таймер достигает нуля. Операционная система должна периодически обновлять таймер каждые несколько секунд. Если таймер достигнет нуля, будет инициировано прерывание, и его обработчик запустит перезагрузку системы.
Прерывание возникает при установке бита BIOSWE в регистре управления BIOS, который отвечает за доступ к ПЗУ, содержащему код BIOS. Если бит установлен в режиме SMM, прерывание не произойдет, так как код уже выполняется в этом режиме; если же бит активируется в любом другом режиме, прерывание состоится, после чего вызовется обработчик, который вернет бит в прежнее состояние. Данный механизм предназначен для предотвращения несанкционированной перезаписи прошивки компьютера из режимов, отличных от SMM.

2. SMM memory (SMRAM)

Для обеспечения изоляции среды выполнения операций в SMM используется память SMM memory (SMRAM), где хранятся все нужные данные для функционирования SMM: код, обработчики прерываний и информация о состоянии регистров (процессор сохраняет контекст при переходе в SMM). Если операция осуществляется не в режиме SMM, а в обычном (менее привилегированном), доступ к этой памяти закрыт, то есть нельзя ни прочитать, ни записать данные. SMRAM может содержать следующие области (вывод о применении или непригодности дан в контексте современных ЭВМ с типовой конфигурацией SMM) [5, 8]:

ASEG [0x000A0000-0x000BFFFF] – не используется,
HSEG [0xFEDA0000-0xFEDBFFFF] – не используется,
TSEG [настраиваемый диапазон] – используется.

3. Инициализация SMRAM

Рекомендуется рассматривать инициализацию SMRAM и осуществление работы SMM с применением UEFI BIOS, а не Legacy BIOS, так как большинство современных компьютеров применяют именно интерфейс UEFI, а компания Intel планирует в ближайшем будущем полностью отказаться от поддержки Legacy BIOS в своих устройствах [13].

Весь код SMM, включая обработчики SMI, хранится в UEFI BIOS, который содержится в постоянной памяти. Этот код загружается в SMRAM и конфигурируется единожды при запуске компьютера на этапе SMM, который, в свою очередь, является частью фазы DXE (все этапы показаны на рисунке 1) [14]. После этого фаза SMM остается активной на протяжении всего времени работы компьютера, параллельно с другими фазами Run Time (RT).

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

Иллюстрация 1. Этапы загрузки системы с использованием UEFI

4. Регистры SMM

Для правильного функционирования SMRAM и организации доступа к этой памяти применяется ряд регистров. Ключевым и основным регистром является регистр управления System Management RAM (SMRAMC) [15 часть 3.29]. Значение SMRAMC устанавливается во время инициализации SMRAM, после чего регистр блокируется до следующего перезапуска ЭВМ [16]. В этом регистре наиболее значимыми являются биты D_OPEN и D_LCK, которые должны быть установлены в 0 и 1 соответственно в любой корректно настроенной системе, чтобы память SMRAM могла быть доступна только из кода, исполняемого в SMM.

Существуют также производные регистры, предназначенные для обеспечения корректного доступа к памяти, которые были созданы в ответ на выявление различных векторов атак на SMM (эти регистры также должны быть правильно настроены и заблокированы аппаратным обеспечением):

Регистр диапазонов управления системой (SMRR) – устанавливает зоны памяти, в которые записи, не принадлежащие к SMM, игнорируются, а вид памяти имеет свойство некэшируемости. Данный параметр должен быть правильно настроен производителями. Угроза: отравление кеша SMM [17]
Регистр TSEGMB у контроллеров DMA – содержит информацию о расположении TSEG и блокирует запись в эту область через DMA. Он также должен быть правильно настроен производителями. Угроза: атака через DMA [18];
Бит SMI_LOCK в регистре General PM Configuration и бит SMM_BWP в регистре BIOS Control – отвечают за создание SMI во время обновления прошивки. Угроза: отключение создания SMI, что позволяет перепрошивку BIOS неавторизованным программным обеспечением [19].

Результаты (Results)

1. Меры безопасности с применением SMM

SMM предназначен для обработки прерываний, которые сгенерированы либо системой (системные SMI), либо прошивкой / драйверами / приложениями, обладающими доступом с правами администратора в ОС (программные SMI) при помощи записи в APM_CNTI/O порт. Таким образом, возможно создание лишь двух типов функции (обработчиков SMI) на основе SMM:

Разработка обработчика системных SMI. Его можно активировать через программное обеспечение в операционной системе.
Усовершенствование обработчика системных SMI. Такой обработчик будет вызываться автоматически при определенных событиях (это зависит от типа SMI).

С учетом характеристик SMM (привилегированность, изолированность среды выполнения команд SMM, размещение кода SMM в BIOS) можно рассмотреть использование обработчиков SMI для реализации функций, которым требуется одно из следующих свойств:

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

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

1.1. Создание обработчика программных SMI

Чтобы активировать обработчик SMI, требуется правильно настроенный бит APMC_EN в регистре SMI_EN[9–10 раздел 12.8.3.7, 11–12 раздел 5.2.4]. Этот бит имеет режим R/W и может быть изменён в любой момент, если функция блокировки для регистра SMI_EN не реализована. Поэтому не стоит рассчитывать на надёжное срабатывание прерывания, так как отсутствует встроенная функция блокировки.

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

незамедлительное выполнение перезагрузки или отключения системы при обнаружении попыток несанкционированного доступа;
аудит учетных данных и увеличение прав доступа пользователя;
создание дочерних сертификатов/ключей на основе корневого сертификата/ключа с невозможностью прочитать корневой сертификат/ключ;
активация/деактивация/проверка компонентов системы и внешних устройств (например, верификация контрольной суммы BIOS или отключение одного из USB-устройств через интерфейс xHCI);
настройка регистров, контролирующих доступ к системным компонентам и периферийным устройствам (например, включение/выключение функции записи на жесткий диск).

1.2. Усовершенствование обработчика системных SMI

Чтобы активировать обработчик системных SMI, необходимо правильно настроить бит включения прерываний в регистре SMI_EN для нужного типа прерываний [9–10 часть 12.8.3.7, 11–12 часть 5.2.4]. Большинство этих битов имеют режим R/W и, подобно биту APMC_EN, могут быть изменены в любое время при отсутствии функции блокировки регистра SMI_EN. Поэтому, как и в случае с программными SMI, нельзя рассчитывать на стабильное срабатывание большинства системных SMI без наличия функции блокировки. Однако некоторые прерывания обладают встроенной функцией блокировки соответствующих битов. Например, для всех современных ПК на архитектуре x86 такими битами являются: GPIO_UNLOCK_SMI_EN и TCO_EN.

На базе таких обработчиков можно реализовать более специфичные функции с автоматически генерируемыми прерываниями различными компонентами системы при наступлении конкретных событий (зависит от компонента и типа SMI). Примеры возможных функций безопасности:

можно изменить обработчик TCO SMI для работы с запросами на перепрошивку;
можно доработать или полностью заменить обработчик GPIO Unlock SMI, чтобы управлять доступом операционной системы к GPIO-выводам;
обработчик xHCI SMI (бит xHCI_SMI_EN является R/W) может быть модифицирован или дополнен нужными функциями для обработки различных событий, связанных с USB-устройствами [20 часть 4.22.1];
обработчик Periodic SMI (бит PERIODIC_EN является R/W) может быть изменен или дополнен для выполнения указанного кода с заданным периодом многократно.

2. Преимущества и недостатки SMM для средств защиты информации

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

2.1. Преимущества SMM

Основные

Эксклюзивный доступ.

В базовом сценарии SMM предоставляет максимальный доступ к системе среди прочих встроенных в систему технологий (за исключением технологий, которые базируются на РКБ).

Низкая стоимость и высокая надежность.

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

Технические

Начальная стадия работы.

Код SMM загружается и активируется в фазе DXE во время процесса загрузки UEFI. Эта фаза наступает после SEC и PEI, а перед выбором загрузочного устройства (BDS) (см. рисунок 1) [21]. С одной стороны, наличие двух предварительных фаз перед активацией SMM может рассматриваться как недостаток, однако с другой стороны, это создает возможность для кода SMM взаимодействовать с памятью (инициализируемой на PEI) и взаимодействовать с системными устройствами. Полноценное функционирование SMM начинается лишь после блокировки SMRAM, к концу фазы DXE, то есть к моменту завершения этой фазы SMRAM уже будет заблокирован, и SMM сможет обрабатывать поступающие запросы. Таким образом, на этапе BDS можно утверждать о полном развертывании технологии SMM.

Встроенная защита кода SMM от перезаписи.

Ключевой задачей SMM в настоящее время является выполнение запросов на обновление BIOS, в котором находится код SMM. Следовательно, при корректной настройке SMM можно обеспечить защиту кода SMM от неавторизованных вмешательств (не учитывается обновление памяти через аппаратные методы).

2.2. Минусы SMM

Основные аспекты

Уверенность в поставщике.

При использовании SMM необходим РКБ для построения доверенной системы (в том числе для того, чтобы контролировать недоверенный процессор [22]), либо необходимо доверять процессору (который в таком случае будет выполнять некоторые задачи РКБ) и, как следствие, доверять вендору. Также, поскольку системные SMI генерируется различными компонентами системы (например, xHCI контроллером, отвечающий за взаимодействие с USB), необходимо доверять этим контроллерам в части срабатывания прерываний при наступлении конкретных событий.

Технические

Зависимость от платформы.

Технология SMM обладает высокой зависимостью от платформы и предназначена исключительно для архитектуры x86. Кроме того, стоит отметить, что производители (включая Intel и AMD) не несут ответственности за наличие определённых системных SMI по умолчанию в системе (это можно найти в документации [9–10 часть 12.8.3.7, 11–12 часть 5.2.4]).

Ограничения по объёму памяти.

Согласное документации под сегмент TSEG SMRAM может быть выделено 1, 2 или 8 MB (мегабайт) [16 часть 3.37], что ставит ограничения на разрабатываемый код.

Основная часть битов в регистре SMI_EN имеет режим R/W.

Учитывая, что основная часть битов в регистре SMI_EN работает в режиме R/W, нельзя рассчитывать на срабатывание определённых SMI. Для решения данной проблемы необходимо создать индивидуальную логику в SMM, способную блокировать нужный бит.

Обсуждение (Discussions)

Таким образом, наиболее разумным и простым способом применения SMM становится использование этой технологии для создания небольшого хранилища данных, либо функций, доступ к которым будет ограничен в чтении и изменении через SMI обработчики. При этом взаимодействие с данной областью памяти можно осуществлять напрямую из операционной системы. В открытых источниках существует множество примеров реализации связи между кодом ОС и кодом SMM [14, 23, 24].

С другой стороны, существует возможность задействовать автоматически генерируемые SMI, создаваемые платформой контроллера PCH. Однако этот метод эффективен только в случае блокировки битов, отвечающих за активацию прерываний, что требует реализации дополнительной функциональности для обеспечения неизменности этих битов. Документация Intel не упоминает о возможностях блокировки таких битов [9–10 часть 12.8.3.7, 11–12 часть 5.2.4], а случаи атак на ЭВМ [25], в которых происходят изменения этих битов, подчеркивают наличие атакующих векторов при реализации СЗИ через SMI. Тем не менее, существует патент на блокировку регистра SMI_EN (см. [26]), который в большей степени описывает архитектурные возможности улучшения чипсета (в частности, южного моста чипсета), нежели возможности программной блокировки регистра. Таким образом, предложенный в патенте метод блокировки может быть полезен для производителей компьютерной техники, поскольку они способны вносить значительные изменения в конструкцию компонентов ЭВМ, но не является оптимальным для разработчиков СЗИ.

Заключение (Conclusions)

Из приведенных выше рассуждений можно заключить, что так как код, выполняющийся в SMM, имеет достаточно высокий уровень доступа к ЭВМ, данный режим остается весьма привлекательным для анализа на предмет уязвимостей с целью формирования рекомендаций по правильному конфигурированию. Однако, учитывая архитектурные особенности этой технологии, внедрение новых средств безопасности с помощью SMM оказывается сложной и неоправданной задачей. Следовательно, в современных ЭВМ важно корректно настраивать SMM и не стоит полагаться на эту технологию при разработке систем защиты информации.

Литература (References)

Ссылка на источник: Пахомов М. В. Использование технологии SMM в сфере компьютерной безопасности // Вопросы защиты информации. Москва, 2021. Выпуск 4. Страницы 13–19.

Режим SMM в процессорах

Процессор может переходить в режим SMM по сигналу, поступающему на вход SMI # (System Management Interrupt), однако более современные процессоры способны активировать этот режим также при получении соответствующего сигнала по шине контроллера прерываний APIC. Сигнал SMI # считается запросом на прерывание с высшим приоритетом. При обнаружении активного сигнала SMI # процессор, завершив выполнение текущей инструкции и выгрузив буферы записи, переключается в режим SMM и генерирует сигнал SMIACT # на выходе. В тот же момент, когда процессор входит в SMM, он сохраняет свой контекст (включая почти все регистры) в специальной памяти SMIRAM. Эта память использует часть адресного пространства физической памяти, к которой доступ возможен только при наличии сигнала SMIACT #. После окончания сохранения контекста процессор начинает выполнять программу-обработчик SMI, хранящуюся в памяти SMIRAM. Эта программа-обработчик состоит из серии обычных инструкций, которые процессор выполняет в режиме, схожем с реальным режимом.

При входе в режим SMM автоматически запрещаются аппаратные прерывания (маскируемые и немаскируемые) и не генерируются исключения, поэтому действия процессора определяются программой-обработчика SMI. Программа-обработчик завершается инструкцией RSM ( RSM выполняется только в режиме SMM ), по которой процессор восстанавливает свой контекст из SM I RAM, и возвращается в обычный режим работы.

Начиная со второго поколения процессоров Pentium, существует возможность перезапуска инструкций и входа в SMM по сигналу, полученному с шины APIC. Возвращение из режима SMM может происходить различными способами в зависимости от требований программы-обработчика (учитывая ограничения, связанные с аппаратным обеспечением и конкретной моделью процессора в режиме SMM). Программа-обработчик может модифицировать контекстный образ процессора, что позволяет процессору вернуться в состояние, отличное от того, в котором произошло переключение в режим SMI.

Возможен выбор варианта для случая, когда прерывание SMI возникло во время останова процессора по инструкции HALT :

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

Процессоры, начиная со второго поколения Pentium, также поддерживают возможность повторного выполнения команды ввода-вывода, предшествующей появлению сигнала SMI #. Данная функция восстановления команды ввода-вывода является расширением режима SMM. Она используется, например, когда приложение (или системный драйвер) пытается выполнить операцию ввода-вывода с периферийным устройством, находящимся в «спящем» состоянии. В этой ситуации системная логика должна инициировать сигнал SMI # раньше, чем сигнал готовности устройства к обмену RDY #, который завершает циклы шины для восстановленной команды ввода-вывода. Обработчик SMI «разбудит» устройство, после чего операция ввода-вывода возобновляется, и приложение (или драйвер) не заметит, что устройство находилось в «спячке». Таким образом, управление потреблением энергии может быть полностью «прозрачным» для прикладного программного обеспечения и операционных систем (ОС). Прозрачность режима SMM обеспечивается следующими характеристиками:

— предоставлением лишь аппаратного доступа к режиму SMM,

— исполнением программы-обработчика SMM в отдельном адресном пространстве памяти,

— хранением состояния приостановленной программы в памяти SM I RAM,

— запретом обычных аппаратных прерываний,

— восстановление состояния задачи, которая была прервана, при выходе из режима SMM.

SM I RAM должна представлять собой физически или логически зарезервированное пространство размером от 32 Кб (минимум) и до 4 Гб. SM I RAM начинается с адреса SMIBASE (по умолчанию 30000 h) и распределяется относительно этого адреса следующим образом:

FE 00 h — FFFFh (от 3 FE 00 h до 3 FFFFh) — область для сохранения контекста (распределяется начиная с более высоких адресов к более низким). При возникновении прерывания SMI происходит сохранение практически всех регистров процессора, включая регистры, недоступные программно: CR 1, CR 2 и CR 4, а также аппаратные скрытые регистры CS, DS, ES, FS, GS и SS, используемые для хранения дескрипторов. Однако для регистров DR 5-DR 0, TR 7-TR 3 и регистров FPU автоматическое сохранение не выполняется;
8000 h (38000 h) — начальная точка для обработчика (SMI Handler);
0-7 FFFh (30000 h — 37 FFFh) — участок, предназначенный для свободного использования.

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

Режим работы SMM напоминает однопоточный режим с использованием реального адреса и обладает рядом характерных особенностей и свойств:

— вычисление адресов аналогично реальному режиму;

— предел установлен на уровне 4 Гб;

— флаг прерывания IF деактивирован;

— немаскируемое прерывание NMI запрещено;

— флаг TF в регистре EFLAGS отключен, режим по шагам не разрешен;

— регистр DR7 сброшен, отладочные ловушки запрещены;

-инструкция RSM работает корректно (в иных режимах она приводит к ошибке некорректного кода операции).

По умолчанию применяется 16-битный режим для регистров, стека и команд.

Контекст математического сопроцессора (и регистры ММХ) при SMI автоматически не сохраняется, поскольку операции FPU в режиме SMM вряд ли кому-либо потребуются. Однако если SMI используется для выключения процессора, контекст FPU может быть программно сохранен обработчиком.

О безопасности UEFI, часть вторая

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

Вторая часть. SMM

Немного теории

Информацию о SMM, благодаря специалистам по поисковой оптимизации и сетевому маркетингу (будь они здоровы!), решительно невозможно найти в сети по запросу «SMM», постоянно натыкаешься на предложения что-нибудь увеличить, ускорить и улучшить, поэтому будем проводить ликбез не отходя от снаряда. System Management Mode— один из наиболее привилегированных режимов исполнения кода у x86/amd64-совместимых процессоров, впервые появившийся в специальной SL-версии Intel 80386. Начиная с 80486 поддерживается всеми x86 CPU, в том числе производства AMD и VIA. Изначально SMM использовался для независимой от ОС реализации автоматического управления питанием и системными устройствами, т.к. научить этому ОС того времени было сложнее, чем добавить еще один режим исполнения в процессор. Переход в режим SMM выполняется только при помощи специального прерывания — SMI , которое генерируется различными способами: — аппаратно, выдачей высокого уровня на вывод SMI# — самой системой, как результат каких-то событий — программно, отправкой байта в CPU IO-регистр с заданным номером (чаще всего это регистр 0xB2)

Аппаратное SMI

Нечего особо сказать по этому поводу: подаем питание на ногу — получаем прерывание. В настоящее время такой подход используется редко, поскольку почти все системы оснащены многофункциональными GPIO, которые способны генерировать события без прерывания работы операционной системы, и не требуется дополнительная логика для определения, какое именно устройство вызвало аппаратное SMI, так как устройств много, а нога лишь одна.

Системные SMI

xHCI SMI — инициируется USB-контроллером, что позволяет реализовать эмуляцию устаревшего USB и загрузку с USB-накопителей в DOS
ME SMI — возникает от МЕ и позволяет работать с ним системам, которые не имеют родного драйвера для основного интерфейса ME — HECI
SMI для разблокировки GPIO — возникает при удалении состояния Lock из регистров, отвечающих за управление выводами GPIO. Разработчик прошивки имеет возможность привязать к этому SMI собственный обработчик, который будет разрешать или запрещать ОС доступ к определенным GPIO.
Периодический SMI — создается чипсетом с использованием внутреннего таймера, который может быть настроен на интервалы 8/16/23/64 секунды, хотя обычно функция этого SMI отключена.
TCO SMI — активируется таймером TCO, если он включен. TCO представляет собой специфичный для Intel таймер контроля, который ОС обязана перезаряжать каждые несколько секунд, чтобы уведомить таймер о своей исправности. Если таймер достигает нуля, генерируется SMI, в обработчике которого, как правило, инициируется перезагрузка системы.
EC SMI создается чипсетом при обращении к IO-портам CPU в диапазоне 0x62-0x66, где обычно расположен EC. Это позволяет либо организовать его эмуляцию, либо защитить его прошивку от изменений. Чаще всего данный источник отключен, и запросы к указанному диапазону сразу же перенаправляются на шину LPC, к которой подключен физический EC. Если же его нет, чипсет возвращает 0xFF на все запросы, и на этом всё заканчивается.
APMC SMI возникает при записи в CPU IO-порт APM_CNT, более подробно о нем будет рассказано в следующем разделе.
SLP SMI возникает при переходе в состояния ACPI S1-S5, точнее при попытке установить бит SLP_EN. Через это прерывание реализуются Sx-ловушки, что позволяет запустить платформо-зависимый код перед переходом в режим сна или гибернации.
IOTR SMI генерируется при взаимодействии с портами ввода-вывода процессора. Это прерывание используется для реализации IO-ловушек, которые позволяют эмулировать устаревшие устройства, ранее подключенные к IO-портам, такие как SuperIO, клавиатура, аудиочипы, порты MIDI, COM и LPT, а также ряд других компонентов. Ваша USB-клавиатура функционирует в DOS благодаря перехвату обращений к IO-портам 0x60/0x64, выполненному либо SuperIO, либо IO Trap.
И еще несколько других аспектов, о которых говорить слишком долго, поэтому всех заинтересованных отправляю к соответствующей документации.

Программные SMI

Программные SMI в большинстве случаев создаются либо через прошивки, либо с использованием драйверов, однако ничто не препятствует злоумышленнику с правами администратора в операционной системе (при этом нужны права для выполнения команды out) также инициировать их. Программное SMI активируется при обращении к порту ввода-вывода процессора APM_CNT (обычно это порт 0xB2), где номер передается в регистре AL. Таким образом, максимальное количество уникальных обработчиков программных SMI в системе составляет 256, но на практике их число варьируется от 0-5 на специализированных платформах, настроенных для работы с RTOS, до 15-20 на системах с разнообразным оборудованием, которое нужно контролировать без участия операционной системы.

Структура SMM

Для кода SMM-диспетчера и обработчиков SMI выделяется 1-3 области физической памяти, которую во всех «обычных» режимах исполнения чипсет помечает как область MMIO с несуществующим устройством, т.е. для всего остального мира эти области — сплошная череда 0xFF, которые невозможно перезаписать. Первая область, называемая обычно ASEG(т.е. «сегмент А»), предназначена для т.н. legacy SMM code, т.е. старых 16-битных обработчиков SMI, которых на современных системах уже нет.

Сегмент получил свое название благодаря тому, что располагается по фиксированным физическим адресам от 0xA0000 до 0xBFFFF. Вторая область с установленными адресами называется HSEG (то есть «высокий сегмент»), которая раньше находилась в диапазоне 0xFEDA0000 — 0xFEDBFFFF, но в современных системах больше не используется, так как появился более удобный сегмент с настраиваемыми адресами и размерами — TSEG (то есть «топовый сегмент»). В этом сегменте сейчас находится 99% кода, выполняемого в SMM, в то время как ASEG служит лишь небольшой заглушкой для обеспечения совместимости.

При переходе в SMM процессор сохраняет практически весь контекст (т.е. содержимое практически всех регистров, какие именно не сохраняются — зависит от конкретной микроархитектуры), причем к сохраненному контексту у обработчиков SMI есть полный доступ, и потому он может общаться с системой через изменение сохраненных значений. Для ОС вызов SMM кода выглядит как волшебное изменение содержимого регистров и памяти, и хотя отследить длительность нахождения в SMM все же можно по косвенным признакам, а факт перехода в него — по непосредственным, при помощи чтения регистра MSR_SMI_COUNT до и после вызова инициации программного прерывания, но повлиять на длительность обработчика SMI ОС не может, поэтому SMM плохо совместим с hard-RTOS (стоит отметить, что вся архитектура x86 совместима с ними весьма через раз, но это другая история). При настройках по умолчанию работающий в SMM код имеет полный доступ ко всей физической памяти на чтение и запись, полный доступ ко всем подключенным устройствам, в общем — может практически все, и при этом независим от ОС и недоступен из нее даже на чтение, что сильно затрудняет его анализ и делает код обработчиков SMI весьма привлекательной целью для атаки. Более того, если атакуемой системе доступна из SMM запись на SPI-микросхему (а она доступна во всех случаях, кроме систем с включенной PFAT, которые не найти с огнем, систем с Read-only BIOS’ом, которые встречаются еще реже, и систем с защитой через PR-регистры), то успешная атака может закончиться записью своего кода в BIOS, с последующем воровством, убийством и непотребством с гусями. Именно поэтому защитить SMM от вставки туда вредоносного кода — жизненно необходимо.

Атаки на SMM и защита от них

Забытая D_LOCK

Код в SMRAM не появляется без участия человека, прежде всего необходимо правильно настроить SMRAM, инициализировать физическую память, задать параметры TSEG так, чтобы все обработчики могли разместиться, переместить туда код SMM-диспетчера и обработчиков, а также правильно установить таблицы дескрипторов — в общем, создать порядок, после чего следует обязательно установить бит D_LOCK и снять бит D_OPEN, чтобы предотвратить нарушения. На некоторых устаревших системах забывали активировать D_LOCK, из-за чего SMM оставался открытым для атак, однако в эпоху UEFI данная проблема уже устранена, и этот вектор нападения стал частью истории.

Отравление кэша SMM

Еще одна знаковая атака — это отравление кэша SMRAM, о которой в 2009 году рассказали Рафал Войтчук и Иоанна Рутковска. Суть атаки заключается в следующем: мы изменяем тип памяти для региона SMRAM на Write-Back, создаем запись своего кода в этот регион SMRAM. Хотя запись в память не осуществляется, наш код сохраняется в кэше второго уровня. Затем мы генерируем программное SMI, и процессор начинает считывать данные не из SMRAM, а из кэша, что приводит к выполнению нашего вредоносного кода. Проблема была решена кардинально: производители процессоров запретили использование режима WB для SMRAM, поэтому системы с UEFI защищены от данной уязвимости.

Вызов SMM, также известный как атака на внедрение SMM

Но достаточно истории, перейдем к «современным» атакам. Начнем, пожалуй, с той самой SMM Incursion Attack, о которой тов. maseal упомянул в комментарии к первой части. Я специально поставил слово «современные» в кавычки, ибо этой атаке — сто лет в обед, впервые о ней сообщали еще в 2008 году как проблему тогдашних BIOS’ов, но в 2015 ее вновь переоткрыли Corey Kallenberg и Xeno Kovah.

Атака аналогична простому мычанию — если обработчик SMI инициирует выполнение кода вне SMRAM, то злоумышленник с правами на запись в физическую память способен изменить вызываемый код на свой и осуществить его выполнение в режиме SMM. Поскольку разработчики UEFI привыкли к доступности EFI Runtime-сервисов, эти сервисы регулярно вызывались из обработчиков SMI при каждом удобном случае (чаще всего это были запросы GetVariable, SetVariable и ResetSystem).

Уязвимости оказалось подвержено столько систем, что проще сказать, где их не было. По моей грубой оценке, если ваш UEFI старше мая-июня 2015 года по build date, в нем гарантированно имеется пара уязвимых к этой атаке обработчиков SMI.

Удалить из системы такие проблемные обработчики довольно трудно, и поскольку раньше такое поведение не рассматривалось как уязвимость («кто дерзнет вмешиваться в сервисы?!»), простые разработчики не были осведомлены о недопустимости таких действий — даже сейчас периодически выходят обновления для драйверов времени выполнения, затрагиваемых этой проблемой. В общем, ситуация печальная.

Чтобы предотвратить вызов кода, находящегося вне SMRAM, инженеры Intel внедрили специальный MSR_SMM_FEATURE_CONTROL, активация определенного бита которого вызывает немаскируемое и невосстановимое MCE при попытке выполнить такой код. Однако такой MSR присутствует только у процессоров серии Haswell и новее, а возможность его использования активируется лишь во время отладки прошивки, поскольку в противном случае пользователи могут прийти к разработчикам с серьезными претензиями из-за непонятных зависаний — большинству требуется, чтобы всё функционировало сейчас, а безопасность, казалось бы, избыточна. Для обладателей более старых систем и процессоров AMD инженеры Phoenix нашли своеобразное решение, используя NX-бит для настройки памяти SMM-кода таким образом, чтобы обращение к коду за пределами SMRAM приводило к Page Fault, который можно обработать, а не вызывать зависание с MCE. Признаюсь, я пока еще не реализовал это решение у себя, но, когда появится время, обязательно займусь. Обычному пользователю остается только избегать выполнения неясного кода от пользователя с административными правами, но, к сожалению, это практически невозможно в современных операционных системах — возможности для локального повышения привилегий по-прежнему многочисленны, и статистику по 0day-эксплойтам сейчас так просто не собрать. Осталось только сослаться на ранее упомянутого Ксено Кова:

Пожалуйста, не забывайте установить обновления!

Атака DMA

Еще одна интересная атака, на этот раз — с помощью своего же чипсета. Дело в том, что у современных чипсетов имеется контролер DMA , который используется для разгрузки CPU от задач пересылки данных из памяти и в память, как между DRAM, так и между DRAM и памятью PCIe-устройств. Причем инициировать такую передачу может как ОС, так и PCIe-устройство, у которого тоже может быть свой DMA-контролер.

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

То же самое может сделать и прошивка контролируемого атакующим PCIe-устройства. Для защиты от DMA-атаки у DMA-контролеров Intel имеется регистр TSEGMB в котором дублируется информация о местонахождении TSEG, и бит Lock, который запрещает это самое содержимое менять. Если авторы прошивки забыли установить (или восстановить при старте после S3, но об этом — в следующей части) — можно атаковать. Я не знаю, есть ли защита от DMA-атаки у чипсетов AMD, но постараюсь выяснить это в ближайшее время.

SMM cross-buffer attack

Специалисты компании Intel представили характеристику атаки ATR, нацеленную на обработчики SMI, которые принимают на вход указатель и размер буфера, записывая в него информацию. Злоумышленник может передать указатель и размер таким образом, что буфер пересечет границу между RAM и SMRAM. Поскольку обработчик SMI имеет доступ к SMRAM, он может перезаписать некоторые данные в начале SMRAM. При удачном стечении обстоятельств (например, после около 500 часов отладки) обработчик имеет возможность изменять служебные структуры диспетчера SMM или других обработчиков в соответствии с намерениями атакующего, что позволит ему запускать произвольный SMM-код. Эта атака является крайне сложной и целенаправленной, но осуществимой. Поэтому с начала 2015 года все обработчики SMI, которые обрабатывают указатели на буфер, обязаны проводить его валидацию перед использованием. На более старых системах атака будет возможно, однако вероятность того, что именно вас могут взломать через этот метод, остается довольно низкой.

Заключение

Итак, теперь мы более-менее разобрались с SMM. В следующем разделе обсудим атаки на S3 BootScript. Благодарим за внимание, желаем вам безопасных прошивок.

P.S.Не могу не поблагодарить тов. d_olex за его статьи об SMM и атаках на него — раз и два. Для интересующихся темой и умеющих читать по-английски — обе обязательны к прочтению.

Что такое runtime smm polling в BIOS