Как устроена память Hyper-V. EXO-разделы и виртуальные машины сторонних производителей - «Новости» » Самоучитель CSS
Меню
Наши новости
Учебник CSS

Невозможно отучить людей изучать самые ненужные предметы.

Введение в CSS
Преимущества стилей
Добавления стилей
Типы носителей
Базовый синтаксис
Значения стилевых свойств
Селекторы тегов
Классы
CSS3

Надо знать обо всем понемножку, но все о немногом.

Идентификаторы
Контекстные селекторы
Соседние селекторы
Дочерние селекторы
Селекторы атрибутов
Универсальный селектор
Псевдоклассы
Псевдоэлементы

Кто умеет, тот делает. Кто не умеет, тот учит. Кто не умеет учить - становится деканом. (Т. Мартин)

Группирование
Наследование
Каскадирование
Валидация
Идентификаторы и классы
Написание эффективного кода

Самоучитель CSS

Вёрстка
Изображения
Текст
Цвет
Линии и рамки
Углы
Списки
Ссылки
Дизайны сайтов
Формы
Таблицы
CSS3
HTML5

Новости

Блог для вебмастеров
Новости мира Интернет
Сайтостроение
Ремонт и советы
Все новости

Справочник CSS

Справочник от А до Я
HTML, CSS, JavaScript

Афоризмы

Афоризмы о учёбе
Статьи об афоризмах
Все Афоризмы

Видео Уроки


Видео уроки
Наш опрос



Наши новости

       
24-06-2020, 16:00
Как устроена память 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).


За последние несколько лет в 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).

Теги: CSS

Просмотров: 364
Комментариев: 0:   24-06-2020, 16:00
Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь. Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.

 
Еще новости по теме:



Другие новости по теме:
Комментарии для сайта Cackle