Как устроена память Hyper-V. EXO-разделы и виртуальные машины сторонних производителей

За последние несколько лет в Microsoft создали массу проблем для разработчиков виртуальных машин. Причина тому — ряд новых технологий (VBS, Windows Sandbox, WSL), активно использующих возможности аппаратной виртуализации Hyper-V. Разработчики стороннего ПО для виртуализации больше не могут применять собственный гипервизор и должны полагаться на API, который предоставляет Microsoft.

Платформа виртуализации Hyper-V, разработанная в Microsoft, появилась достаточно давно — первый доклад о ней опубликован на конференции WinHEC в 2006 году, сама платформа была интегрирована в Windows Server 2008. На первых порах в Microsoft охотно делились описанием API Hyper-V (он даже присутствовал в Microsoft SDK 7.0), но со временем официальной информации об интерфейсах Hyper-V становилось все меньше. В конце концов она осталась только в виде Hyper-V Top Level Function Specification, которые предоставляют разработчикам операционных систем, желающим создать условия для работы своей ОС внутри Hyper-V.

Еще большие проблемы возникли после того, как в Windows 10 внедрили технологию Virtualization Based Security (VBS), компоненты которой (Device Guard, Code Integrity и Credential Guard) используют Hyper-V для защиты критичных компонентов операционной системы. Оказалось, что существующие системы виртуализации, такие как QEMU, VirtualBox и VMware Workstation, не могут работать в этих условиях при использовании функций аппаратной виртуализации процессора. Работающий Hyper-V просто блокировал их выполнение.

VBS появился в Enterprise-версии Windows 10, build 1511 (ноябрь 2015 года) как отдельный компонент, но в сборке 1607 уже стал частью ОС, а в декабре 2019-го его сделали активным по умолчанию. Из-за этого начались сбои сторонних виртуальных машин.

Для решения этой проблемы Microsoft разработала Windows Hypervisor Platform API, которые предоставляют следующие возможности для сторонних разработчиков:

• создание «разделов» Hyper-V и управление ими;
• управление памятью для каждого раздела;
• управление виртуальными процессорами гипервизора.

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

API стали доступны в Windows 10 начиная со сборки 1803 (April 2018 update), через компонент Windows Hypervisor Platform (WHPX). Первым поддержкой WHPX обзавелся эмулятор QEMU, для которого программисты Microsoft разработали модуль ускорения WHPX, продемонстрировав, что их API работоспособны. За ними последовали разработчики Oracle VirtualBox, которым пришлось несколько раз переписать код поддержки WHPX по причине изменений в Windows 10 1903.

Компания VMware выпустила версию своей виртуальной машины с поддержкой Hyper-V только 28 мая 2020 года (версия 15.5), аргументировав столь долгую задержку необходимостью переписать весь стек виртуализации.

При этом реализация VMware для Hyper-V потеряла поддержку вложенной виртуализации, и будет ли она добавлена — неизвестно. Также сейчас обсуждают, что производительность заметно снизилась.

Итого в настоящее время WHPX API используются:

• в QEMU;
• VirtualBox;
• VMware Workstation, начиная с версии 15.5 (а также Preview версии 20H2);
• Android emulator, созданном Google;
• Applepie — A Hypervisor For Fuzzing Built With WHVP And Bochs.

Можно сказать, что пока API получается использовать эффективно только в usermode (QEMU, Bochs). И что будет дальше — непонятно. С одной стороны, можно заметить, что API меняются. Новые функции появляются каждые полгода при выходе новой версии Windows и даже при выпуске ежемесячных кумулятивных обновлений.

Например, вот список функций, экспортируемых vid.dll в зависимости от версии Windows.

Как видно, набор функций меняется, особенно для серверных версий Windows.

Для WHVP API все гораздо более стабильнее, что, в общем-то, логично для публичных API.

Официальная документация Hyper-V TLFS обновляется крайне редко — последний апдейт затронул появление вложенной виртуализации, но информации не слишком много, она позволяет считать данные о внутренних структурах гипервизора, что я делал в свое время с помощью утилиты LiveCloudKd. Пока эту информацию получается использовать только в исследовательских целях — применить ее на практике, интегрировав, например, в отладчик, не представляется возможным.

Отдельно стоит упомянуть, что облако Microsoft Azure использует одну и ту же кодовую базу с Hyper-V, о чем говорит менеджер Hyper-V Бен Армстронг (запись сессии — на третьей минуте). Однако основной модуль Hyper-V в Azure отличается и явно собран с некоторыми директивами условной компиляции (достаточно сравнить hvix64/hvax64 для Windows Server 2019 и Windows 10, чтобы определить, что они отличаются достаточно сильно).

Термины и определения

• WDAG — Windows Defender Application Guard (или MDAG — Microsoft Defender Application Guard в более новых версиях Windows).
• Full VM — стандартная полноценная виртуальная машина, созданная в Hyper-V Manager. Отличается от контейнеров WDAG, Windows Sandbox, Docker в режиме изоляции Hyper-V.
• Root ОС — операционная система, в которой установлена серверная часть Hyper-V.
• Гостевая ОС — операционная система, которая работает в контексте эмуляции Hyper-V, в том числе используя виртуальные устройства, предоставляемые гипервизором. В статье могут иметься в виду как Full VM, так и контейнеры.
• TLFS — официальный документ Microsoft Hypervisor Top-Level Functional Specification 6.0.
• GPA (guest physical address) — физический адрес памяти гостевой операционной системы.
• SPA (system physical address) — физический адрес памяти root ОС.
• Гипервызов (hypercall) — сервис гипервизора, вызываемый посредством выполнения команды vmcall (для процессоров Intel) с указанием номера гипервызова.
• VBS (Virtualization Based Security) — средство обеспечения безопасности на основе виртуализации.
• EXO-раздел — объект «раздел», создаваемый при запуске виртуальных машин, работающих под управлением Windows Hypervisor Platform API.
• WHVP API — Windows Hypervisor Platform API.

Устройство памяти EXO-разделов

В своем исследовании я использовал Windows 10 x64 Enterprise 20H1 (2004) в качестве root ОС и для некоторых случаев Windows 10 x64 Enterprise 1803 с апдейтами на июнь 2020-го (ее поддержка закончится в ноябре 2020-го, поэтому информация предоставлена исключительно для сравнения). В качестве гостевой ОС — Windows 10 x64 Enterprise 20H1 (2004).

В Windows SDK 19041 (для Windows 10 2004) присутствуют три заголовочных файла:

• WinHvPlatform.h;
• WinHvPlatformDefs.h;
• WinHvEmulation.h.

Функции экспортируются библиотекой winhvplatform.dll и описаны в заголовочном файле WinHvPlatform.h. Эти функции — обертки над сервисами, предоставляемыми vid.dll (библиотека драйверов инфраструктуры виртуализации Microsoft Hyper-V), которая, в свою очередь, вызывает сервисы драйвера vid.sys (Microsoft Hyper-V Virtualization Infrastructure Driver).

Источник: xakep.ru