SimpleSvm

SimpleSvm is an educational Windows kernel-mode hypervisor project for AMD CPUs with SVM support. It is intended to help understand how a minimal hypervisor works on Windows, including VMCB setup, nested paging (NPT), #VMEXIT handling, and low-level host/guest transitions in ring 0.

This repository is based on the original educational code by Satoshi Tanda, and this version includes a stability-focused audit and hardening pass. The goal is not to produce a production runtime, but to provide a practical reference for kernel-mode virtualization, x64 internals, Windows driver development, and system-level experimentation in a controlled lab environment.

Why this project exists

The project is useful for learning:

• how a hypervisor is initialized on Windows,
• how the AMD SVM interface is used,
• how MSR, CPUID, GDTR, IDTR, and related hardware state are manipulated,
• how a VMCB is built and configured,
• how nested paging (NPT) maps guest addresses to host memory,
• how #VMEXIT events are intercepted and handled,
• and how system calls and kernel shared data can be instrumented in a lab setting.

It is meant for technical study, reverse engineering research, and authorized experimentation. It is not intended as a general-purpose or production-ready hypervisor.

Legal and safety notes

This code is distributed for research and educational purposes only.

It is not intended for:

• bypassing anti-cheat, DRM, or protection systems,
• tampering with third-party software,
• or performing activities outside an authorized and controlled environment.

The project should be used only on hardware and systems where you have explicit permission to test and study. Kernel-mode virtualization is dangerous, can cause system instability, and must be handled with extreme care.

Project scope and architecture

Core idea

The driver validates AMD hardware, enables EFER.SVME, initializes per-CPU virtualization state, creates a nested paging map, and then manipulates the guest and host transitions through #VMEXIT behavior. The code is intentionally small and readable so that the virtualization flow is understandable.

Main files

• SimpleSvm/SimpleSvm.cpp

  • Main driver logic.
  • Covers CPU validation, VMCB setup, #VMEXIT routing, guest configuration, cleanup, and the stability-oriented fixes.

• SimpleSvm/x64.asm

  • Assembly code for VM launch, stack setup, syscall interception, and transitions between host and guest execution contexts.

• SimpleSvm/SimpleSvm.hpp

  • AMD-specific structures, VMCB definitions, paging layouts, segment descriptors, and other low-level support types.

• SimpleSvm/SimpleSvm.vcxproj

  • Visual Studio project for the Windows driver build.

• SimpleSvm.sln

  • Solution entry point for building the project.

• LICENSE

  • MIT license for the repository.

Requirements

This project is designed for a very specific environment:

• Windows x64
• AMD processor with SVM support
• Nested Page Tables (NPT) support
• Windows Driver Kit (WDK)
• Visual Studio with driver development tools
• BIOS/UEFI with SVM enabled
• A controlled lab or kernel-debug environment
• Advanced knowledge of Windows internals, x64, and virtualization

This is not a user-mode project. It is a kernel driver and requires careful handling of memory, IRQL, exceptions, and race conditions.

Build instructions

1. Open SimpleSvm.sln in Visual Studio.
2. Install and configure the relevant Windows WDK and driver development components.
3. Select the x64 target configuration (Debug or Release).
4. Build the solution.
5. Only load or test the driver in a controlled and authorized environment.

How it works internally

1. Hardware validation

The driver checks whether the CPU is AMD and verifies that SVM and NPT are available. The validation is done through CPUID and model-specific register reads, and the driver rejects unsupported configurations.

2. VMCB preparation

The project creates a VMCB per logical processor with guest state, segment selectors, control registers, RSP, RIP, RFLAGS, and the interception settings needed for the test environment.

3. Nested paging

NPT is configured to manage guest physical-to-host physical translation. This allows the hypervisor to control memory visibility and guest addressing in a controlled way.

4. #VMEXIT handling

When guest execution triggers a VM exit, the hypervisor examines the exit reason and decides whether to emulate behavior, modify VMCB state, inject an exception, or abort the VM.

Typical exit cases include CPUID, MSR access, GDTR/IDTR access, and faults or exceptions that require host intervention.

5. Syscall and KUSER_SHARED_DATA handling

The code includes a syscall hook and KUSER spoofing logic used to redirect or observe certain system paths. This is a representative low-level technique that demonstrates how a hypervisor can intercept or reshape the execution environment, but it is only suitable for research and tightly controlled testing.

6. Driver lifecycle and cleanup

The driver installs power-state handling and uses explicit teardown paths to free resources and avoid stale state during unload or shutdown. Stability work in this repository makes these paths safer and more resilient.

Stability audit and hardening pass

This repository includes a practical hardening pass on the original educational base. The work focuses on real kernel-mode failures that turn a demo into a BSOD-prone system under realistic load.

The improvements are intentionally documented in the code and relate to the basic rule that in kernel mode, every allocation can fail, every pointer can be NULL, every reference count can leak, and every race can eventually happen.

Critical BSOD-causing issues addressed

The most serious issues fixed include:

• Use-after-free on EPROCESS during process exit and background setup.
• MmProbeAndLockPages being called with a NULL MDL after failed allocation.
• Exception escapes from MmProbeAndLockPages without a kernel-mode SEH guard.
• KeWaitForSingleObject being called with a NULL object on driver unload.
• A sysretq race where the indirect target pointer could become NULL between validation and execution.
• A sysretq validation problem where a kernel-mode or invalid address could be used as the return target.

These are exactly the kind of problems that do not show up in a happy-path demo but become guaranteed crashes under real-world conditions.

Memory leak fixes

The code also fixes several resource leaks, including:

• MDL and locked-page leaks when mapping a KUSER page fails,
• stale EPROCESS references not released in cleanup paths,
• thread exit paths that skipped cleanup after a failed setup routine.

These are especially important because kernel leaks are resilient and often survive until reboot.

Correctness and cleanup fixes

Additional fixes include:

• correcting a bad copy of BaselineInterruptTimeQpc from the wrong source,
• eliminating a hardcoded NtSystemRoot string in favor of the real KUSER_SHARED_DATA value,
• cleaning up duplicated or dead code that was never reached in practice,
• adding explicit compiler barriers in critical points to avoid incorrect memory ordering assumptions.

Performance / hot-path notes

A few hot-path optimizations were also considered:

• fast-fail checks for g_Ready,
• avoiding expensive operations when readiness is false,
• removing dead IRQL manipulation code from VMEXIT handling.

The gains are modest, but when combined with the safety fixes they improve both correctness and maintainability without turning the project into a fragile demo.

File-level structure

SimpleSvm.cpp

This is the central logic file. It defines:

• driver entry and lifecycle,
• verification of SVM/NPT support,
• VMCB and memory setup,
• #VMEXIT dispatch,
• process tracking and KUSER spoofing,
• cleanup paths and hardening checks.

x64.asm

This contains the low-level assembly needed to:

• launch the guest environment,
• install and maintain the syscall hook,
• switch execution context between host and guest,
• perform the required stack and register manipulations for virtualization.

SimpleSvm.hpp

This holds the foundational low-level definitions:

• paging structures,
• bit masks,
• AMD SVM details,
• segment descriptors,
• and other shared constants required by the driver.

Limitations

• Only relevant on AMD systems with SVM and NPT support.
• Not a standard user-mode application.
• Requires deep knowledge of kernel programming, x64, Windows internals, and virtualization.
• Requires a highly controlled environment and explicit permissions.
• Not suitable for production systems or general-purpose use.

License

This project is released under the MIT license. See LICENSE for details.

Summary

SimpleSvm is a minimal but educational Windows hypervisor implementation for AMD SVM hardware. The original code shows the core mechanics of virtualization, while this hardened variant makes the project safer, more resilient, and easier to reason about in the real world.

In short:

• original purpose: learn how SVM works,
• updated purpose: learn how to make a low-level virtualization project survive realistic kernel failures,
• current status: research and lab code, not production software.

This repository is best treated as a technical study project for engineers and researchers working in authorized, controlled environments.