Lock legacy resources в биосе что это

Все статьи

Как включить или отключить видеокарту в BIOS-е?
Причины по которым не запускается БИОС
Что делать, если при включении ноутбука или ПК открывается BIOS?
1(один) длинный 2 (два) коротких сигнала BIOSа — что означают?

Новые статьи

Как обновить BIOS материнской платы вашего ПК
Значение ошибки: Chassis intruded! Fatal Error… System Halted
Как включить в БИОСе клавиатуру?
Что делать, если при включении ноутбука или ПК открывается BIOS?

Быстрый доступ к теме

Копирование и цитирование материалов сайта разрешено только при условии размещения четко видимой, прямой, открытой для индексации ссылки на источник.

Присоединяйтесь в
социальных сетях

Опция BIOS Boot List Option

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ключевые слова: System Management Mode, System Management Interruption, средство защиты информации, компьютерная безопасность, регистр SMI_EN, кольца защиты, режим исполнения кода, архитектура x86.

Введение (Introduction)

Архитектура 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». А с другой стороны, с помощью таких технологий можно расширить функциональность существующих СЗИ, либо попытаться реализовать полнофункциональное СЗИ на основе таких технологий.

Используемые методы исследования (Research methods used)

В этой статье из ранее упомянутых режимов будет рассматриваться только 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 используются 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.
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 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].
Результаты (Results)

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

SMM предназначен для обработки прерываний, которые сгенерированы либо системой (системные SMI), либо прошивкой / драйверами / приложениями, обладающими доступом с правами администратора в ОС (программные SMI) при помощи записи в APM_CNT I/O порт. Таким образом, возможно создание лишь двух типов функции (обработчиков SMI) на основе SMM:
1. Создание обработчика программных SMI. Вызывать такой обработчик можно с помощью ПО в ОС.
2. Расширение обработчика системных 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, и до фазы Boot Device Selection (BDS) (см. рисунок 1) [21]. И с одной стороны, наличие двух фаз перед запуском SMM является, определенно, минусом, но с другой стороны это позволяет коду SMM работать с памятью (которая инициализируется в PEI) и работать с устройствами системы. При этом полноценно функционировать SMM начинает после блокирования SMRAM, до окончания фазы DXE, то есть в конце фазы 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, создаваемые Platform Controller Hub’ом (PCH). Но этот способ является эффективным только в случае блокировки битов, отвечающих за срабатывание прерываний, поэтому необходимо также реализовать дополнительную функциональность, которая будет отвечать за неизменность этих битов. Документация Intel не декларирует возможностей по блокировке таких битов [9–10 часть 12.8.3.7, 11–12 часть 5.2.4], а примеры атак на ЭВМ [25] с изменением таких битов еще раз подтверждают наличие векторов атак в случае реализации СЗИ через SMI. Однако существует патент по реализации блокировки регистра SMI_EN (см. [26]), но он скорее описывает архитектурную возможность по аппаратному улучшению чипсета (в частности, южного моста чипсета), нежели возможность по реализации блокировки регистра с помощью программных средств. Таким образом, предлагаемый вариант блокировки в патенте может быть целесообразен для вендоров компьютерной техники, поскольку они могут вносить существенные изменения в структуру элементов ЭВМ, но не является целесообразным для разработчиков СЗИ.

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

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

Литература (References)
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-Design-Flaw-Allowing-Universal-Privilege-Escalation-wp.pdf (дата обращения: 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-management-technology-amt.html (дата обращения: 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-stm-to-monitor-smm-in-efi-developer-kit-ii-819978.pdf (дата обращения: 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-datasheet.pdf (дата обращения: 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-datasheet.pdf (дата обращения: 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-datasheet-vol-2.pdf (дата обращения: 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-datasheet-vol-2.pdf (дата обращения: 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-datasheet-vol-2.pdf (дата обращения: 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-host-controler-interface-usb-xhci.pdf (дата обращения: 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;
Автор: Пахомов М. В.

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

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

Lock legacy resources в биосе что это

Switch Between Legacy BIOS and UEFI BIOS Modes

The BIOS firmware supports both Legacy BIOS (the default) and UEFI. Because some OSs support both Legacy BIOS and UEFI BIOS and some only support Legacy BIOS, you have these options:
- If the OS being installed supports Legacy BIOS only, ensure that BIOS is set to Legacy mode before you install the OS.
- If the OS being installed supports both Legacy BIOS and UEFI BIOS, you can set the BIOS to either Legacy mode or UEFI mode. Set the BIOS mode before you install the OS.
Note — The Windows Server 2008 OSs support both Legacy and UEFI BIOS modes. You can choose which mode to use for the OS installation.
1. Reset or power on the server. For example:
  - From the local server – Press the Power button (approximately 1 second) on the front panel of the server to power off the server, then press the Power button again to power on the server.
  - From the Oracle ILOM web interface – Click Host Management > Power Control and select Reset from the Select Action list box.
  - From the Oracle ILOM CLI on the server SP – Type.->reset /SystemAre you sure you want to reset /System (y/n)?yPerforming hard reset on /System
The BIOS screen appears.
When prompted in the BIOS screen, press F2 to access the BIOS Setup Utility. After a few moments, the BIOS Setup Utility appears.
In the BIOS Setup Utility, select Boot from the top menu bar. The Boot screen appears.
Select the UEFI/BIOS Boot Mode field and use the +/- keys to change the setting to UEFI BIOS.
Save changes and exit BIOS by pressing the F10 key.