Журнал «Компьютерра» №32 от 06 сентября 2005 года
Шрифт:
Но стоп, - скажет здесь читатель, - а что же будет, если мы запустим две операционные системы и одна из них решит отобрать для своих целей кусочек физического, а не виртуального пространства памяти другой операционной системы, отобразив его в своей таблице трансляции? В обычных условиях это фатальная ошибка, которая быстро приведет две совместно работающие операционки к краху. Но если у нас есть VMM, то ситуация в корне меняется, ибо мы теперь можем запущенную операционную систему «одурачить», перехватив соответствующее обращение и подсунув ей не настоящий CR3, а специально подготовленную «пустышку». ОС, наивно полагая, что она полностью контролирует виртуальную память компьютера, на самом деле будет всего лишь изменять никак не связанную с настоящей таблицей трансляции область оперативной памяти. А обращения к ней, используя стандартные же механизмы виртуальной памяти, будет перехватывать все тот же VMM и синхронизировать в соответствии с ними настоящую таблицу трансляции. Красиво придумано, не правда ли? Собственно виртуальной машины у нас нет, просто мы тщательно контролируем работу операционной системы и при необходимости ловко манипулируем ею.
Набор
Фальсифицируется все - даже время. Для «подделки» данных счетчика тактов TSC (Time Stamp Counter) в Vanderpool, например, предусмотрен даже не один, а целых два способа - автоматический (к значению TSC прибавляется заданная VMM константа) и «ручной» (перехватываются обращения к RDTSC); аналогично нетрудно перехватить и обращение ОС к системному таймеру с запросом текущего времени. Эдакое «1984» в рамках одного конкретно взятого процессора с VMM в роли Министерства Правды.
В качестве завершающего штриха в описании Vanderpool Technology (VT) приведем блок-схему, поясняющую функционирование технологии и назначение десяти (да-да, всего десяти!) входящих в нее инструкций (рис. 2). Заметим также, что все вышесказанное относилось к варианту VT-x для x86-совместимых процессоров. Кроме нее существует слегка отличающаяся VT-i для процессоров Itanium, но работает она по тем же самым принципам, так что останавливаться на ней я не буду.
Компьютерный мир помешался на совместимости: процессоры Intel и AMD сегодня поддерживают практически идентичные наборы инструкций, а «заклятые друзья» ревниво следят за тем, чтобы процессор конкурента никаких заметных преимуществ перед «родным» процессором не имел. Так, AMD скопировала у Intel набор инструкций SSE (1/2/3); Intel у AMD - 64-битную технологию AMD64 и входящий в ее состав NX-бит: называются они по-разному (SSE у AMD превратилась в 3Dnow! Professional; AMD64 у Intel - в EM64T), но большого значения для ПО это, по сути дела, не имеет. Просто есть некий софт (оптимизированный под SSE ли, под AMD64 - неважно), и производители процессоров стараются сделать все возможное, чтобы этот софт (независимо от того, для какого процессора он разрабатывался) мог запускаться и на их CPU. Из-за этих-то пресловутых требований совместимости до сих пор живет архитектура x86, создававшаяся скорее для микропроцессоров («ноги» i8086 растут из предназначавшегося для калькуляторов i8080) и крайне неудобная для любых современных процессоров (что Athlon, что Pentium вынуждены ее «на лету» преобразовывать в более подходящий для обработки формат). «Хоронили» ее по меньшей мере трижды - в связи с выходом процессоров «правильных» архитектур. Однако ж некогда процветавшие ветви RISC-машин сегодня зачахли, архитектура VLIW не получила должного распространения, а x86 и поныне «живее всех ее хоронивших» - колоссальный парк ПО, накопленного для этой архитектуры, сделал ее практически «непотопляемой». И в свете этого полная несовместимость технологий виртуализации от AMD и от Intel звучит как гром среди ясного неба.
Концептуально - перед нами все тот же выделенный менеджер виртуальных машин с широкими возможностями для перехвата управления у обычных операционных систем и неограниченными правами доступа. Практически - Pacifica проще, функционально богаче и «дружественнее» к разработчику VMM3 (рис. 3). Судите сами: например, можно отказаться от хитроумной и трудоемкой технологии подмены таблиц трансляции виртуальной памяти, используя двухуровневые таблицы. Обычно в таблице трансляции виртуальной памяти записываются физические адреса, но ведь там можно хранить и виртуальные адреса «второго уровня», для которых тоже будет существовать своя, определяемая исключительно VMM, таблица. То есть так же, как операционная система обеспечивает запущенным в ней программам персональные «линейные» участки виртуальной памяти, VMM просто-напросто предоставляет каждой из запущенных операционок свою «виртуальную физическую» оперативную память. И точно так же, как обычная программа не замечает подвоха в работе оперативной памяти, «одураченная» операционная система не будет подозревать, что работает она не в физическом, а в виртуальном адресном пространстве. Не нужно ничего отлавливать, перехватывать и синхронизировать - все происходит в автоматическом режиме, без малейших усилий со стороны VMM. Не совсем понятно, почему Intel отказалась от этого очевидного и радикально упрощающего жизнь программистам шага, однако в текущем варианте несчастные программисты у Intel фактически вынуждены будут дублировать основную функциональность ядра операционной системы (в вопросах, касающихся управления памятью).
Вторая принципиальная «фича» AMD’шной виртуализации - это Tagged TLB, тегированный кэш трансляции виртуальных адресов. TLB представляет собой буфер, позволяющий процессору не заниматься каждый раз чрезвычайно трудоемкой и медленной процедурой преобразования виртуального адреса в физический, а сделать это единожды и впоследствии быстро обращаться к уже вычисленным парам соответствия «виртуальная память - память реальная». Понятно, что при каждом переключении от одной программы к другой (не говоря уже о переключении от одной операционной системы к VMM и обратно), когда процессору приходится переключаться между разными виртуальными пространствами памяти, этот буфер со всей ранее накопленной информацией приходится сбрасывать - в новом виртуальном пространстве старым виртуальным адресам будут соответствовать совсем другие «физические». А значит, каждое переключение к VMM и обратно - это вопиющее расточительство процессорных ресурсов, десятки и сотни тысяч потраченных на восстановление потерянной информации тактов. В реализации AMD буфер TLB запоминает, какой из виртуальных операционных систем какой адрес принадлежит. В обычной ситуации запоминать эту информацию бессмысленно - при переключении задач TLB все равно быстро заполнится новыми адресами, вытесняющими старые; а вот для быстрого переключения от OS к VMM и обратно (когда, возможно, работа VMM не займет и сотни тактов процессорного времени) подобная оптимизация приходится как нельзя более кстати.
Следующий приятный «пунктик» в программе AMD - аппаратная защита контроллера DMA. В обычных условиях этот контроллер позволяет периферийным устройствам работать с оперативной памятью, не привлекая центральный процессор. Например, CPU может не заниматься рутинной и монотонной задачей передачи данных неторопливому винчестеру, а скинуть всю необходимую для сохранения информацию в оперативную память, сообщить жесткому диску, что, откуда и куда сохранять из памяти на диск - и, не дожидаясь окончания этой операции, заняться каким-либо другим делом. Это удобно, это быстро, но в то же время это грандиозная дыра в безопасности в тех случаях, когда две операционные системы, запущенные на одном компьютере, требуется изолировать друг от друга. Ведь никаких проверок на то, что периферийное устройство может запросить совершенно «левый» адрес физической оперативной памяти (если, допустим, по некоей договоренности между драйвером и устройством, по во-о-он тому физическому адресу вроде бы ничего не должно располагаться и его можно использовать как вспомогательный буфер при работе), DMA обычно не производит. Специалисты AMD это упущение исправили - теперь все устройства могут быть разбиты на несколько виртуальных доменов (изначально - по четыре домена на каждый процессор), а DMA-контроллер может проверять, разрешено ли устройству из такого-то домена чтение данных из такой-то области памяти.
Наконец, AMD уже сегодня предоставляет основную часть возможностей еще даже неопубликованной технологии защиты данных Intel LaGrande, а именно - «безопасный» запуск виртуальной операционной системы. Не зря же Intel называет свою технологию VT, а AMD свою - SVM (Security amp; Virtual Machine). Если быть более точным, то специальная инструкция SKINIT позволяет процессору запускать гарантированно безопасный загрузчик - крошечный (64 Кбайт) кусочек подписанного цифровой подписью кода, который затем может проверить и загрузить «безопасный» VMM или «безопасное» ядро обычной операционной системы. Сам загрузчик проверяется специальным аппаратным модулем TPM (которые уже активно устанавливаются в серийные материнские платы), ну а дальнейшая проверка надежности загружаемого этим загрузчиком кода - целиком и полностью лежит на собственно загрузчике. В результате появляется возможность настроить компьютер так, чтобы загружающийся при старте компьютера VMM и (или) запускаемые им операционные системы соответствовали некоторому заданному и аппаратно прошитому «стандарту» (это, например, может гарантировать, что обладающий широчайшими возможностями VMM не станет «шпионить» за клиентским ПО, а на «брэндовом» компьютере запустится только подписанная лицензионная копия MS Windows).
AMD Pacifica пока не в полной мере поддерживает виртуализацию устройств ввода-вывода (как распределить между виртуальными операционными системами реальную периферию - головная боль VMM), как и не в полной мере обеспечивает безопасность каналов ввода-вывода (проще говоря, от подцепленного к периферийному кабелю «жучка» такая защита не спасает), однако все равно можно утверждать, что все принципиально важные вопросы защиты операционных систем и эффективной виртуализации она решает. У корпорации Intel в последнее время и без того хватает неудач, так что я бы очень хотел написать, что черная полоса для нее уже закончилась и анонсированная гораздо раньше конкурента технология виртуализации позволяет ей наконец-то вырваться вперед, но… Да, Vanderpool - замечательная технология, однако Pacifica обходит ее по всем основным показателям.
Не будем сейчас затевать споры о том, чье решение лучше и перспективнее. Со своей главной задачей - запуском произвольного количества виртуальных операционных систем и обеспечением их эффективной одновременной работы - справляются обе технологии, а за Intel стоит все-таки больший сегмент рынка. Вариант AMD смотрится гораздо интереснее, однако для поддержки всех своих возможностей он требует специально заточенных «под AMD» менеджеров виртуальных операционных систем, принципиально несовместимых с Intel Virtualization Technology. Чтобы совсем уж явно не проводить «водораздел» между VMM «для Intel» и «для AMD» (все-таки VMM - очень сложное и трудоемкое программное обеспечение), в Pacifica предусмотрен специальный, скажем так, «режим совместимости» SPT, в котором двойная трансляция адресов виртуальной памяти отключена и VMM «для Intel» можно с небольшими переделками превратить в «урезанный» VMM «для AMD»[Который, правда, даже в таком варианте получается более совершенным и «интересным», нежели Vanderpool. Инженеры AMD, как обычно, сделали все, чтобы обойти коллег из Intel]. Клиентское ПО и операционные системы переделывать не придется и подавно: с «потребительской» точки зрения VMM в компьютере вроде бы как и не существует.