Windows 11 Hypervisor-Protected Code Integrity

Windows 11 protects its core operating system through Hypervisor-Protected Code Integrity (HVCI), also known as Memory Integrity. By leveraging hardware virtualization, Windows creates an isolated, highly secure environment that restricts the OS kernel from modifying its own execution rules. This article explains how Windows 11 utilizes Virtualization-Based Security (VBS) and hypervisor memory controls to prevent malicious code from executing within the Windows kernel, ensuring that even compromised kernel-level drivers cannot bypass security policies.

Virtualization-Based Security (VBS) Architecture

At the foundation of this protection is the Windows hypervisor (Hyper-V). When Virtualization-Based Security (VBS) is enabled, the hypervisor divides system memory into distinct Virtual Trust Levels (VTLs):

• VTL0 (Normal World): The standard operating environment where user applications, third-party software, and the standard Windows kernel operate.
• VTL1 (Secure World): A restricted, isolated environment that runs secure micro-services, isolated security authorities, and the code integrity verification engine.

Because the hypervisor operates below the operating system, code running inside VTL0 cannot directly access or alter the memory assigned to VTL1.

How HVCI Validates Kernel Code

Hypervisor-Protected Code Integrity (HVCI) operates inside VTL1. When a kernel-mode driver or component requests execution in VTL0, the request is redirected to the secure environment:

1. Signature Verification: The code integrity module in VTL1 inspects the digital signature and certificates of the binary.
2. Policy Enforcement: VTL1 determines if the driver complies with strict Microsoft signing policies and security standards.
3. Execution Approval: Only after the integrity check passes does VTL1 grant permission for the memory pages to be marked as executable.

Hardware-Enforced Memory Protections (W^X)

HVCI enforces a strict security policy known as “Write XOR Execute” (W^X). Under this rule, a memory page in the kernel can be writable or executable, but never both simultaneously:

• Preventing Code Injection: If a page contains executable code, its write permissions are revoked by the hypervisor using Second Level Address Translation (SLAT) / Extended Page Tables (EPT).
• Preventing Data Execution: If a page is writable (such as standard data buffers), the hypervisor strips its execution privileges.

Because these memory page permissions are managed directly by the hypervisor at the hardware level, the standard kernel in VTL0 lacks the privilege to change its own page permissions from writable to executable.

Mitigation of Kernel-Level Exploits

In traditional operating systems, an attacker who obtains kernel-level privileges (Ring 0) gains complete control over the machine, allowing them to disable security software, patch kernel code, and inject malicious rootkits.

With hypervisor protections enabled in Windows 11, kernel-level compromise is severely contained. Even if an attacker achieves Ring 0 execution in VTL0, they cannot load unsigned drivers, tamper with existing executable memory, or bypass code integrity checks, because the enforcement authority resides entirely outside their reach in VTL1.