VBS, HVCI & isolation

Hyper-V & partitions described virtualization's original purpose: running separate guest operating systems. This chapter is about a very different, security-focused use of the exact same underlying hypervisor mechanism — Virtualization-Based Security (VBS) — where the "guest" being isolated isn't a separate OS at all, but a hardened portion of the very machine you're already using.

Isolation as a security primitive, not just a hosting mechanism

The hypervisor's core capability — creating isolated execution contexts that even a fully-compromised kernel above it can't directly reach into — turns out to be exactly the primitive needed to solve a hard, longstanding security problem: what do you do when the very thing supposed to protect your secrets (the kernel) might itself be compromised? VBS's answer: use the hypervisor to carve out an isolated environment — a separate VTL (Virtual Trust Level), running its own minimal, tightly-controlled "secure kernel" — that the ordinary, "normal world" Windows kernel cannot access, even with full kernel-mode privileges, because the hypervisor itself enforces that boundary from underneath.

Credential Guard: a concrete, motivating example

Credential Guard is the feature most people encounter this concept through: it moves the secrets LSASS would otherwise hold directly into this isolated, VTL-protected environment. The practical consequence: malware that achieves full SYSTEM-level, kernel-mode code execution on the "normal world" side — a level of compromise that would traditionally mean total, unrestricted access to everything on the machine, including whatever LSASS was holding — still cannot reach into the isolated secure world to extract those credentials, because the isolation boundary is enforced by the hypervisor, a layer beneath even kernel-mode code, not by anything the compromised kernel could itself be tricked into bypassing.

HVCI: restricting what kernel code is even allowed to exist

HVCI (Hypervisor-protected Code Integrity) tackles a related but distinct problem: rather than isolating secrets, it uses the hypervisor to enforce which kernel-mode code pages are allowed to be executable at all, checking code integrity in a way the hypervisor itself guarantees can't be tampered with by code running in the normal kernel — even a kernel exploit that would normally be able to patch memory or load unsigned code finds that avenue closed, because the hypervisor, not the kernel being attacked, is the one enforcing the policy.

The tradeoff this level's earlier chapters set up

This chapter directly builds on the prerequisite understanding from Hyper-V & partitions and Access tokens: VBS requires the same hardware virtualization support Hyper-V uses, and enabling it isn't free — some driver and software compatibility issues arise specifically because HVCI's stricter code-integrity enforcement rejects certain older, unsigned, or improperly-behaving kernel-mode code that would have run without complaint before. This is a genuine, explicit tradeoff: meaningfully stronger isolation against an entire class of otherwise-devastating kernel-level compromise, at some real cost to compatibility and a small amount of performance overhead from the additional virtualization layer always being active.

A common mistake

The name "Virtualization-Based Security" leads a lot of people to assume it means "your desktop is running inside a VM" — the same misreading Virtualization already flagged for Hyper-V generally. VBS specifically does not mean your everyday Windows session is a guest operating system; it means the hypervisor is being used to carve out a small, additional, isolated environment alongside your ordinary, still-natively-running Windows session, specifically to hold secrets and enforce policy that even a fully compromised normal-world kernel can't touch.

Where this connects

• LSASS, SAM, and local security policy is exactly what Credential Guard is protecting when VBS is enabled.
• Kernel mechanisms covers the IRQL and execution-context rules HVCI's code-integrity enforcement operates alongside, inside the normal-world kernel it's protecting.