The security boundary VBS is meant to enforce
Download More RAM is easier to understand once the Windows boundary it targets is made explicit. The focus here is not a tour of Windows security features, but the division of responsibility among the ordinary kernel, Hyper-V, the Secure Kernel, HVCI, and protected processes. That division lets us judge what a local administrator normally cannot do—and why the guarantee still depends on hardware, firmware, and boot information supplied from below.
The key distinction is between policing a component and isolating it from the component being policed. Windows has long used the first strategy. VBS adds the second. The difference explains both the strength of the design and the importance of a memory address map that everyone agrees is real.
From kernel self-protection to a separate trust domain
Driver Signature Enforcement and PatchGuard are useful examples of kernel-local defense. Driver Signature Enforcement requires kernel-mode drivers to carry the required Microsoft signature. PatchGuard attempts to detect changes to critical kernel structures and code. Both make common attacks harder and raise the cost of tampering. But the ordinary kernel is also the environment in which these controls operate. If an attacker already has comparable kernel privilege, the controls are trying to defend the kernel from an actor who is close to the authority that enforces them.
That is a structural limitation, not a claim that the controls are pointless. A gate inside a building can keep ordinary visitors out. It is a weaker boundary against someone who already controls the building’s security desk. Windows needed a place where the most sensitive decisions could be made outside the ordinary kernel’s direct authority.
Hyper-V supplies that separation. It is Microsoft’s native type-1 hypervisor: it operates directly on the hardware and manages virtualized partitions beneath the main operating system. On a VBS-enabled system, the familiar Windows environment is placed in Virtual Trust Level 0, or VTL0. VTL0 contains the user-facing system and the normal Windows kernel. A separate VTL1 contains the Secure Kernel and Isolated User Mode. The hypervisor mediates the relationship between the two levels.
The ownership question is more important than the labels. VTL0 owns ordinary application and kernel execution. VTL1 owns security decisions that must remain authoritative even when VTL0 is compromised. Hyper-V owns the separation between those environments. The normal kernel can ask for operations that affect protected state, but it is not supposed to redefine the rules under which VTL1 grants them. That is why VBS is described as a root of trust for an operating system that assumes its kernel may be compromised.
HVCI, also called memory integrity or hypervisor-enforced code integrity, is a major consumer of this arrangement. A driver request begins in the ordinary Windows environment, but the decision about whether the image is trusted is enforced from the protected side. The Secure Kernel checks driver layout and integrity, verifies the relevant signing information, and consults the vulnerable-driver blocklist. The blocklist matters because a signature answers only who authorized a driver, not whether the driver contains a vulnerability that an attacker can turn into arbitrary access.
HVCI also changes who controls memory permissions. Microsoft’s documentation describes kernel-mode code being checked before it starts, executable pages being created only after those checks, and executable pages not being writable. The paper explains the same design as a write-or-execute separation in which the ordinary kernel no longer has the authority to make arbitrary pages executable. If a buffer-overflow exploit modifies an existing executable page, the desired path to persistent code execution is supposed to be closed: code pages cannot simply be changed and then made executable by the compromised kernel.
This produces a chain of authority. The ordinary kernel presents a driver or code page for evaluation. The Secure Kernel decides whether the code is acceptable and whether its memory attributes are legal. HVCI’s value comes from the fact that the decision is made in a different protection domain. If a driver is rejected, VTL0 is not meant to be able to overrule VTL1 by editing the same decision procedure.
Protected processes illustrate the same principle at the process level. Process Protection Light, or PPL, assigns protection levels that govern which processes may read, write, or terminate another process. An administrator running an ordinary process is not automatically allowed to stop a PPL-protected anti-malware or EDR process. The protection can be reinforced by a second authentication path, such as a management-controlled tamper-protection credential. In a managed Windows deployment, this means administrator access and total control are intentionally different states.
That distinction is easy to lose in everyday descriptions of “admin rights.” An administrator can configure many parts of Windows, but PPL and VBS exist because some resources are meant to remain outside that account’s authority. Download More RAM is significant precisely because the paper does not simply show an administrator using a documented control to switch these protections off. It asks whether an administrator can reach the memory in which those protections—and the state they protect—actually reside.
The design also makes the role of a signed driver more subtle than a simple trusted-or-untrusted label. A driver can be legitimately signed and still be vulnerable to abuse; that is why HVCI’s policy includes reputation and revocation information in addition to signature validity. The Secure Kernel is the owner of the decision to admit or reject the image, while the normal kernel is the requester and loader. If the requester could rewrite the decision logic, the separation would become ceremonial even though the driver still passed through the expected loading path. Download More RAM later focuses on exactly this relationship, but the architecture already tells us why the relationship matters: code integrity is only a boundary when its authority is outside the code it evaluates.
The same reasoning applies to PPL. It does not promise that a protected process is invulnerable to every fault in the platform. It says that ordinary process operations are evaluated against a protection hierarchy, so a lower-protection caller cannot simply issue a termination or write request and expect it to succeed. The hierarchy is meaningful while the kernel and protected services can trust the memory and control paths implementing it. A lower-layer error can therefore leave the visible policy enabled while undermining the state on which the policy depends.
The diagram shows why VBS is more than a collection of settings. Hyper-V owns the partition boundary, VTL1 owns the protected decision, and VTL0 contains the system that may be compromised. PPL then applies a related authority model to selected processes. The design is coherent as long as the layers agree about the resources being protected and no lower layer silently changes that agreement.
The boundary starts before Windows boots
That last condition is supplied by the platform. Microsoft’s VBS guidance does not describe VBS as a Windows-only switch. It calls for a 64-bit processor with hardware virtualization extensions and Second Level Address Translation, or SLAT. Those capabilities allow Hyper-V to manage the mappings used by virtualized partitions rather than relying on ordinary software conventions alone.
The platform also needs an IOMMU or SMMU for devices capable of direct memory access. DMA-capable hardware can otherwise interact with memory through a path that does not look like an ordinary user or kernel load. The requirement does not mean every memory threat is solved by an IOMMU; it shows that VBS’s security story includes access paths outside the CPU’s normal page-table flow.
Firmware contributes several more invariants. Secure Boot is part of the documented platform requirements. Trusted Platform Module 2.0 support is required. System firmware must follow hardening recommendations for System Management Mode, and UEFI must report runtime memory in a way that lets the OS apply the intended protections. Microsoft’s Memory Attributes Table guidance requires runtime code and data to be separated, aligned, and reported with attributes such as read-only or execute-prohibited. A writable and executable region is not supposed to be left ambiguous. Secure Memory Overwrite Request revision 2 adds another firmware-level protection for a setting involved in memory handling. Drivers must also be tested for compatibility with memory integrity, because static inspection alone cannot reveal every runtime violation.
These requirements have different owners, but they serve a common purpose: each layer must provide an input that the next layer can safely rely on. The processor supplies virtualization capabilities. Firmware reports memory and its attributes. Secure Boot constrains the boot environment. Drivers operate within the rules exposed by the protected runtime. Windows then builds VBS policy on top of those inputs.
The chain can be stated as a simple conditional. If the platform reports a particular physical memory range, Windows can assign permissions and trust relationships to that range. If the firmware reports that an executable region is read-only, VBS can preserve that property. If a driver image is presented to the Secure Kernel, HVCI can decide whether it meets the code-integrity policy. But these checks are meaningful only if the thing being described remains the same thing when the lower layers act on it.
This is where Download More RAM finds its opening. SPD, the Serial Presence Detect data stored on a memory module, is normally understood as configuration information: capacity, memory type, frequency, voltage, and related geometry. Yet that information influences how the memory controller interprets addresses during platform initialization. A false SPD description does not merely make a label inaccurate. It can cause the hardware to construct a physical address map that differs from the module’s actual storage.
VBS does not ordinarily own that construction. Hyper-V can isolate VTL0 from VTL1, but it receives a platform memory map rather than independently proving that every physical address corresponds to a unique set of cells. The memory-management unit can enforce page permissions on the map it is given. HVCI can enforce that executable pages are not writable within that map. PPL can prevent a lower-protection process from terminating a protected service. None of these facts, taken alone, verifies that a second physical address cannot reach the cells assigned to the first.
That does not weaken the normal VBS model. It identifies its starting premise. Isolation is a relationship among execution domains, memory mappings, and the hardware that gives those mappings meaning. The higher layer can be operating exactly as designed while a lower layer supplies an identity error that the higher layer was never designed to correct.
There are legitimate variations in how VBS is deployed. Microsoft documents support for virtual machines through nested virtualization or Guest VSM, and hardware and firmware capabilities differ across systems. Those variations make a careful threat model more important, not less. “VBS is enabled” establishes that a policy is requested and supported; it does not by itself prove that every prerequisite, memory-reporting rule, or protection interface is identical on every endpoint.
The lesson is therefore not that the Windows security stack has no value. Its layers are valuable because they make the ordinary administrator, application, and compromised-kernel paths distinct. The lesson is that a security boundary cannot authenticate an object whose identity it simply inherits. Download More RAM tests that inheritance by changing the address map underneath the hypervisor. The next question is how a memory module’s configuration can create two physical names for one region—and why the resulting deception is more consequential than a bad capacity reading.