Protecting linear address translations with Hypervisor-enforced Paging Translation (HVPT)

Microsoft is committed to continually raising our security bar. Windows 11 and Windows Server 2025 are built with layers of defense, helping ensure we are secure by default and by design. Across the board, we have been innovating and integrating security into the fabric of the features we build, from chip-to-cloud, and it’s paid off: out-of-the-box security features in Windows 11 led to a reported 62% drop in security incidents¹. One of our latest silicon-assisted security features that went live recently is called Hypervisor-enforced Paging Translation (HVPT). HVPT is an innovative new feature that leverages the power of Windows Hyper-V to help protect guest virtual address (GVA) to guest physical address (GPA) translation with the goal of protecting against 2 page-table-targeted attacks, known as aliasing and remapping attacks. HVPT can help protect the root OS as well as guest VMs running atop it. In this blog, we will cover the attacks HVPT is designed to help protect against, and dive into how HVPT helps protects GVA to GPA translations.

Attacks on GVAs

Helping protect GVA to GPA translations provides massive security benefit by making GVA addresses tamper-proof. HVPT allows us to help protect critical system structures that make up some of our key security features like Kernel Data Protection, Shadow Stacks and Control Flow Guard. These features are hardened with HVPT, helping ensure that the protections can’t be bypassed by tampering with guest address translations, as we’ve seen attackers do. As mentioned, HVPT helps protect against remapping and aliasing attacks. Here's a brief explanation of how each of these attacks works.

Here is how a remapping attack can be carried out:

Fig 1: A remapping attack explained. An attacker tampers with the CR3-rooted page tables to remap a GVA to a target GPA where it has placed malicious content.

If the attacker exploits a write-what-where vulnerability and manages to write to memory, the attacker can then simply remap the GVA translation to point to the target GPA, by tampering with the CR3-rooted page tables. This attack can map protected software to point to malicious content, effectively changing the content of a GVA.

Another type of page table attack HVPT protects against is aliasing attacks. Here is what an aliasing attack looks like:

Fig 2: An aliasing attack explained. An attacker tampers with the CR3-rooted page tables to have a its GVA point to a target GPA.

In this attack, the CR3-rooted page tables are tampered with once again, to map a malicious GVA to an already-mapped GPA.

Introducing HVPT

Now that we understand the attacks that arise in the case of an unprotected GVA to GPA translation, let’s dive deeper into HVPT.

HVPT is really a collection of changes to the SLAT and OS, all working together to achieve the end goal of helping protect GVA to GPA translations:

Hypervisor-secured paging structures to disallow unauthorized modifications: HVPT adds brand new, secure-kernel-managed paging structures to the OS. These paging structures are physically mapped as read-only to the NT kernel but read/write to the secure kernel.

Fig 3: A diagram explaining the HVPT structures and how they are read-only to normal kernel mode, bur read-write to secure kernel.

Paging Write (PW) bit in the SLAT to allow processor A/D read/writes: The HVPT table is protected by the SLAT and marked read-only to the OS. However, to allow the CPU to be able to designate these pages as accessed/modified, there is a new bit called the “Paging Write” bit added to the SLAT, and set to 1 for page tables corresponding to HVPT structures. This allows for access/dirty bit writes for these structures.

Guest Paging Verification (GPV) bit in the SLAT to help validate secure page walks: To protect against aliasing attacks, we should enable the path taken to arrive at the final system physical address (SPA) was not tampered with. When the GPV bit is set for a GPA translation, the processor enables the paging structures used for the GVA to GPA translation have the PW bit set, signifying that the translation happened via the HVPT tables in SK. This is supported by Intel’s underlying HLAT feature, and will be supported by Windows in the future.

HLAT Prefix Size: The HLAT Prefix Size is a new field added to the Virtual Machine Control Structure (VMCS) that defines the range of addresses meant to be protected by HVPT. Checking the HLAT Prefix Size is the first step in the translation process. The HLAT Prefix Size acts as a filter to determine whether an address should be translated via HVPT- or CR3-rooted page tables.

HLAT Pointer (HLATP): The address of the HVPT paging structures is stored in a new field in the VMCS called the HLATP. This field is used to begin HVPT-based translations once an address is determined to be HVPT-protected via the PLR.

Restart bit: The HVPT paging structures include a restart bit. When this bit is encountered during a page-walk, the walk is stopped and restarted from the CR3-rooted page tables. This allows for performant translations in the case that an address is not fully translated via HVPT tables.

Let’s put all these pieces together and walk through how an HVPT address is translated and protected.

Fig 4: A diagram explaining how page translations happen with HVPT enabled. First, the address is checked against the PLR to determine if the address is protected with HVPT, in which case the translation starts in the HVPT tables (the address of which is stored in HLATP). Next, the translation of the GVA to GPA happens via the HVPT tables. The PW bit is set for each accessed HVPT PTE in the SLAT. The GPV bit is set on the SLAT PTE corresponding to the leaf-level HVPT PTE. If at any point in the walk a Restart bit is encountered, the walk aborts to restart at the CRW-rooted page tables.

HVPT helps eliminate remapping and aliasing attacks on GVAs. In both attacks, the attacker modifying the CR3 tables is ineffective, because the translation does not utilize those tables for HVPT-protected addresses, and the HVPT tables are protected by the hypervisor.

HVPT is a huge leap forward in securing the OS from exploits. We’re excited to add HVPT to the list of features making Windows secure-by-default.  

HVPT is live today and on-by-default on Windows 11 24H2 (host) and Windows Server 2025 (host). HVPT requires Intel Alderlake+ vPro-enabled hardware, and for VBS and HVCI to be enabled. We urge all customers and developers to update to the latest version of Windows and Windows Server to benefit from the enhanced security provided by HVPT.

If you want to learn more about HVPT, you can reference the following:

• Link to Intel’s blog on HLAT
• Hypervisor-enforced Paging Translation (HVPT)
• Windows Hyper-V
• Recon 2024 - Hypervisor-enforced Paging Translation - The end of non data-driven Kernel Exploits?
• Alder Lake and the new Intel Features – AaLl86 Security

References

1. Windows 11 security book - Windows security book introduction | Microsoft Learn

Securing the Present, Innovating for the Future

Security is a shared responsibility. Through collaboration across hardware and software ecosystems, we can build more resilient systems secure by design and by default, from Windows to the cloud, enabling trust at every layer of the digital experience.

The updated Windows Security book is available to help you understand how to stay secure with Windows. Learn more about Windows 11 and Copilot+ PCs.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

- The Core OS team