Гипервизор: наблюдатель, граница защиты и возможный противник

Три роли одной технологии

Гипервизор может изолировать недоверенные нагрузки, предоставлять внешнему наблюдателю доступ к состоянию гостя или сам оказаться частью модели противника. Эти роли несовместимо сводить в один знак «доверено». Нужно назвать, кто контролирует monitor, как он запускается и какие объекты защищает.

Историческая работа SubVirt исследовала virtual-machine based rootkit: monitor размещался под существующей ОС, которая продолжала работать как гость. Это модель изменения уровня контроля, а не доказательство того, что любую современную машину можно незаметно «перевести под гипервизор» без предусловий. S17

Практическая ошибка в обсуждении таких техник — начинать с возможностей monitor и забывать о праве его установить. Контроль загрузки или хостовой инфраструктуры уже представляет сильную исходную позицию. Его нельзя бесплатно включать в модель непривилегированного противника внутри гостя.

Почему Ring −1 — только мнемоника

Удобная метафора «ниже ring 0» не описывает полный набор полномочий. Виртуализация включает режимы процессора, управление отображением памяти, обработку событий и интерфейсы гостя. Для безопасности важно не числовое положение на картинке, а фактическая возможность изменять конкретный защищаемый объект.

Например, наблюдатель может видеть гостевую память, но не понимать, как из её байтов восстановить корректный список процессов данной версии ОС. Это семантический разрыв. Если часть интерпретации берётся из самого гостя, источник может быть недостоверным. Внешнее расположение датчика повышает независимость, но не делает анализ автоматически правильным.

VBS: обычное ядро перестаёт быть единственным арбитром

Microsoft описывает VBS как использование аппаратной виртуализации для изолированной среды, где могут размещаться защищённые функции. HVCI переносит решение о допустимости kernel-кода в такую среду; VBS также предъявляет требования к памяти firmware runtime. Это отдельная архитектурная граница, а не другое название обычного антивирусного драйвера. S14

В Virtual Secure Mode используются Virtual Trust Levels. Механизмы защиты памяти и переходов определяют взаимодействие уровней. Поэтому полномочия кода в обычном ядре и полномочия изолированного компонента нельзя считать одинаковыми. Наличие административных прав в ОС само по себе не описывает всю модель VTL. S16

Это особенно важно для чтения Abyss и Insomnia. Изменение функции в ntoskrnl или её ответа не является доказательством изменения решения отдельного enforcement-компонента. И наоборот, включённая настройка в интерфейсе ещё не доказывает, что гипервизор и требуемая защита реально запустились в текущем сеансе. E06 E40

Измерять состояние, а не надпись в настройках

Для Blue полезно фиксировать три группы фактов: запрошенную конфигурацию, реально запущенные компоненты и наблюдаемое применение ограничений. Если политика требует защиты, но компонент не стартовал, это иной результат, чем успешный старт с неожиданным поведением.

В исследовательском протоколе также нужны точная версия ОС, firmware и состояние виртуализации. Повторение опыта на машине с тем же маркетинговым названием Windows недостаточно. Отладочные режимы, совместимость драйверов и конфигурация платформы могут менять условия.

Red: утверждение об обходе должно называть конкретную границу: обычное ядро, защищённую память, VTL-переход или сам hypervisor. «Код исполнился в kernel mode» не доказывает все эти результаты одновременно.

Blue: независимый источник должен быть независим именно от атакуемого слоя. Два отчёта из одного скомпрометированного ядра не становятся надёжнее от разных названий утилит.

Виртуальная машина — удобный стенд, но другой противник

bootlicker описывает сценарий с виртуальной прошивкой VMware. В его просмотренных стадиях видны UEFI-переходы, ACPI.SYS, thread callback и APC, а не реализация собственного monitor. Это bootkit внутри определённого окружения, а не автоматически hypervisor rootkit. E33 E36 E38

Владелец хоста может менять виртуальные диски и конфигурацию VM; пользователь гостя обычно находится в другой позиции. Если стенд начинается с подготовленного firmware image, результат должен сохранять это предусловие. Иначе демонстрация поздней стадии превращается в преувеличенное заявление о первоначальном проникновении.

Защитный snapshot VM также требует осторожной интерпретации. Он полезен как сохранённое состояние, но полнота снимка зависит от того, какие компоненты инфраструктуры в него входят. Диск гостя, NVRAM, конфигурация, firmware и состояние памяти не обязательно восстанавливаются одной операцией.

Когда гипервизор исключают из доверенной базы

TDX и SEV-SNP рассматривают более сильную модель: VMM может быть недоверенным по отношению к защищённому гостю. Intel описывает защиту trust domain от внешнего программного обеспечения; AMD добавляет механизмы целостности памяти к своей архитектуре защищённых VM. Но конкретные гарантии и исключения необходимо брать из модели соответствующей версии. S18 S20

При такой архитектуре наблюдаемость тоже меняется. Внешний монитор, которому раньше был доступен весь plaintext гостя, может потерять этот доступ. Для Blue возникает инженерный компромисс: как получить достаточные свидетельства о поведении, сохраняя заявленную конфиденциальность нагрузки. Решение часто требует кооперации внутри защищённого гостя и тщательно ограниченных экспортируемых событий.

Нельзя при этом считать шифрование памяти универсальной защитой от всех побочных каналов. В AMD-SB-3021 обсуждаются конкретные ciphertext side-channel исследования для SEV-SNP. Это пример необходимости учитывать опубликованные исключения и состояние исправлений, а не объявлять любую платформу полностью защищённой одним названием технологии. S21

Интерфейс гостя остаётся поверхностью анализа

Confidential VM продолжает получать данные извне: от виртуальных устройств, storage и сетевых служб. Intel отдельно подчёркивает необходимость защиты guest code при недоверенном VMM. Проверка параметров внешнего интерфейса остаётся обязанностью соответствующего компонента. S19

Аналитически это удобно описать как две независимые гарантии. Первая: внешний субъект не может произвольно прочитать или изменить приватные страницы. Вторая: программа не принимает ложные внешние данные за авторизованное решение. Первая не доказывает вторую. Тот же принцип действует для TEE и TPM, но у VM поверхность виртуальных устройств особенно заметна.

Сравнительная карта доверия

Карта предназначена для постановки исследования. Она не ранжирует технологии одним баллом: у них разные противники и разные обещания. Выбор защиты следует из того, какой субъект исключается из доверия и какие свидетельства остаются доступны после этого выбора.

Что связывает все четыре сценария

Нужна история происхождения самого арбитра. Кто запустил hypervisor, что удостоверяет его состояние, кто может заменить его после обновления и как проверяется результат? Без этих ответов «вынести контроль ниже» лишь переносит неявное доверие в другой компонент. С ними виртуализация становится конкретным и проверяемым элементом архитектуры защиты.