Виртуальная Матрешка

Аппаратура виртуализации ЦП разрабатывалась в рамках концепции монопольного использования. Это означает, что только единственный Гипервизор может использовать ее, запустить Гипервизор в задаче другого Гипервизора невозможно.

Это в теории, но практика требует во многих случаях все-таки наличия нескольких гипервизоров одновременно и это абсолютно неисследованная область, по крайней мере, в публичных источниках. Гипервизор, могущий запустить в своих задачах другие гипервизоры, редкий зверь, упоминания о них встречаются, но таких работающих программ нет. Единственное внятное упоминание о такой «матрешке» из гипервизоров, это некий хитрый гипервизор Рутковской. Его реальная работоспособность в связке с коммерческими системами виртуализации мне неизвестна.

Если речь идет о двух гипервизорах, то естественно есть первичный (корневой), и он «по праву первой ночи» забирает аппаратуру виртуализации в полное свое распоряжение. Для следующих (вторичных) гипервизоров он обязан эмулировать эту аппаратуру, таким образом, чтобы они не заметили различий.

Тут есть одна хитрость, поскольку для работы гипервизоров применяется два метода виртуализации и соответственно в каждом задействована разная программно-аппаратная среда, то запустить два гипервизора использующих разную аппаратуру нет никаких проблем. К примеру, «Красная пилюля» отлично работает в качестве корневого гипервизора для продуктов VMware, если на них принудительно отключить поддержку аппаратной виртуализации.

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

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

Но как говорил «Великий кормчий»: «Если что-либо можно измыслить, то это возможно и реализовать». Так что, следуя заветам Мао-Дзе-Дуна, гипердрайвер «Красная пилюля» был модифицирован до уровня корневого гипервизора. Он оснастился программными обработчиками, эмулирующими для вторичного гипервизора работу с аппаратурой виртуализации ЦП. В таком виде он поддерживает три типа виртуализации:

Виртуализацию основной ОС и всех ее приложений, не использующих аппаратуру виртуализации ЦП. Это основной тип использования аппаратуры виртуализации, он был в «Красной пилюле» изначально. Основная ОС и ее приложения выполняются в режиме задачи корневого гипервизора. Данный режим подробно описан в предыдущих статьях о «Красной пилюле».

Виртуализацию хоста вторичного гипервизора. В этом специальном режиме задачи для программ хоста вторичного гипервизора создается аппаратное окружение полностью соответствующее работе на реальной аппаратуре виртуализации. Сделать это не просто, поскольку аппаратура ЦП в режиме хоста работает со значимыми отличиями от обычных режимов работы процессора. К примеру, хост гипервизора после выхода из задачи не реагирует на внешние прерывания, он их запоминает и выполняет обработку прерываний после завершения программ хоста. Если выполнять программы хоста вторичного гипервизора в режиме задачи, то приходится такую блокировку прерываний осуществлять в обработчиках событий первичного гипервизора. Есть еще несколько тонких моментов, которые нужно учитывать, эмулируя аппаратное окружение для программ хоста вторичного гипервизора.

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

И вот посмотрите на результат (кликабельно):

В системе на GPU A4 AMD, у которой два ядра, запущен гипердрайвер, в VMware Workstation запущена гостевая ОС Windows XP, хост VMware работает с принудительно включенной аппаратной виртуализацией.

Затем в гостевой ОС Windows XP также запускается Гиперагент и на нем можно редактировать весь объем Оперативной памяти вычислительной установки используя встроенный интерфейс между приложением и корневым гипервизором.

Этот скриншот демонстрирует возможность контроля за событиями в работающем гипервизоре VMware и любом другом подобном ему из прикладной задачи запущенной в гостевой ОС.

По этой ссылке можно скачать демонстрационную версию «Красной пилюли» и самим убедиться в работоспособности гипердрайвера, а также можно оценить уровень быстродействия такой «матрешечной» системы из двух вложенных друг в друга гипервизоров. Как запустить «Красную пилюлю» подробно описано в предыдущих статьях об этом гипердрайвере на VM Guru.

Кстати о быстродействии: я, сколько не тестировал изменения в быстродействии в «матрешке» и без нее, никаких видимых замедлений работы не заметил.

Данная версия «Красной пилюли» работает на процессорах AMD, в ней введена поддержка всех новейших архитектур CPU. Старые версии гипердрайвера на них не работают, поскольку фирма исключила из архитектуры несколько важных аппаратных режимов использовавшихся в старых версиях «Красной пилюли».

Это странно, обычно режимы, прописанные в томе 2 (AMD64 Architecture Programmer’s Manual Volume 2 System Programming) официальной документации AMD и фиксирующие некие возможности, поддерживаются в последующих решениях. Здесь же фирма изменила своему правилу и многие «хитрые» системы сразу потеряли работоспособность на новых CPU...

Часто задают вопрос, а почему все пишут собственные гипервизоры для систем на базе процессоров AMD? Ответ прост: их аппаратуру виртуализации гораздо проще программировать нежели аппаратуру Intel, да и возможностей виртуальных машин у AMD гораздо больше.
Ссылки на отсутствие документации у системы виртуализации Intel несостоятельны, она хорошо документирована для основных режимов работы гипервизора. Другое дело, что система виртуализации Intel гораздо сложнее устроена и объем программирования ее значительно больше, а быстродействие гораздо ниже.

Если же говорить о недокументированных возможностях, то они есть как в аппаратуре AMD, так и в аппаратуре Intel, здесь не надо искать какого-то тайного смысла. Разработчики изначально проектировали архитектуру ориентируясь на максимум возможностей, но не все эти возможности отлажены и востребованы на текущий момент. Поэтому у каждой из этих фирм существует собственная политика активации новых возможностей аппаратуры. В большей степени она ориентируется на маркетинг, нежели на объективные проблемы отладки новых аппаратных блоков.

Актуален вопрос использования этих недокументированных возможностей. В некоторых случаях их реально можно задействовать, они просто не описаны в документации, но их использование не заблокировано аппаратно, обычно так поступает AMD.

Фирма Intel действует по другой схеме, она имеет легальный механизм аппаратной блокировки таких не описанных в документации возможностей. Для этого используются специальные MSR-маски активации аппаратуры виртуализации. От ревизии к ревизии системы виртуализации в документации описываются новые аппаратные возможности и биты активации для них снимаются с блокировки.

Если же сфокусироваться на теме вложенных гипервизоров, то методом эмуляции примененным в «Красной пилюле», матрешку из гипервизоров на аппаратуре Intel не создать. Объем эмуляции будет очень велик и существенно затруднит как процесс создания корневого гипервизора, так и его эксплуатационные качества в части быстродействия.

В Интернете есть упоминания о недокументированном режиме аппаратуры виртуализации Intel для работы с несколькими управляющими блоками (VMCS) аппаратуры виртуализации. Этот режим одновременного присутствия нескольких активных VMCS-блоков предназначен для создания корневых гипервизоров. Кроме этого в документации Intel описан один частный случай использования двух одновременно активных управляющих VMCS-блоков для случая виртуализации режима системного менеджмента (дуальный монитор). Более подробно об этом можно почитать здесь и здесь.

«Красная пилюля» в демонстрационном варианте использует интерфейс обмена данными /командами с приложениями (в данном случае с Гиперагентом) гостевой системы. Пока реализован только интерфейс редактирования физической памяти и дампирования участков физической памяти в бинарный файл.

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

Поступает много предложений развернуть данную демонстрационную программу в полноценную систему отладки/реверса кода. Видимо настало время «Красной пилюле» с демонстрационного подиума спуститься на рабочие места системных программистов.

Если говорить о применении такой «матрешки», то пока это актуально только для исследований внутренностей официальных систем виртуализации типа VMware ESX/ESXi. До сего момента приходилось только доверять заверениям разработчиков о неуязвимости их продуктов. Сейчас появилась возможность проверить эти утверждения на практике.

Но актуальность темы отладки/реверса/контроля возрастет с приходом UEFI и TPM модулей. Для вычислительных систем, использующих эти функции, средство отладки на корневом гипервизоре прошитом в флеш-память материнской платы станет пожалуй единственным вариантом. Так что пора похоже выполнить обещание и показать в ближайшем будущем работающий из БИОС гипервизор…..