Работая с виртуальными расширениями Intel VMX и ARM, я заметил отсутствие функциональности, которая была бы очень полезна при реализации гипервизоров.
В рамках работы гипервизора часто бывает необходимо перехватить гостевое поведение, но только для целей отслеживания (то есть инструкция может нормально выполняться гостем, но нам нужно сначала что-то сделать - например, ведение журнала).
Чтобы быть более точным, возьмем следующий пример: на гипервизоре Intel, который я реализовал некоторое время назад (с Windows 7 в качестве гостя), мне нужно было регистрировать каждый раз, когда структура ядра Windows изменялась < / сильный>. Для этого я узнал физический адрес структуры ядра и удалил гостевое разрешение на запись для соответствующей страницы EPT. Таким образом, всякий раз, когда гость пытался записать (изменить) структуру, происходило нарушение EPT, что приводило к ловушке гипервизора.
При каждом таком нарушении EPT я бы применил одну из следующих стратегий:
Стратегия 1:
- Активируйте флаг-ловушку-монитора.
- Временно предоставить гостю разрешение на запись региона (модификация EPT)
- VMRESUME => гость выполнит инструкцию и VMEXIT сразу после этого, так как MTF активирован.
- при следующем VMEXIT я бы деактивировал MTF и повторно запретил гостю писать структуру (= модификация EPT + аннулирование) и VMRESUME еще раз
Стратегия 2:
- Эмулируйте инструкцию, которая хочет написать структуру. Это подразумевало написание эмулятора (> дизассемблера).
Как видите, обе эти стратегии немного сложны даже без поддержки многопроцессорной обработки. Что касается стратегии 1, если бы Windows была виртуализирована на нескольких процессорах, нам также пришлось бы отправлять IPI на другие ядра, чтобы приостановить их, пока мы обрабатываем нарушение EPT. Кроме того, это конкретный пример, подразумевающий конкретную стратегию. Другим примером трассировки может быть, например, запись в журнал и / или изменение параметров функции ядра при каждом ее вызове. В этом случае нам может потребоваться другая стратегия.
Думаю, пора перейти к делу. Моя дилемма заключается в следующем. Простой способ избежать сложных программных стратегий всякий раз, когда нам нужно отслеживать поведение гостя, был бы для технологий виртуализации, предлагающих возможность динамически выбирать, возникают ли ловушки команд до ИЛИ ПОСЛЕ их выполнения. < / сильный>
Еще до написания своего первого гипервизора (на Intel) я был почти уверен, что VMX предложит мне такую функциональность. Мое мнение подсказывало мне, что это будет очевидная функция, предлагаемая любой технологией виртуализации на любой платформе, поэтому я был удивлен (и немного разочарован), когда обнаружил, что на самом деле это не так: не на Intel, не на ARM (как Я недавно узнал) и, скорее всего, не на других платформах. Таким образом, мой вопрос на самом деле: ПОЧЕМУ? Почему "дизайнеры" аппаратной виртуализации не реализуют такую функциональность? Я уверен, что об этом думали ранее, поэтому мне кажется, что единственным возможным ответом на этот вопрос является аппаратно такое реализация функциональности была бы очень сложной или даже невозможной, хотя я не понимаю, почему это так. Так ли это?
Заранее спасибо за ответы :)
ИЗМЕНИТЬ
Хотя я не прояснил это, я также хотел бы указать на тот факт, что есть десятки случаев, когда программист хочет уловить какое-то гостевое поведение С НАМЕРЕНИЕМ ИЗМЕНИТЬ ЭТО ЭФФЕКТ (таким образом, подразумевая больше чем трассировка), но в которой такая функциональность все равно будет очень полезна.
Возьмем, к примеру, следующий пример. Предположим, я хочу, чтобы мой гипервизор контролировал связь гостя с устройством с отображением памяти (или даже полностью имитировал его - очень распространенное требование для современных гипервизоров). В большинстве случаев мы будем сообщать гостю, что устройство отображено в памяти по адресу A, а перехватчик записывает / читает на / с этого адреса. . Когда захваченная инструкция пытается прочесть область по адресу A, в настоящее время мы вынуждены ее дизассемблировать и эмулировать. Если бы гипервизор предлагал нам возможность разрешить выполнение инструкции с временным разрешением чтения / записи и прерыванием сразу после нее, эмуляция инструкции стала бы ненужной, поскольку мы могли бы позволить ей выполнить и «добавить» желаемый эффект впоследствии.
