Технології віртуалізації: вчора, сьогодні, завтра (стр. 6 из 8)

а) Віртуалізація завтра: 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 повинна обслуговувати самостійно.