Virtualization-based security, or VBS, uses hardware virtualization and the Windows hypervisor to create an isolated virtual environment that becomes the root of trust of the OS that assumes the kernel can be compromised. Windows uses this isolated environment to host a number of security solutions, providing them with greatly increased protection from vulnerabilities in the operating system, and preventing the use of malicious exploits which attempt to defeat protections. VBS enforces restrictions to protect vital system and operating system resources, or to protect security assets such as authenticated user credentials.
One such example security solution is memory integrity, which protects and hardens Windows by running kernel mode code integrity within the isolated virtual environment of VBS. Kernel mode code integrity is the Windows process that checks all kernel mode drivers and binaries before they're started, and prevents unsigned or untrusted drivers or system files from being loaded into system memory. Memory integrity also restricts kernel memory allocations that could be used to compromise the system, ensuring that kernel memory pages are only made executable after passing code integrity checks inside the secure runtime environment, and executable pages themselves are never writable. That way, even if there are vulnerabilities like a buffer overflow that allow malware to attempt to modify memory, executable code pages cannot be modified, and modified memory cannot be made executable.
Note
Memory integrity is sometimes referred to as hypervisor-protected code integrity (HVCI) or hypervisor enforced code integrity, and was originally released as part of Device Guard. Device Guard is no longer used except to locate memory integrity and VBS settings in Group Policy or the Windows registry.
VBS requires the following components be present and properly configured.
| Hardware requirement | Details |
|---|---|
| 64-bit CPU | Virtualization-based security (VBS) requires the Windows hypervisor, which is only supported on 64-bit IA processors with virtualization extensions, including Intel VT-X and AMD-v. |
| Second Level Address Translation (SLAT) | VBS also requires that the processor’s virtualization support includes Second Level Address Translation (SLAT), either Intel VT-X2 with Extended Page Tables (EPT), or AMD-v with Rapid Virtualization Indexing (RVI). |
| IOMMUs or SMMUs (Intel VT-D, AMD-Vi, Arm64 SMMUs) | All I/O devices capable of DMA must be behind an IOMMU or SMMU. An IOMMU can be used to enhance system resiliency against memory attacks. |
| Trusted Platform Module (TPM) 2.0 | For more information, see Trusted Platform Module (TPM) 2.0. |
| Firmware support for SMM protection | System firmware must adhere to the recommendations for hardening SMM code described in the Windows SMM Security Mitigations Table (WMST) specification. The WSMT specification contains details of an ACPI table that was created for use with Windows operating systems that support VBS features. Firmware must implement the protections described in the WSMT specification, and set the corresponding protection flags as described in the specification to report compliance with these requirements to the operating system. |
| Unified Extensible Firmware Interface (UEFI) Memory Reporting | UEFI firmware must adhere to the following memory map reporting format and memory allocation guidelines in order for firmware to ensure compatibility with VBS.
|
| Secure Memory Overwrite Request (MOR) revision 2 | Secure MOR v2 is enhanced to protect the MOR lock setting using a UEFI secure variable. This helps guard against advanced memory attacks. For details, see Secure MOR implementation. |
| Memory integrity-compatible drivers | Ensure all system drivers have been tested and verified to be compatible with memory integrity. The Windows Driver Kit and Driver Verifier contain tests for driver compatibility with memory integrity. There are three steps to verify driver compatibility:
|
| Secure Boot | Secure Boot must be enabled on devices leveraging VBS. For more information, see Secure Boot |
VBS works on VMs that have nested virtualization support. This includes all Gen2 VMs, and Gen1 VMs that support nested virtualization. A list of supported VM series is detailed in the table below.
| VM Series Name | Nested Virtualization | VM Gen |
|---|---|---|
| Av2 | Yes | 1 (certain internal sizes support gen 2) |
| B | No | 1 and 2 |
| Dsv2/Dv2/Dv3/Ev3 | Yes | 1 |
| Dsv3/Ddsv3 | Yes | 1 and 2 |
| Dsv4/Ddsv4 | Yes | 1 and 2 |
| Esv3/Edsv3 | Yes | 1 and 2 |
| Esv4/Edsv4 | Yes | 1 and 2 |
| Ev4/Edv4 | Yes | Ev4 - 1 only Edv4 -1&2 |
| Dv4/Ddv4 | Yes | 1 and 2 |
| Dv5/Ddv5/Dsv5/Ddsv5 | Yes | 1 and 2 |
| Ev5/Edv5/Esv5/Edsv5 | Yes | 1 and 2 |
| Dasv5/Dadsv5/Easv5/ Eadsv5 | Yes | 1 and 2 |
| Ebsv5/Edbsv5 | Yes | 1 and 2 |
| Fsv2 | Yes | 1 and 2 |
| Fx | Yes | 2 |
| Lsv2 | Yes | 1 and 2 |
For more info about Hyper-V, see Hyper-V on Windows Server 2016 or Introduction to Hyper-V on Windows 10. For more info about hypervisor, see Hypervisor Specifications.
