Virtualization-based Security (VBS)

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.

Please notice that TPM is not a must requirement, but we highly recommend to implement TPM.

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 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 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.

  • UEFI v2.6 Memory Attributes Table (MAT) - To ensure compatibility with VBS, firmware must cleanly separate EFI runtime memory ranges for code and data, and report this to the operating system. Proper segregation and reporting of EFI runtime memory ranges allows VBS to apply the necessary page protections to EFI runtime services code pages within the VBS secure region. Conveying this information to the OS is accomplished using the EFI_MEMORY_ATTRIBUTES_TABLE. To implement the UEFI MAT, follow these guidelines:
    1. The entire EFI runtime must be described by this table.
    2. All appropriate attributes for EfiRuntimeServicesData and EfiRuntimeServicesCode pages must be marked.
    3. These ranges must be aligned on page boundaries (4KB), and can not overlap.
  • EFI Page Protections -All entries must include attributes EFI_MEMORY_RO, EFI_MEMORY_XP, or both. All UEFI memory that is marked executable must be read only. Memory marked writable must not be executable. Entries may not be left with neither of the attributes set, indicating memory that is both executable and writable.
    • 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:
    1. Use Driver Verifier with the Code Integrity compatibility checks enabled.
    2. Run the Hypervisor Code Integrity Readiness Test in the Windows HLK.
    3. Test the driver on a system with VBS and memory integrity enabled. This step is imperative to validate the driver's behavior with memory integrity, as static code analysis tools simply aren't capable of detecting all memory integrity violations possible at runtime.

    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.