When “protected memory” has two addresses
Download More RAM is a research attack against Windows 11’s assumption that a protected physical memory map is a trustworthy foundation. The specific question is how a local administrator, without physically opening the machine or already controlling the kernel, could make two reported addresses reach the same memory cells—and what that would mean for Virtualization-Based Security (VBS). Understanding that distinction gives the reader a way to judge both the paper’s seriousness and its limits: this is not an unprivileged remote exploit, but it is also not a routine administrator action that Windows’ strongest defenses are supposed to make harmless.
The paper by Sam Collins and colleagues, published for the 35th USENIX Security Symposium, calls the technique Download More RAM because the first deception is simple to state. A memory module can be made to report more capacity than it physically contains. The operating system then receives an address map that appears larger than the available cells. The extra addresses are not new storage. They are aliases: alternate names that resolve to locations already represented in the lower part of memory. Once that mismatch exists, protections applied to one view of memory may not govern every other way of reaching the same cells.
That is the central tension of this series. VBS is designed to protect security-critical code and data even when the ordinary Windows kernel is compromised. Download More RAM asks what happens when the layer below that boundary changes the identity of memory itself.
The promise at the top
Windows security is often described as a stack of increasingly strong controls. At the ordinary operating-system level, Driver Signature Enforcement requires kernel-mode drivers to be signed, and PatchGuard tries to prevent modification of critical kernel structures and code. Those measures are important, but they operate close to the kernel whose behavior they are trying to police. An attacker who reaches comparable kernel privilege is already operating near the authority that enforces them.
VBS is meant to solve that problem by moving the most important checks into a separate environment. Hyper-V runs the normal Windows system in Virtual Trust Level 0, or VTL0. A separate VTL1 contains the Secure Kernel and Isolated User Mode. The hypervisor mediates the relationship between them, creating a boundary that the ordinary kernel is not supposed to cross. Microsoft describes this isolated environment as a root of trust for an operating system that assumes its kernel may be compromised.
Several protections depend on that arrangement. Hypervisor-enforced code integrity, commonly called HVCI or memory integrity, checks kernel-mode drivers and binaries in the protected environment. It enforces a write-or-execute separation: code pages must pass integrity checks before becoming executable, and executable pages cannot simply be made writable by the ordinary kernel. HVCI also uses a blocklist of known vulnerable drivers, because a legitimate signature does not guarantee that a driver is safe. Process Protection Light, or PPL, applies a related idea to selected processes. Anti-malware and EDR processes can reject read, write, or termination requests from less-protected processes, including ordinary administrators.
The intended relationship is therefore straightforward. A compromised application should not reach the kernel. A compromised kernel should not reach the Secure Kernel. A normal administrator should not be able to terminate a protected anti-malware service. And a signed but dangerous driver should remain blocked. Download More RAM matters because it does not begin by asking one of those controls to make an obviously bad decision. It attacks the shared physical substrate on which the decisions depend.
A boundary built from several layers
The VBS boundary is not created by Windows alone. Microsoft’s platform guidance lists requirements that span the processor, memory translation, firmware, boot process, and drivers. A supported system needs hardware virtualization and Second Level Address Translation, protection for DMA-capable devices through an IOMMU or SMMU, TPM 2.0, hardened firmware behavior, correct UEFI memory reporting, compatible drivers, and Secure Boot. These requirements are not administrative decoration. They are the conditions under which Windows can trust the platform it is isolating.
A useful way to see the dependency is to follow an address downward. A program uses a virtual address. Windows’ memory-management machinery translates that into a physical address, and the hypervisor helps decide which security domain may use the resulting page. The memory controller then interprets the physical address as a set of ranks, banks, rows, and columns on a DIMM. At the bottom, electrical storage cells hold the actual bits.
Each layer can enforce a rule about the representation it receives. VBS can restrict VTL0’s access to VTL1. HVCI can reject a driver whose image fails the checks performed by the Secure Kernel. The memory-management unit can enforce page permissions. None of those mechanisms, by themselves, establishes that every physical address value names a unique physical location. That uniqueness is inherited from the hardware configuration and the address-decoding logic beneath the operating system.
This is why the paper’s use of the term “memory aliasing” is more precise than a general warning about faulty RAM. In a conventional memory-safety bug, an attacker writes through a pointer to an unintended location. In an aliasing failure, the pointer may be perfectly valid according to the software’s map; the problem is that the map contains two valid names for one underlying location. A permission attached to one name can be sidestepped by using the other. The security boundary has not necessarily miscomputed a page permission. It has lost control of what the page’s physical destination means.
The diagram’s important edge is the dashed one. The software-induced alias enters below the VBS boundary, at the point where the platform turns configuration data into a physical address map. That does not mean the hypervisor is irrelevant. It means the hypervisor is enforcing isolation over a representation that has already become misleading.
What Download More RAM actually assumes
The attack model is deliberately strong in one respect and restrained in others. The attacker has local administrator privileges on a Windows 11 system with Secure Boot, Driver Signature Enforcement, PatchGuard, VBS, and HVCI enabled. The target DIMM does not have effective SPD write protection. SPD—the Serial Presence Detect data stored on a module—describes configuration such as capacity and memory geometry. On the affected modules, the authors found a way to change that information from software through the platform’s memory-management bus. The resulting configuration makes the module report roughly twice its physical capacity, with the upper reported range aliasing the lower one.
The attacker does not begin with physical access, a firmware-reflashing capability, or a previously discovered vulnerability in the Windows kernel, an installed driver, or a third-party component. That is the paper’s important reduction in assumptions compared with earlier memory-aliasing work. But the reduction should not be mistaken for no assumptions. The attacker still needs an administrator foothold and a module whose configuration can be rewritten. A DIMM with the relevant SPD blocks protected would stop the demonstrated software-only starting point; the authors found that even partial protection was sufficient in their testing.
The first consequence is not a clean privilege escalation. An operating system that believes the module has more memory may allocate into the upper range, and accesses there can overwrite data in the lower range. The researchers found that aliased configurations were unstable during boot, often producing crashes or the Windows equivalent of a kernel panic. Their chain therefore had to keep Windows from using the upper range while leaving that range physically present. Only after that staging problem did they develop ways to read and write portions of the memory that Windows considered unavailable.
That distinction matters for judging the paper. “A false map exists” is not the same claim as “the attacker immediately owns the secure kernel.” The demonstrated chain advances through separate reliability and access problems. It eventually uses a limited write to weaken code-integrity checks and admit a previously blocked vulnerable driver; that driver then provides a more reliable route to broad physical-memory access. Later parts of this series examine why that escalation works and what the authors reached with it. Here, the essential point is narrower: the visible VBS controls sit above an address-identity assumption they do not create and cannot independently repair.
The practical question
The stakes extend beyond one Windows component. If the lower layer can expose or modify memory that the ordinary kernel is not supposed to see, the affected assets may include the Secure Kernel, Hyper-V-managed state, HVCI’s code-integrity machinery, and processes protected by PPL. Third-party endpoint security, anti-cheat systems, and enterprise policy can inherit the same weakness when they rely on those Windows guarantees. That does not make every product equally vulnerable, and it does not erase the paper’s platform and privilege conditions. It does show why a local administrator is not always the end of the threat model in a managed Windows environment: policy can constrain an administrator only while the mechanisms enforcing the policy remain authoritative.
The useful question is therefore not simply whether VBS is enabled. It is whether the full chain that VBS relies on—hardware configuration, firmware reporting, physical-memory interfaces, the hypervisor, and code-integrity authority—preserves the identity of the resources it protects. Download More RAM’s contribution is to show, on a class of consumer systems, how that chain can fail from below. The next step is to examine the boundary as Windows intends it to work: which layer owns which protection, and what must remain true before any memory alias is possible.