Технологии виртуализации вчера, сегодня, завтра

       

Виртуализация завтра: AMD Secure Virtual Machine «Pacifica»


С AMD ситуация еще интереснее: в 2005 году эта компания сильно удивила мировую общественность, выпустив свою технологию виртуализации, абсолютно несовместимую с технологией, предложенной Intel. Вот так вот! Раньше процессоры Intel и AMD работали на одних и тех же материнских платах, затем стали работать на разных, затем потребовали разных типов оперативной памяти, а теперь вот - и разного программного обеспечения. Можете даже не пытаться установить виртуализационный софт «для Intel» на процессоры AMD - там нет ничего даже близко похожего.

Правда, с другой стороны, решение AMD совершеннее и современнее. А несовместимость подходов проявляется лишь в относительно небольшой части кода модуля VMM (любые операционные системы и обычное ПО, естественно, будут по-прежнему одинаково хорошо работать на процессорах и Intel, и AMD). Но - тем не менее.

Давайте на минутку вернёмся к Intel и посмотрим на то, какой подход был положен в основу идеологии VT-x. У нас есть некая «базовая» операционная система, в которой пользователь запускает приложение типа VMWare Workstation или Microsoft VirtualPC, а уж это приложение при желании может подкрутить что-то в процессоре, включить режим виртуализации, создать специальный модуль по управлению виртуальными машинами, создать виртуальные машины, и запустить на них какие-то «гостевые» операционные системы со своими приложениями. При этом «режим VMX» не является чем-то сильно особенным и запущенный в этом режиме код никакими особенными привилегиями не обладает. Фактически это просто обычное приложение (или драйвер), запущенное на процессоре и обладающее лишней парой флажков, записанных глубоко в служебных регистрах процессора.

У AMD подход принципиально другой, более простой и наглядный. Начинается он тоже с менеджера виртуальных машин VMM, да только вот менеджер тот на интеловский аналог абсолютно не походит. У Intel VMM - это некое очень хитрое приложение обычной операционной системы, которое может быть запущено даже из кольца обычного приоритета.
У AMD - это системный код, работающий на более низком уровне, чем сама операционная система, и запускаемый исключительно из системного Ring 0. Модуль VMM в Pacifica фактически выполняет роль ядра некоторой «базовой» операционной системы, и только этот код в Pacifica работает с собственно физическим оборудованием. Все «обычные» операционные системы в подходе AMD - гостевые и работающие с виртуальными машинами, которые для них создаёт VMM. Оцените всю прелесть решения: у Intel модуль VMM в поте лица занимается «фальсификацией» кучи разных событий, выбиваясь из сил, лишь бы сделать вид, что гостевая ОС работает с реальным «железом». У AMD модуль VMM попросту один-единственный раз создаёт виртуальную машину, переключается в «гостевой режим» - и запущенный в этой гостевой машине код работает со свежесозданной виртуальной машиной в практически полностью автономном режиме, без какого-либо вмешательства VMM.



Схема 9. Виртуализация с AMD Pacifica

Как такое возможно? Да очень просто: AMD действительно виртуализирует физические ресурсы, и, прежде всего, - оперативную память. «Физическая» виртуальная память, видимая гостевыми ОС в Pacifica - это просто виртуальная память второго уровня. Таблицы трансляции для которого контролирует, естественно, VMM. То есть если какая-нибудь программа, запущенная в этой гостевой ОС, скажем, обращается к памяти по адресу такому-то, то процессор, используя таблицы трансляции, контролируемые гостевой ОС, вначале преобразует этот адрес в «физический» адрес, который уже аппаратно, без участия VMM преобразуется в настоящий физический адрес. Или, как уже говорилось, не преобразуется, а вызывает подкачку из своп-файла, загрузку данных по сети, и прочее - возможности виртуальной памяти в умелых руках безграничны. VMM, кстати говоря, устроен гораздо проще операционной системы, полностью независим от неё, и потому потенциально возможно реализовывать на его основе всю ту «редкую» функциональность, которую обычно не рискуют (или не хотят) вносить в ядра обычных операционных систем.



Еще одна интересная особенность Pacifica - это специальный защищенный режим запуска VMM. При желании на компьютере с процессором, поддерживающим данную технологию, можно сделать так, чтобы при старте компьютер на аппаратном уровне проверил цифровую подпись к VMM. Проще говоря, можно «зашить» в компьютер такую программу, что на нём принципиально невозможно будет запустить неподписанные доверенным источником модули VMM. А сами модули от этого «доверенного источника», в свою очередь могут проверить цифровую подпись у запускаемых ими операционных систем; операционные системы - проверять цифровую подпись у запускаемых приложений, и так далее, до сколь угодно высоких степеней контроля того, что именно запущено на компьютере.

Из просто-таки напрашивающихся примеров - можно, к примеру, будет создать такой компьютер, на котором будут запускаться только лицензионные операционные системы производства Microsoft без единого байта «чужих» изменений со стороны любителей халявного ПО. Вернее сказать, запускать на этом компьютере, при желании (скажем, после перепрошивки BIOS) можно будет, конечно, всё что угодно, но при этом в процессоре не взведётся специальный «бит безопасности», легко проверяемый абсолютно любым приложением, и с подобным «не прошедшим проверку» компьютером, к примеру, может отказаться работать какое-нибудь ПО. Для обычного пользователя, боюсь, подобная возможность выльется в очередную кучу проблем с копирайтом и свободным софтом, однако для корпоративных пользователей поддержка «безопасного режима» может оказаться жизненно важной, поскольку позволяет гарантировать безопасность среды, в которой запускается корпоративное приложение. Проверил «безопасный флаг» - значит компьютер гарантированно «чистый», «проверенный». Нет этого флага - значит, в системе что-то изменилось: поменяли часть «железа» (поменяли клавиатуру, на содержащую «жучок»; добавили шпионскую PCI-плату, собирающую информацию о ПО; поставили чужую сетевую карту; посадили в систему «руткит» и так далее).




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

Впрочем, справедливости ради, нужно отметить, что у Intel разрабатывается (уже в течение нескольких лет) собственная технология аппаратной безопасности под названием LaGrande, которая умеет очень многое и даже более готова к выходу на рынок, чем Pacifica. Так что, вполне возможно, что связка Intel VT+LaGrande окажется не менее функционально привлекательной, чем AMD Pacifica. А уж в умении Intel устроить грамотный и широкомасштабный маркетинг своим продуктам сомневаться не приходится.

Само по себе функционирование VMM у AMD очень напоминает функционирование VMM в технологии Intel: VMM с помощью специальных инструкций подготавливает специальные управляющие структуры, описывающие виртуальные компьютеры, «запускает» эти структуры на исполнение и перехватывает выбранные события, там происходящие, подменяя их «ручной» работой. Главное отличие - это объем и тип выполняемой работы. У AMD нет необходимости заниматься сложнейшим менеджментом памяти с подставными таблицами трансляции и синхронизацией этих таблиц с настоящими; нет необходимости в перехвате связанных с этими таблицами трансляции событий. Нужно перехватывать и обрабатывать только некоторые внешние события (скажем, прерывание от таймера, чтобы переключаясь между гостевыми операционными системами создавать иллюзию их одновременной работы; или прерывание от клавиатуры - переключаться между гостевыми ОС по нажатию определенной комбинации клавиш). Да и то, при желании в Pacifica можно попросту «напрямую» подключить выбранные устройства в гостевых операционных системах к физическим ресурсам (в VT-x, для сравнения, любое обращение гостевой ОС к портам ввода-вывода принудительно перехватывается модулем VMM).



Есть и другие особенности, позволяющие минимизировать количество ненужных переключений от гостевой ОС к VMM и обратно, переложив соответствующие проверки на аппаратное обеспечение. А если и приходится всё же переключаться между гостевой ОС, VMM, и другой гостевой ОС - то, опять же по контрасту с VT-x, это переключение происходит крайне быстро, с очень ограниченной необходимостью в сохранении контекста и полным отсутствием необходимости сброса, к примеру, буфера TLB, который обычно при переключении между разными таблицами трансляции приходится полностью очищать. Естественно, что набор перехватываемых событий и возможности «фальсификации» всего и вся ничуть у Pacifica не уже, чем у VT-x; однако настройка что перехватывать, а что нет - гораздо гибче (в VT-x многое перехватывается безусловно; в Pacifica можно отключить практически любой перехват). Даже не знаем, к чему придраться, - вряд ли можно было придумать нечто большее по функциональности, удобное в использовании, и столь быстродействующее.

Набор инструкций Pacifica столь же прост и изящен, как и само решение AMD:


  • Команда VMRUN переключает выполнение на выбранную виртуальную машину.
  • Из виртуальной машины управление возвращается либо по перехвату одного из указанного в настройках виртуальной машины событий, либо при вызове специальной инструкции VMMCALL (если последняя разрешена настройками).
  • Информация о виртуальной машине хранится в специальной структуре данных VMCB (Virtual Machine Control Block) известного формата. VMM работает с данной структурой напрямую, вручную изменяя при необходимости соответствующие поля (в отличие от VT-x, где формат аналогичной структуры VMCS официально неизвестен и для работы с VMCS используются специальные инструкции VMREAD и VMWRITE). На всякий случай еще раз напомним, что сама эта структура относительно невелика и описывает только состояние процессора виртуальной машины, а виртуальную память и состояние виртуальных устройств этой машины VMM должна обслуживать самостоятельно.
  • Самые необходимые операции по переключению контекста при переходах VMM к гостевой ОС и обратно выполняются полностью автоматически.


    Однако, чтобы не совершать лишних действий, сохраняется и загружается действительно только самое необходимое, и при необходимости каких-либо сложных действий или переключения на другую гостевую ОС, «дополнительные» операции сохранения состояния процессора в VMCB и обратной загрузки выполняются инструкциями VMLOAD и VMSAVE.
  • Инструкция SKINIT позволяет начать загрузку процессора в «безопасном режиме», на аппаратном уровне гарантировав соответствие загрузчика (до 64 Кбайт кода) указанной в аппаратуре (в модуле TPM) цифровой подписи

    Пять инструкций. Против десяти в куда более сложном и менее функциональном VT-x. Ну как еще выразить восхищение архитекторами наборов инструкций AMD? Правда, к «пяти базовым» для полного раскрытия возможностей Pacifica можно еще использовать «тактические» три инструкции, позволяющие дополнительно ускорить скорость работы Pacifica:
  • STGI, CLGI - управляют схемой перехвата прерываний в Pacifica (включают-выключают «глобальный перехват прерываний»).
  • INVLPGA - сбрасывает TLB, но не целиком, а только те записи TLB, которые относятся к конкретной гостевой ОС (или к VMM).


Как и в случае с VT-x, для того, чтобы получить доступ к новым инструкциям, программному обеспечению нужно эти инструкции разблокировать (установить 12-й бит регистра EFER MSR, отныне известный как EFER.SVME). При желании в Pacifica можно отключить все её продвинутые функции, вплоть до отключения двойной трансляции виртуальных адресов, что позволяет максимально приблизить (хотя и не до конца) схемы использования к VT-x.

В целом решение AMD явно охватывает всю мыслимую область применимости решения Intel, но изящнее, быстрее и проще в использовании; а главное - обеспечивает более чем достаточный запас прочности для того, чтобы считаться полноценным виртуализационным решением будущего. Тем более что соответствующие процессоры должны появиться уже совсем скоро - в первом квартале 2006 года.

Интересно, что на последнем московском Intel Developer Forum (прошедшем в октябре 2005 года) в докладах совершенно неожиданно прозвучали всё те же знакомые «двойные таблицы трансляции», «защита DMA» и прочие характерные функции Pacifica, рекламировавшиеся как...


второе поколение систем виртуализации Intel. К первому, естественно, относилась «закрывающая дыры x86» технология VT-x. Честно говоря, сам московский IDF с нашей субъективной точки зрения, оказался в плане информации по виртуализации крайне скуп, а уровень «познаний» заменявших своих иностранных коллег сотрудников, выступавших с докладами порой просто шокировал - они были не в состоянии отвечать на задаваемые им из зала неспециалистами вопросы! Но позднее замечательнейший человек - Всеволод Предтеченский, в одиночку заменяющий всех остальных технических специалистов российского отделения Intel - в личной беседе пояснил, что этим самым «вторым поколением» должна стать давным-давно анонсированная «технология безопасности» LaGrande (а вернее, то, во что этот проект превратился к настоящему времени), которая вберёт в себя не только новейшие технологии виртуализации (о которых мы поговорим в последней части), но и сложные системы обеспечения гарантированной безопасности (вплоть до шифрования передаваемых по USB данных мышкой).


Содержание раздела