Доклады, выступления, видео и электронные публикации

Исследование перспективы использования технологии SMM для реализации СЗИ

Введение

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

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

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

В этой статье из вышеупомянутых режимов будет рассматриваться только SMM, и цель данной работы: оценить перспективы использования технологии SMM в разработке СЗИ.

1. Технология SMM

Для понимания функциональности SMM, прав доступа к ресурсам ЭВМ в данном режиме, а также потенциальных уязвимостей технологии, необходимо рассмотреть работу SMM и определить каким образом устроена память, в которой происходит функционирование SMM.

1.1. Описание SMM

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

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

Для переключения процессора в SMM используются System Management Interruptions (SMIs), которые генерируются компонентами материнской платы, либо могут генерироваться различными драйверами, приложениями (в том числе приложениями из ОС) или пользователями с административными правами в ОС [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 Control, отвечающий за возможность читать и писать в флеш-память BIOS’а. Если бит выставляется в SMM, то прерывание не будет сгенерировано, так как выполняемый код уже в SMM режиме; если бит выставляется в любом другом режиме, то прерывание будет сгенерировано, и соответственно будет вызван обработчик, который просто выставит бит обратно. Такой механизм реализован для защиты от перезаписи прошивки ЭВМ из любого режима кроме SMM.
  • APMC (APM Control) SMI – генерируется при записи в APM_CNT I/O порт (почти всегда это 0xB2 порт). Срабатывание такого прерывания может быть вызвано администратором ОС при помощи записи в ранее указанный порт. Количество обработчиков может быть 256, при этом при вызове можно указывать номер желаемого обработчика;
  • IOTR (IO Trap) SMI – генерируется при обращении к портам CPU I/O. Обработчик позволяют эмулировать Legacy устройства (например, клавиатуру), которые раньше использовали I/O порты;
  • xHCI (Extensible Host Controller Interface) SMI – генерируется USB-контроллером при различных событиях.
  • Periodic SMI – генерируется чипсетом по таймеру с периодичностью 8/16/32/64 (период настраивается с помощью битов PER_SMI_SEL).

1.2. SMM memory (SMRAM)

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

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

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

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

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

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

 1.jpg

Рисунок 1. Фазы загрузки системы с UEFI

1.4. Регистры SMM

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

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

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

2. Функции безопасности с использованием SMM

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

  1. Создание обработчика программных SMI. Вызывать такой обработчик можно с помощью ПО в ОС.
  2. Расширение обработчика системных SMI. Вызываться такой обработчик будет автоматически при каких-то событиях (зависит от типа SMI).

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

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

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

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

Для вызова обработчика программных SMI необходим корректно выставленный бит APMC_EN регистра SMI_EN [9-10 часть 12.8.3.7,11-12 часть 5.2.4]. Данный бит является R/W и может быть перезаписан в любой момент, если не реализована соответствующая функциональность блокировки регистра SMI_EN. Таким образом, не следует полагаться на гарантированное срабатывание прерывания при отсутствии функциональности блокировки.

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

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

2.2. Расширение обработчика системных SMI

Для вызова обработчика системных SMI необходим корректно выставленный бит включения прерываний для соответствующего типа прерываний регистра SMI_EN [9-10 часть 12.8.3.7,11-12 часть 5.2.4]. Большинство таких битов являются R/W и могут быть перезаписаны в любой момент, если не реализована соответствующая функциональность блокировки регистра SMI_EN. Таким образом, не следует полагаться на гарантированное срабатывание прерывания при отсутствии функциональности блокировки. Но для некоторых прерываний предусмотрена встроенная функциональность блокировки соответствующего бита, так, например, для всех современных ЭВМ 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) можно модифицировать, либо дополнить необходимыми функциями, чтобы выполнять определенный код многократно с определенным периодом.

3. Плюсы и минусы SMM для СЗИ

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

3.1. Плюсы SMM

3.1.1 Фундаментальные

  • Привилегированный доступ.

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

  • Дешевизна и высокая бесперебойность.

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

3.1.2 Технические

  • Ранняя стадия старта функционирования.

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

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

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

3.2. Минусы SMM

3.2.1. Фундаментальные

  • Доверие к вендору.

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

3.2.2. Технические

  • Платформозависимость.

Данная технология сильно платформозависима (и разработана только для x86 архитектуры) по своей реализации и написанию драйверов для SMM. Также не менее важным является факт, что вендоры (в том числе 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.

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

3.3. Возможные СЗИ

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

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

Заключение

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

Список литературы

  1. Domas C. The Memory Sinkhole // Официальный сайт конференции Black Hat [Электронный ресурс]. URL: https://www.blackhat.com/docs/us-15/materials/us-15-Domas-The-Memory-Sinkhole-Unleashing-An-x86-Desi... (дата обращения: 14.11.2020).
  2. Oster J. E. Getting Started with Intel® Active Management Technology (Intel® AMT) // Официальный сайт компании Intel [Электронный ресурс]. URL: https://software.intel.com/content/www/us/en/develop/articles/getting-started-with-intel-active-mana... (дата обращения: 18.11.2020).
  3. О безопасности UEFI, часть заключительная [Электронный ресурс]. URL: https://habr.com/ru/post/268423/ (дата обращения: 18.11.2020).
  4. Jiewen Y., Zimmer J. V. A Tour Beyond BIOS Launching STM to Monitor SMM in EDK II // Официальный сайт компании Intel [Электронный ресурс]. URL: https://software.intel.com/content/dam/develop/external/us/en/documents/a-tour-beyond-bios-launching... (дата обращения: 18.11.2020).
  5. О безопасности UEFI, часть вторая [Электронный ресурс]. URL: https://habr.com/ru/post/267197/ (дата обращения: 18.11.2020).
  6. Rauchberger J., Luh R., Schrittwieser S. LONGKIT – A Universal Framework for BIOS/UEFI Rootkits in System Management Mode // Conference: 3rd International Conference on Information Systems Security and Privacy. P. 346–353.
  7. Банк данных угроз безопасности информации. SMM // Официальный сайт ФСТЭК [Электронный ресурс]. URL: https://bdu.fstec.ru/search?q=SMM (дата обращения: 18.11.2020).
  8. SMM и SMRAM или 128 Кб потусторонней памяти: исследовательская работа №5 [Электронный ресурс]. URL: https://xakep.ru/2008/07/29/44663/ (дата обращения: 18.11.2020).
  9. Intel® 8 Series/C220 Series Chipset Family Platform Controller Hub (PCH) // Официальный сайт компании Intel [Электронный ресурс]. URL: https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/8-series-chipset-pch-datashe... (дата обращения: 18.11.2020).
  10. Intel® 9 Series Chipset Family Platform Controller Hub (PCH) // Официальный сайт компании Intel [Электронный ресурс]. URL: https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/9-series-chipset-pch-datashe... (дата обращения: 18.11.2020).
  11. Intel® 200 (Including X299) and Intel® Z370 Series Chipset Families Platform Controller Hub (PCH). Volume 2 // Официальный сайт компании Intel [Электронный ресурс]. URL: https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/200-series-chipset-pch-datas... (дата обращения: 18.11.2020).
  12. Intel® 300 Series and Intel® C240 Series Chipset Families Platform Controller Hub (PCH). Volume 2 // Официальный сайт компании Intel [Электронный ресурс]. URL: https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/300-series-chipset-pch-datas... (дата обращения: 18.11.2020).
  13. Intel to Remove Legacy BIOS Support from UEFI by 2020 [Электронный ресурс]. URL: https://www.anandtech.com/show/12068/intel-to-remove-bios-support-from-uefi-by-2020 (дата обращения: 09.05.2021).
  14. Building reliable SMM backdoor for UEFI based platforms [Электронный ресурс]. URL: http://blog.cr4.sh/2015/07/building-reliable-smm-backdoor-for-uefi.html (дата обращения: 18.11.2020).
  15. 8th and 9th Generation Intel® Core™ Processor Families and Intel® Xeon E Processor Family // Официальный сайт компании Intel [Электронный ресурс]. URL: https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/8th-gen-core-family-datashee... (дата обращения: 18.11.2020).
  16. Intel® Platform Innovation Framework for EFI System Management Mode Core Interface Specification (SMM CIS) // Официальный сайт компании Intel [Электронный ресурс]. URL: https://www.intel.ru/content/dam/doc/reference-guide/efi-smm-cis-v091.pdf (дата обращения: 18.11.2020).
  17. Attacking SMM Memory via Intel® CPU Cache Poisoning [Электронный ресурс]. URL: https://invisiblethingslab.com/resources/misc09/smm_cache_fun.pdf (дата обращения: 18.11.2020).
  18. Attacking UEFI Boot Script [Электронный ресурс]. URL: https://bromiumlabs.files.wordpress.com/2015/01/venamis_whitepaper.pdf (дата обращения: 18.11.2020).
  19. О безопасности UEFI, части нулевая и первая [Электронный ресурс]. URL: https://habr.com/ru/post/266935/ (дата обращения: 18.11.2020).
  20. eXtensible Host Controller Interface for Universal Serial Bus (xHCI) // Официальный сайт компании Intel [Электронный ресурс]. URL: https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/extensible-hos... (дата обращения: 18.11.2020).
  21. Устройство файла UEFI BIOS, часть полуторная: UEFI Platform Initialization [Электронный ресурс]. URL: https://habr.com/ru/post/185764/ (дата обращения: 18.11.2020).
  22. Елькин В. М. Контроль недоверенного процессора // Комплексная защита информации: материалы XXIII научно-практической конференции, Суздаль, 22–24 мая 2018 г. М.: Медиа Групп «Авангард», 2018. С. 209–211.
  23. System Management Mode Hacks [Электронный ресурс]. URL: http://phrack.org/issues/65/7.html (дата обращения: 18.11.2020).
  24. Использование Intel Processor Trace для трассировки кода System Management Mode [Электронный ресурс]. URL: https://habr.com/ru/company/dsec/blog/481692/ (дата обращения: 18.11.2020).
  25. Advanced x86: Introduction to BIOS & SMM. SMI Suppression [Электронный ресурс]. URL: https://opensecuritytraining.info/IntroBIOS.html (дата обращения: 18.11.2020).
  26. Ziarnik G. P., Durham M. R., Piwonka M. A. Pattern № US9483426B2, United States (US). Locking a system management interrupt (SMI) enable register of a chipset. Appl. № US14/364,706; PCT Filed 31.01.2012; PCT № PCT/US2012/023225; PCT Date 12.06.2014; Publication Date 01.11.2016. Assignee: Hewlett-Packard Development Company, L.P.

Автор: Пахомов М. В.

Дата публикации: 19.08.2021

Библиографическая ссылка: Пахомов М. В. Исследование перспективы использования технологии SMM для реализации СЗИ // Комплексная защита информации: материалы XXVI научно-практической конференции. Минск. 25–27 мая 2021 г. Минск: Издатель Владимир Сивчиков, 2021. С. 294–300.


Scientia potestas est
Кнопка связи