Virtualization-based Security (VBS)
Virtualization-based security, or VBS, uses hardware virtualization features to create and isolate a secure region of memory from the normal operating system. Windows can use this "virtual secure mode" 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.
One such example security solution is Hypervisor-Enforced Code Integrity (HVCI), commonly referred to as Memory integrity, which uses VBS to significantly strengthen code integrity policy enforcement. Kernel mode code integrity checks all kernel mode drivers and binaries before they're started, and prevents unsigned drivers or system files from being loaded into system memory.
VBS uses the Windows hypervisor to create this virtual secure mode, and to enforce restrictions which protect vital system and operating system resources, or to protect security assets such as authenticated user credentials. With the increased protections offered by VBS, even if malware gains access to the OS kernel the possible exploits can be greatly limited and contained, because the hypervisor can prevent the malware from executing code or accessing platform secrets.
Similarly, user mode configurable code integrity policy checks applications before they're loaded, and will only start executables that are signed by known, approved signers. HVCI leverages VBS to run the code integrity service inside a secure environment, providing stronger protections against kernel viruses and malware. The hypervisor, the most privileged level of system software, sets and enforces page permissions across all system memory. Pages are only made executable after code integrity checks inside the secure region have passed, and executable pages are not writable. That way, even if there are vulnerabilities like a buffer overflow that allow malware to attempt to modify memory, code pages cannot be modified, and modified memory cannot be made executable.
VBS requires the following components be present and properly configured.
Please notice that TPM is not a must requirement, but we highly recommend to implement TPM.
|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||TPMs, either discrete or firmware, will suffice. 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 Windows virtualization-based security (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.|
|Hypervisor Code Integrity (HVCI)-compatible drivers||Ensure all system drivers have been tested and verified to be compatible with HVCI. The Windows Driver Kit and Driver Verifier contain tests for driver HVCI compatibility. There are four steps to verify driver compatibility:
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|
|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
|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|
|Lsv2||Yes||1 and 2|