Enable windows virtualization based security что это

Обновлено: 04.07.2024

Безопасность на основе виртуализации (VBS) использует функции виртуализации оборудования для создания и изоляции защищенного региона памяти от обычной операционной системы. Windows может использовать этот "виртуальный безопасный режим" для размещения ряда решений по обеспечению безопасности, предоставляя им значительно повышенную защиту от уязвимостей в операционной системе и предотвращая использование вредоносных эксплойтов, пытающихся предотвратить защиту.

Одним из таких примеров решения безопасности является Hypervisor-Enforcedная целостность кода (обязательная политика HVCI), которая, как правило, называется целостностью памяти, которая использует VBS для значительного усиления применения политики целостности кода. Целостность кода в режиме ядра проверяет все драйверы и двоичные файлы режима ядра перед их запуском и предотвращает загрузку неподписанных драйверов или системных файлов в системную память.

VBS использует гипервизор Windows для создания этого виртуального безопасного режима, а также для обеспечения ограничений, которые защищают критически важные ресурсы системы и операционной системы или защищают активы безопасности, например учетные данные пользователя, прошедшего проверку подлинности. Благодаря расширенным средствам защиты, предоставляемым VBS, даже если вредоносная программа получает доступ к ядру ОС, возможные эксплойты могут быть значительно ограничены и храниться, так как гипервизор может препятствовать выполнению кода или доступу к секретам платформы.

Для VBS необходимо, чтобы были установлены и правильно настроены следующие компоненты.

Обратите внимание, что доверенный платформенный модуль не обязательно должен быть обязательным, но мы настоятельно рекомендуем реализовать TPM.

Эта таблица должна описывать всю среду выполнения EFI.
Все соответствующие атрибуты для страниц Ефирунтимесервицесдата и Ефирунтимесервицескоде должны быть помечены.
Эти диапазоны должны быть согласованы по границам страниц (КБ) и не могут перекрываться.

Используйте средство проверки драйверов с включенной проверкой совместимости с проверкой целостности кода .
запустите тест готовности к целостности кода гипервизора в Windows хлк.
Протестируйте драйвер в системе с включенными VBS и обязательная политика HVCI. Этот шаг является обязательным для проверки поведения драйвера с помощью обязательная политика HVCI, так как средства анализа статического кода просто не способны обнаруживать все нарушения обязательная политика HVCI, возможные во время выполнения.
Используйте средство дгреадинесс.

Связанные темы

Дополнительные сведения о Hyper-V см. в статье Hyper-V в Windows Server 2016 или Знакомство с Hyper-V в Windows 10. Дополнительные сведения о гипервизоре см. в статье Спецификация гипервизора.

После перехода на операционную систему Windows 11 многие пользователи заметили снижение производительности в играх. Согласно некоторым тестам, эти потери составляют до 25%.

Одна из причин такого снижения производительности – технология VBS, обеспечивающая дополнительную защиту системы от вредоносных программ. В данной статье мы расскажем о том, как отключить VBS на Windows 11 и для чего нужна эта технология.

Что такое VBS/HVCI на Windows 11

VBS или Virtualization-based Security (Безопасность на основе виртуализации) – это функция аппаратной виртуализации, которая создает и изолирует от остальной операционной системы безопасную область в оперативной памяти. Windows может использовать эту изолированную безопасную область памяти для хранения важных для безопасности данных и кода.

Использование изолированной части памяти позволяет защититься от эксплойтов, направленных на преодоление средств защиты. Вредоносное ПО часто атакует на встроенные механизмы безопасности Windows, чтобы вывести их из строя или получить доступ к важным системным ресурсам. Например, вредоносный код может получить доступ к ресурсам уровня ядра, обойдя методы проверки подлинности кода Windows.

VBS решает эту проблему, отделяя средства защиты системы от остальной части ОС. Это делает Windows более безопасной, поскольку вредоносные программы не могут обойти встроенную защиту ОС. Одной из таких средств защиты является Hypervisor-Enforced Code Integrity (HVCI).

HVCI использует VBS для выполнения проверки целостности кода. В частности, HVCI проверяет подлинность драйверов и программ режима ядра, чтобы убедиться, что они получены из надежных источников. Таким образом, HVCI гарантирует, что в память загружается только доверенный код.

Как проверить включен ли VBS

Вы можете проверить включен ли VBS на вашем компьютере с Windows 11. Для этого нужно открыть окно « Выполнить » ( Win-R ) или меню « Пуск » и ввести команду « msinfo32 ».

В результате откроется окно « Сведения о системе ».

Здесь в самом низу окна будет пункт « Безопасность на основе виртуализации ». Если в нем указано « Выполнение », значит VBS включен.

Как отключить VBS через настройки

Самый простой способ отключить VBS на Windows 11 – это воспользоваться стандартными настройками Windows 11. Для этого откройте меню « Пуск », введите в поиск фразу « Изоляция ядра » или « Core isolation » и откройте найденную программу.

После этого нужно перезагрузить компьютер, чтобы настройки применились.

Как отключить VBS через реестр

Также вы можете отключить VBS через реестр Windows 11. Для этого нужно открыть окно « Выполнить » ( Win-R ) или меню « Пуск », ввести команду « regedit » и открыть редактор реестра.

В редакторе реестра нужно перейти в следующий раздел настроек:

И создать там DWORD параметр с названием « EnableVirtualizationBasedSecurity ».

Дальше нужно открыть параметр « EnableVirtualizationBasedSecurity » и присвоить ему значение « 0 ».

После этого нужно перезагрузить компьютер, чтобы настройки применились.

Как отключить VBS через политики

Если у вас Pro-версия Windows 11, то вы можете отключить VBS через локальные групповые политики. Для этого нужно открыть окно « Выполнить » ( Win-R ) или меню « Пуск », ввести команду « gpedit.msc » и открыть « Редактор локальных групповых политик ».

Здесь нужно открыть параметр « Включить средство обеспечения безопасности на основе виртуализации ».

Привет, Хабр! Я Александр Воронцов, технический специалист Cloud4Y. В этой статье расскажу про vSphere Virtual Machine Encryption. Здесь не будет описания опыта внедрения. Это, скорее, обзор технологии и её неочевидных нюансов и особенностей, не описанных в документации. Я постараюсь дать ответы на вопросы, которые могут возникнуть у специалиста в процессе изучения.

Демонстрацию буду проводить на тестовом стенде vSphere 6.7 U3, Cloud Director 10.2

vSphere VM Encryption — механизм шифрования виртуальных машин, который впервые появился в VMware vSphere 6.5. Официальная документация по VM Encryption по ссылке. VM Encryption требует VMware vSphere 6.5 и новее и KMS (кластера KMS) с поддержкой протокола KMIP v1.1. VMware не предоставляет KMS, его требуется приобрести отдельно у другого вендора. В vSphere 7.0 U2 добавили Native Key Provider, который можно использовать вместо внешнего KMS для VM Encryption. В данной статье его не рассматриваю.

KMS — Key Management Server - Сервер управления ключами.

KMIP — Key Management Interoperability Protocol - протокол совместным управлением ключами. По этому протоколу происходит взаимодействие между vCenter и KMS сервером.

vTPM — Virtual Trusted Platform Module - виртуальный аналог TPM, криптографический модуль, предназначенный для хранения ключей. Может использоваться в паре с Windows Bitlocker.

Какие задачи решает VM Encryption

VM Encryption позволяет хранить файлы виртуальной машины (файл конфигурации, файлы виртуальных дисков, снапшоты и т. п.) в зашифрованном виде на СХД, не прибегая к средствам шифрования самой СХД.

VM Encryption позволяет облачному провайдеру дополнительно защитить свою инфраструктуру (напр. зашифровать служебные VM), а также предоставлять своим клиентам опциональную возможность шифрования клиентских VM с управлением шифрованием через VMware Cloud Director.

VM Encryption позволяет клиенту облачного провайдера зашифровать свои VM в облаке, а также использовать vTPM (Virtual Trusted Platfom Module) в связке, например c Windows BitLocker.

Как это работает

У VMware есть видео, которое демонстрирует работы механизма vSphere Virtual Machine Encryption.

В механизме VM Encryption используется два ключа симметричного шифрования:

1. Data Encryption Key (дал. DEK). Этот ключ генерирует ESXi хост. Таким ключом зашифрованы файлы конфигурации и файлы виртуальных дисков виртуальной машины. Для файлов конфигурации VM DEK хранится в *.vmx в зашифрованном виде, для файлов виртуальных дисков - в *.vmdk файле в зашифрованном виде.

Давайте рассмотрим процессы, который происходят при работе VM Encryption.

Этапы инициализации шифрования:

vCenter запрашивает KEK у KMS. KMS генерирует KEK, сохраняет его в своей базе данных, и передает его vCenter. vCenter передаёт KEK всем ESXi в vSphere High Avalibility кластере. ESXi хранят KEK в оперативной памяти и никогда не записывают его на диск.

ESXi, получив KEK, генерирует DEK, зашифровывает DEK с помощью KEK и записывает зашифрованный DEK в конфигурационный файл VM.

ESXi выполняет процесс шифрования файлов VM с помощью DEK.

Этапы включения зашифрованной VM:

ESXi получает команду на запуск зашифрованной VM, проверяет в своей ОЗУ наличие KEK для расшифровки VM. Если KEK нет в ОЗУ ESXi, KEK запрашивается у vCenter, а vCenter запрашивает KEK у KMS.

KMS передаёт KEK vCenter, а vCenter передаёт KEK ESXi хосту.

ESXi хост запускает VM.

Этапы миграции vMotion зашифрованной VM:

При миграции vMotion KMS сервер не используется. Encrypted vMotion можно использовать и без VM Encryption.

ESXi получает команду на миграцию VM на другой ESXi хост. Если миграция выполняется в другой ESXi кластер, то на этом шаге vCenter запросит KEK у KMS и передаст его на ESXi назначения.

ESXi источника запрашивает "одноразовый ключ" у vCenter. vCenter генерирует ключ и передаёт его хостам источника и назначения миграции.

ESXi источника зашифровывает "одноразовым ключом" ОЗУ виртуальной машины и расшифрованный DEK и передаёт их на хост назначения с помощью vMotion

ESXi назначения расшифровывает "одноразовым ключом" полученные данные и VM продолжает работу на ESXi назначения.

Как настроить VM Encryption

Поскольку есть множество KMS серверов с поддержкой KMIP (у VMware даже есть документ, описывающий "сертифицированные KMS"), я не буду рассматривать конкретную реализацию KMS, выбор и настройку также обойду стороной. В моей тестовой среде уже есть кластер KMS из трёх нод, в котором каждая нода реплицирует данные с другими нодами.

Если у вас нет KMS, можете взять любой из списка "сертифицированных". Бесплатных решений в этом списке нет, если требуется что-то такое, смотрите в сторону PyKMIP. Кластер на PyKMIP построить нельзя, но с vCenter он работает. Проверял.

Для кластера KMS не требуется Load Balancer. Все ноды кластера равнозначны, содержат одинаковую базу данных и vCenter может запросить ключ у любой ноды KMS, а KMS, который выдал ключ, реплицирует этот ключ на другие ноды.

Установка доверительных отношений между vCenter и KMS

Давайте подключим наши vCenter к кластеру KMS. Процедуру подключения необходимо повторить на каждом vCenter.

Создаём новый кластер, указываем адрес нашей первой ноды и порт 5696 (стандартный порт KMIP). В моем случае логин и пароль указывать не требуется, но это может зависеть от реализации KMS.

Говорим vCenter доверять KMS.

На следующем шаге нам нужно, чтобы KMS доверял vCenter. Нажимаем MAKE KMS TRUST VCENTER.

На выбор есть несколько вариантов установки доверия KMS к vCenter. В случае с нашим кластером используется способ загрузки в vCenter ключевой пары KMS.

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

После установки доверия KMS к vCenter, кластер KMS будет доверять этому vCenter. Добавляем в vCenter остальные ноды KMS (загрузка пары ключей этих нод не потребуется) и на этом настройка KMS завершена.

Создание Storage Policy с шифрованием

Следующим шагом будет создание Storage Policy, использующей шифрование.

VM Encryption позволяет хранить VM с шифрованием и без шифрования на одной СХД. У нас уже есть Storage Policy vcd-default-policy. Создадим аналогичную vcd-default-encrypted-policy и включим шифрование в параметрах Host based services.

Как управлять шифрованием из vSphere Client

Когда KMS и Storage Policy настроены, можно применить Storage Policy с шифрованием к VM. Включаем шифрование в настройках VM, выбирая vcd-default-encrypted-policy. На примере Linux машины это выглядит так.

Применяем настройки, и в Tasks виртуальной машины видим прогресс выполнения первичного шифрования.

Шифрование конфигурационных файлов VM без шифрования дисков

Мы можем зашифровать конфигурационные файлы VM, не шифруя файлы виртуальных дисков VM. Для этого нам нужно включить шифрование VM, а затем переопределить Storage Policy для виртуальных дисков. В результате такой настройки в vSphere Client мы увидим:

VM configuration files are encrypted.

No hard disks are encrypted.

Мы можем использовать такой сценарий для подключения vTPM и используя Bitlocker в Windows VM. Про vTPM и Bitlocker расскажу дальше.

Из vSphere невозможно выгрузить VM (в ova или ovf), использующую VM Encryption.

Дополнительные возможности для Windows

Virtualization Based Security

Для Windows 10, Windows Server 2016 и новее мы можем использовать Virtualization Based Security. Включение VBS принудительно установит механизм загрузки в UEFI и включит Secure Boot. Если VM использовала BIOS, она, скорее всего, не загрузится после включения.

Про VBS можно прочитать в документации Microsoft или блоге VMware. VBS недостаточно включить в настройках виртуальной машины, его необходимо настроить в гостевой ОС. Процедура настройки описана здесь и в документации Microsoft.

Virtual Trusted Platform Module

Для Windows 10 и Windows Server 2016 и новее, включив шифрование конфигурационных файлов VM и используя для загрузки UEFI (Secure boot можно не включать), в настройках VM становится доступна установка vTPM.

Данные vTPM хранятся в файле *.nvram в зашифрованном виде.

В гостевой ОС vTPM определяется как обычный физический TPM 2.0.

vTPM в Windows определяется как обычный TPM 2.0

Bitlocker

С vTPM мы можем использовать Windows Bitlocker без ввода пароля при загрузке Windows.

Windows будет загружаться автоматически и разблокировать диски с помощью ключей в vTPM. Если такую VM вынести за пределы площадки облачного провайдера, (или, если vTPM будет изменён, а такое происходит даже при восстановлении бэкапа VM, кроме восстановления поверх) то Bitlocker будет требовать ввести ключ восстановления Bitlocker. Перенести ключи из vTPM невозможно (такой кейс не описан в документации и простых способов извлечения ключей из vTPM я не вижу).

После ввода ключа восстановление Bitlocker диск останется зашифрован и начнёт использовать новый vTPM, т.е., в случае изменения vTPM, ключ восстановления Bitlocker нужно будет ввести только 1 раз.

Кейс использования vTPM + Bitlocker может быть компромиссом между удобством (VM включается автоматически без ввода пароля Bitlocker) и безопасностью данных (данные зашифрованы средствами гостевой ОС).

Как управлять шифрованием VM из VMware Cloud Director. Взгляд со стороны клиента облачного провайдера

Через панель управления VMware Cloud Director 10.1 и новее есть возможность выбрать Storage Policy, использующую шифрование.

Можно изменять как VM default policy, и в этом случае, изменится политика всех дисков VM, у которых Storage policy не задана явно (задана как VM default policy), а также изменится политика хранения конфигурационных файлов VM.

Также можно задавать Storage Policy индивидуально для каждого диска.

Необходимо придерживаться правила, чтоб все диски VM были или зашифрованы, или были без шифрования. При попытке использования дисков с шифрованием и без шифрования на одной виртуальной машине VMware Cloud Director не позволит это сделать.

При зашифрованных конфигурационных файлах виртуальной машины мы увидим напротив VM Storage Policy надпись (Encrypted). При зашифрованных дисках надпись (Encrypted) будет отображаться напротив каждого виртуального диска.

vTPM без шифрования диска средствами VM Encryption

Чтобы подключить vTPM, конфигурационные файлы VM нужно зашифровать (также, должен быть включен Secure Boot и использовать Windows в качестве гостевой ОС). Если использовать Bitlocker, то шифрование дисков VM средствами VM Encryption приведёт к двойному шифрованию и может негативно сказаться на производительности. Чтобы зашифровать конфигурационные файлы и не шифровать диски VM,необходимо назначить VM Storage Policy c шифрованием, а для дисков использовать Storage Policy без шифрования.

Подключить vTPM из интерфейса VMware Cloud Director нельзя, но это возможно сделать через vSphere Client силами инженеров облачного провайдера.

Через VMware Cloud Director невозможно выгрузить VM , использующую VM Encryption.

Недокументированная фича

vTPM для *nix систем

Существует недокументированный способ подключить vTPM для *nix, или для Windows, использующей BIOS. Этим способом можно подключить vTPM к любой виртуальной машине.

Для этого нужно подключить vTPM, используя PowerCLI. Установим PowerCLI и выполним скрипт через PowerShell.

Выполните через PowerShell Install-Module -Name VMware.PowerCLI

После выполнения скрипта мы увидим, что конфигурационные файлы VM зашифрованы, но диск использует Storage Policy без шифрования.

vTPM на Linux VM

Также отобразится подключенный vTPM.

vTPM на Linux VM

Проверим работу vTPM в Ubuntu 1804.

На Ubuntu установим пакеты:

apt install clevis clevis-tpm2

Проверим наличие TPM

test -c /dev/tpm0 && echo OK || echo FAIL

Проверим работу TPM

echo 'Test vTPM' | clevis encrypt tpm2 '<>' > test.jwe

cat test.jwe | clevis decrypt tpm2

vTPM работает. Теперь мы можем настроить шифрование диска, используя ключи из vTPM, например, по этой статье.

Это недокументированная фича. Используйте на свой страх и риск.

Как делать резервные копии зашифрованных VM

Я провёл тестирования резервного копирования и восстановления с помощью Veeam Backup & Replication 10. Использовал один сервер бэкапа и две виртуальные машины Veeam Proxy в режиме Virtual Appliance. Тестировал бэкап из vDC VMware Cloud Director.

Для того, чтобы Virtual Appliance прокси мог делать бэкап зашифрованной VM, он сам должен являться зашифрованной VM. Подробнее в документации VEEAM.

Провёл 35 тестов. Во всех тестах использовал Windows Server 2019 EN c 1 диском на 40ГБ.

Рассматривал 6 вариаций конфигурации VM:

VM с UEFI и включенным Secure Boot;

VM с UEFI, включенным Secure Boot и включенным Virtualization Based Security ;

VM с UEFI, включенным Secure Boot, включенным Virtualization Based Security, установленным vTPM и настроенным BitLocker в гостевой ОС;

VM с BIOS, бэкап которой выполнялся на Storage Policy без шифрования, затем было включено шифрования и бэкап выполнялся уже зашифрованной VM (Кейс, где шифрование будет включено на VM, бэкап которой уже выполнялся до включения шифрования).

Для каждой VM протестировал 2 варианта бэкапа и 3 варианта восстановления.

Платформа виртуализации 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); ; .

Можно сказать, что пока API получается использовать эффективно только в user mode (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).

Продолжение доступно только участникам

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее

Читайте также: