Архитектура персональных платформ подразумевает наличие целого ряда объектов и событий, которые BIOS (или UEFI firmware) стремится скрыть от операционной системы. И далеко не всегда дело в секретности или обеспечении информационной безопасности. Часто это связано с оптимизацией разделения функций между программными модулями.
Казалось бы, с появлением интерфейса ACPI, приватное взаимодействие платформы и firmware должно было прекратиться, ведь в основе этого нововведения лежит декларирование аппаратно-зависимых регистровых полей с помощью таблиц и передача операционной системе функций по управлению ими. Но при внимательном чтении спецификации ACPI станет очевидно, что две модели – приватная и открытая, мирно уживаются в рамках данного стандарта.
Вспомним, как выполняется перевод платформы в режим ACPI. Операционная система должна записать значение ACPI_ENABLE в порт SMI_CMD. Данные для записи и адрес регистра декларированы в таблице FADT (Fixed ACPI Description Table). Что же происходит после передачи этой команды? Контроллер ACPI не отрабатывает ее аппаратно. Вместо этого генерируется прерывание SMI (System Management Interrupt), при обработке которого процессор выполняет Platform-Specific процедуру. Эта процедура и обеспечивает включение ACPI mode. Ее выполнение происходит в изолированном адресном пространстве с использованием приватной памяти (System Management RAM) и незаметно для ОС.
Доступ к SMRAM или входим в открытую дверь
Раньше, получить доступ к SMRAM было очень просто. Вспомним регистр System Management RAM Control, а в нем бит D_OPEN (бит 6), установив который в «1» можно включать SMRAM в адресное пространство, независимо от текущего состояния процессора (SMM или не-SMM).
Рис 1. Описание регистра SMRAM Control на примере чипста Intel 915
Предусмотренный бит блокировки D_LCK (бит 4) теоретически мог защищать этот регистр от записи, но большинство реализаций BIOS не включали такую защиту, поэтому любое программное обеспечение могло беспрепятственно выполнять чтение и запись SMRAM.
Рис 2. Пример доступа к SMRAM на плате ASUS P5GPL-X
Отравление кэш-памяти или входим в закрытую дверь
Практиковались и более сложные методы доступа к SMRAM, позволяющие обойти блокировку, включаемую по D_LCK=1. Они основывались на технологии отравления кэш-памяти, а именно на создании кэшированного образа памяти SMRAM, отличного от ее истинного содержимого. Таким методом, хакер подключал собственную процедуру обработки прерывания SMI. (Rafal Wojtczuk, Joanna Rutkowska Attacking SMM Memory via Intel CPU Cache Poisoning).
Intel закручивает гайки
В документации на новые процессоры Intel (Socket 1155, 2011) регистр SMRAM Control Register не описан, вместо него используются регистры SMRR (System Management Range Registers), расположенные в пространстве Model-Specific регистров процессора. Согласно документации, перезаписать их может только программа, работающая в System Management Mode.
Рис 3. Описание Model-Specific регистров процессора, управляющих доступом к SMRAM. Слева указан адрес регистра в шестнадцатеричной и десятичной системах счисления. Центральные колонки описывают назначение битов регистров. Правая колонка описывает метод декларирования поддержки указанных регистров.
Использование MSR вместо конфигурационных регистров северного моста системной логики связано с интеграцией функций картирования SMRAM в ядро процессора. И это не случайно – разделение полномочий по управлению SMRAM между системной логикой и процессором, имевшее место в старой архитектуре, и возможность взаимно несогласованной установки состояний процессора и контроллера памяти было одним из факторов уязвимости, даже в том случае, когда контроллер памяти интегрирован в процессор.
Начинаем эксперименты
Наши объекты исследования – плата ASUS Z87-K на основе системной логики Intel Z87 для процессоров Socket 1150. Процессор – Intel(R) Xeon(R) CPU E3-1270 v3 @ 3.50GHz. Используя программное обеспечение, написанное в нашей тестовой лаборатории, мы провели ряд простых экспериментов.
Чтение SMRR-регистров
Рис 4. Подготавливаем входной параметр – адрес регистра для чтения MSR 000001F2h
Рис 5. Результат – в 64-битном регистре число 00000000DF000006h
MSR#000001F2h, IA32_SMRR_PHYSBASE = 00000000.DF000006h
Базовый адрес SMRAM = DF000000h, атрибут MTRR равен 06h, что означает кэшируемая память, тип кэширования Writeback (WB).
Рис 6. Подготавливаем входной параметр – адрес регистра для чтения MSR 000001F3h
Рис 7. Результат – в 64-битном регистре число 00000000FF000800h
MSR#000001F3h, IA32_SMRR_PHYSMASK = 00000000.FF000800h
Размер диапазона = 16 мегабайт, бит 11 установлен в “1”, то есть диапазон включен.
Запись SMRR-регистров
Наша цель — отменить специальный статус SMRAM диапазона DF000000h-DFFFFFFFh, и сделать память SMRAM доступной в адресном пространстве. Для этого попробуем обнулить бит 11 регистра IA32_SMRR_PHYSMASK.
Рис 8. Подготавливаем входные параметры – адрес регистра для записи MSR 000001F3h и данные записи 00000000FF000000h
Рис 9. Результат – ошибка записи в регистр 000001F3h
Попытка перезаписи данного регистра вызывает General Protection Fault. Заявление Intel соответствует действительности.
Рис 10. Просматриваем дамп региона SMRAM и убеждаемся, что оперативная память недоступна
Просматривая дамп памяти, мы видим, что SMRAM не появилась в адресном пространстве, все байты FFh.
Резюме
Более десяти лет ситуация с аппаратной защитой SMRAM напоминала анекдот про разведчика, который, когда враги перекрыли все выходы, вышел через вход. Но видимо, шутки закончились. На сегодня, нашей тестовой лаборатории не удалось взломать защиту SMRAM, разработанную Intel. Хотя, работы в этом направлении ведутся, становится доступной новая документация, поэтому не будем торопиться делать выводы…