HVCI

Hypervisor-Enforced Code Integrity (Memory Integrity): a Virtualization-Based Security (VBS) feature where the Secure Kernel (VTL1) and hypervisor EPT/SLAT enforce that kernel pages are not simultaneously writable and executable without re-validation. VBS splits the machine into VTL0 (normal Windows kernel + user mode) and VTL1 (Secure Kernel + policy enforcement) via the Windows hypervisor; HVCI is the memory-protection bucket within that stack. Distinguish VBS/HVCI capability, configuration, and running state — compatibility evidence does not prove every driver interface or data operation is safe.

Enforcement model

• W→X transition restriction: enforced code pages are not intended to stay writable from VTL0; executability is granted only after configured code-integrity checks pass.
• Pipeline: CI policy defines trust → hypervisor second-stage translation (EPT/SLAT) → strict execution rules on validated kernel pages. Kernel-mode CI.dll API research such as [[ci-dll-demo]] (Ido-Moshe-Github; process-creation notify hook; CiValidateFileObject / CiCheckSignedFile; Authenticode certificate extraction from returned policy data) helps study the same validation pipeline Memory Integrity relies on.
• Driver requirement: drivers must be HVCI-compatible (no self-modifying kernel code paths that violate W→X). HVCI-oriented research platforms such as [[goodmans-kernel]] (signed WDM driver embedding wasm3 to hot-load unsigned wasm32 modules without per-iteration driver rebuild; SEH-guarded kernel memory access; zer0condition) illustrate updatable kernel logic under Memory Integrity constraints. User-mode kernel invocation research such as [[kernel-forge]] (Cr4sh; signed-driver-wrapper primitives + higher-level kernel function calls on VBS/HVCI hosts; kernel-to-user DLL injection demo; exploit-prototyping under Memory Integrity; README [Hijack ROP]) illustrates calling kernel routines without classic unsigned code-mapping paths.

Game-security role

Raises the cost of classic kernel code patches and some [[byovd]] patterns; baseline assumption alongside Secure Boot/TPM in serious AC and [[dma]] threat models. Does not stop pure external DMA by itself—IOMMU/attestation still required. Research framed as HVCI bypass via PFN swapping (call arbitrary kernel functions from user mode) appears in [[bustercall]]. Local runtime integrity inspection on VBS/HVCI hosts via GetRuntimeAttestationReport appears in [[windows-runtime-attestation-report]] (CodeMaxx; signed driver + kernel hotpatch Runtime Report Packages; no remote attestation).

Early-boot / native-subsystem research such as [[bootbypass]] targets DSE and Memory Integrity together via boot-manager checks, CI.dll validation, and SeCiCallbacks patching (subsystem:native).

Operator tooling such as [[solemn]] automates adding drivers to the HVCI HvciDisallowedImages custom blocklist (Windows Security Features / Ring3 research lane).

LOLdriver / vulnerable-driver inventory checks under HVCI appear in PowerShell research such as [[hvci-loldrivers-check]] (Trail of Bits; cheat / vulnerable-driver lane). [[byovdfinder]] (ghostbyt3; identifies LOLdrivers not blocked by the active HVCI policy—BYOVD attack-path research under Memory Integrity) targets the same policy-gap inventory lane. General LOLdriver scan clients such as [[loldrivers-client]] (Go/PowerShell) cover the same inventory lane without an HVCI-specific framing.

WDAC policy build/deploy tooling such as [[wdactools]] (PowerShell; base/supplemental CI policies, UMCI/WHQL/audit options, CIPolicyParser, CiTool.exe) helps study the user-mode side of the same code-integrity trust pipeline [[hvci]] enforces at the hypervisor. Community WDAC driver blocklist policy data such as [[code-integrity-driverblocklist]] (Harvester57; XML deny rules by hash and driver identity, including anti-cheat-relevant kernel modules; defensive hardening consumable by WDAC tooling) complements [[msft-driverblocklist]] in that lane.

HVCI bypass PoCs such as [[zero-hvci]] (gmh5225; policy edge cases + vulnerable signed-driver primitives → unsigned kernel code under Memory Integrity) sit in the same kernel trust-feature research lane.

VBS enclave abuse PoCs such as [[fake-enclave]] (gmh5225; proof-of-concept misusing Enclave isolation within the VBS stack) complement HVCI bypass work when studying virtualization-based security limitations. Defensive enclave game-logic isolation PoCs such as [[secure-game]] (SamuelTulach; Pong-like sample; host app for render/input + enclave DLL for state/rules; SDL2; trusted execution / anti-cheat research) illustrate isolating sensitive gameplay from usermode tampering within the same VBS stack.

Lab teardown guides such as [[disabling-hyper-v]] (gmh5225; Win10; Microsoft's Device Guard and Credential Guard hardware readiness tool → disable HVCI, Device Guard, Credential Guard, and related VBS so Hyper-V can be fully removed—not an in-place bypass) document the configuration side of turning Memory Integrity off for research hosts.

Hypervisor enforcement boundary

A trusted hypervisor can enforce a separate guest-memory protection boundary; Windows VBS/KDP is one concrete architecture. Protecting selected data differs from validating kernel code, authenticating an administrative request, or preserving a detector's end-to-end coverage. For a vulnerable-driver threat, first establish driver presence, reachable interface, and required privilege; a claim that attempted kernel tampering was blocked additionally requires the evidence below. Guest-kernel compromise does not automatically defeat an independently enforced boundary — but that assumes the hypervisor, hardware, and configuration path remain trustworthy.

Review question	Evidence required
What is covered?	Exact protected memory, active mappings, access class and lifecycle
Who owns the policy?	Hypervisor/security-component provenance and authority to change mappings
Was an access observed?	Fault/exit context, collection coverage, mapping and execution correlation
Was the operation prevented?	Enforced decision and resulting state — an exit alone does not establish denial
What remains outside scope?	Unprotected aliases, permitted update paths, device DMA, firmware gaps

WHP user-mode APIs manage guest partitions without granting arbitrary host-kernel control — capabilities, exit contexts, and architecture support are build- and configuration-dependent; correlate the actual exit reason with the analysis question.

HVCI/kCET-aware kernel exception research such as [[bugcheck-suppressor]] (XaFF-XaFF; data-only HAL dispatch hook + bugcheck-callback interception + SEH RtlUnwindEx recovery; CET-compatible assembly stubs; BSOD suppression PoC) probes how Memory Integrity and shadow-stack enforcement interact with bugcheck handling—not a bypass of W→X policy itself.

Related

[[driver-trust-boundaries]] · [[patchguard]] · [[byovd]] · [[iommu]] · [[bustercall]] · [[bootbypass]] · [[zero-hvci]] · [[kernel-forge]] · [[fake-enclave]] · [[secure-game]] · [[disabling-hyper-v]] · [[solemn]] · [[wdactools]] · [[code-integrity-driverblocklist]] · [[msft-driverblocklist]] · [[hvci-loldrivers-check]] · [[byovdfinder]] · [[loldrivers-client]] · [[goodmans-kernel]] · [[bugcheck-suppressor]] · [[ci-dll-demo]] · [[windows-runtime-attestation-report]] · [[overviews/windows-kernel]] · [[overviews/anti-cheat]]