Anti-Cheat Software Spies on Players. This Architecture Stops That.
When you install a competitive game like Valorant or Fortnite, you also install kernel-level anti-cheat software. Riot Vanguard, Easy Anti-Cheat, BattlEye, and FACEIT all require a driver running at ring-0, the most privileged level of your operating system. This driver can monitor everything on your machine: other processes, loaded drivers, input devices, display contents. The trade-off is obvious to anyone who thinks about it for a moment. You're giving closed-source, developer-controlled code total access to your personal computer to prevent someone from cheating in a video game.
The gaming industry treats this as a settled question. Kernel-level anti-cheats work, so players should accept the privacy cost. But the cost is real. These systems have been caught collecting telemetry far beyond gameplay. Some have shipped rootkit-like behavior, concealing their presence and resisting inspection or removal while retaining broad capabilities for remote access and data collection. And they don't even solve the security problem they claim to address: a sophisticated attacker can bypass kernel anti-cheat by exploiting vulnerabilities in the kernel itself or in signed device drivers.
Santosh Gokul Narayanan, Giovanni Paladino, Chuqi Zhang, Sangho Lee, Zhenkai Liang, and Adil Ahmad propose a different approach. Their system, Tirith, eliminates the need for developer-controlled kernel drivers entirely by running games inside hardware-isolated virtual machines, while keeping cheating detection just as effective and performance just as good. It was published at ACM CCS 2026.
Why the Process Abstraction Fails Games
The core problem is that the process abstraction, which works fine for normal applications, is fundamentally wrong for competitive games. When you run a web browser or text editor, the operating system assumes you're a trusted user. You own the machine, you have root, and the software cooperates with you. But in a competitive game, the player is the adversary. The player has root access, technical skills, and a financial or reputational incentive to cheat. Running the game in a regular process gives the player total control over the game's memory, code, and execution environment.
Kernel-level anti-cheats try to solve this by placing a monitor at a higher privilege level than the player. The anti-cheat driver loads at boot, blocks unsigned kernel modules, prevents debuggers from attaching to the game process, and monitors system behavior for cheating signals. But this creates a paradox: the player must trust the developer's unverifiable code with ring-0 access to their entire machine, and the developer must trust that their anti-cheat driver is more resilient than the kernel vulnerabilities a sophisticated attacker can exploit.
The authors frame this as a split trust problem. The player doesn't trust the developer's code, and the developer doesn't trust the player. The current solution asks one side to accept total risk. Tirith proposes a third party: the OS vendor's hypervisor, which both sides already trust.
Protected Virtual Machines as the Foundation
Tirith runs each game inside a Protected Virtual Machine (PVM), a hardware-isolated guest environment provisioned by the OS vendor's first-party hypervisor. Modern commodity platforms already support this: Protected KVM on Linux and Android, Virtualization-Based Security (VBS) on Windows. The PVM hypervisor is launched before the host OS through secure boot, becomes permanently resident, and cannot be disabled or bypassed by software running on top, including a player with root access.
This gives you two-way isolation. The game and the developer's anti-cheat code run inside the PVM with full kernel-level privileges over the game environment, but they cannot read host memory, spy on unrelated applications, capture screen contents, or persist on the machine after a session ends. The player, operating on the host, cannot inspect or tamper with the guest's CPU state, memory, or devices. The hypervisor is the trusted computing base that mediates between them.
The key insight is that the hypervisor already implements the system-level enforcement that kernel anti-cheats provide. It handles boot integrity, driver verification, anti-debugging, device isolation, and remote attestation. These are generic platform security features, not game-specific logic. The developer simply attests to these features when a player wants to start a game session. Game-specific enforcement, like memory scanning and binary integrity checking, stays inside the guest where the developer has full control.
The Two Problems with Running Games in VMs
The idea is elegant, but the authors found that existing virtualization software stacks can't actually run games well. They conducted a case study using muvm, a lightweight gaming-focused VM on Linux, and discovered two fundamental problems.
First, running a full Linux kernel inside the guest VM is both resource-intensive and a security liability. The guest Linux spins up background services, system daemons, and auxiliary processes that aren't needed for gaming. In their tests, CPU utilization increased by 4.9x and the system consumed about 600 MiB of additional memory. More concerning, a full Linux kernel exposes roughly 911 interfaces between the guest and the hypervisor, making it extremely difficult to reason about isolation guarantees.
Second, GPU paravirtualization through virtio is too slow for games. The standard approach requires each batch of graphics commands to cross the guest-host boundary: an MMIO write triggers a VM exit, the hypervisor dispatches to the host backend, the command payload is copied through a shared ring, and an interrupt injection returns the result. VirGL adds per-call encoding on the guest and decoding on the host. In their measurements, the graphics pipeline was up to 82.9 times slower than native execution. The result was 1.4 to 13.3 times fewer frames per second than running the game natively, well below what competitive gaming tolerates.
A Stripped-Down Kernel for Games
Tirith's first design contribution is a minimized Library OS kernel that replaces the full Linux guest. Built on Gramine, the kernel contains only what games need: system call handlers, scheduling, memory management, and a virtual device subsystem with four devices.
The virtual DRM device handles graphics. The event device handles input. The sound device handles audio. The platform device handles host state attestation, which lets the in-guest anti-cheat query the hypervisor about the host's boot measurement, currently loaded drivers, and driver admission policy. This is how the split responsibility architecture works in practice: the developer's code inside the guest asks the trusted hypervisor about the host's integrity state, without the hypervisor exposing raw host data.
The kernel uses standard virtio interfaces for less latency-critical channels: virtio-vsock for networking, virtio-snd for sound, virtio-blk for storage, and virtio-fs for runtime file access. Game binaries and assets are loaded from a developer-signed manifest whose root hash is part of the boot measurement, preventing tampering. The total codebase is small: about 6,200 lines of code changes to Gramine, plus 13 new system calls for SDL compatibility.
Direct GPU Access Without Paravirtualization
The second design contribution is the shared GEM context graphics pipeline, which avoids the per-batch VM exit overhead that kills performance in conventional paravirtualization.
Instead of sending graphics commands through virtio, Tirith maps the host's GEM (Graphics Execution Manager) objects directly into the guest. The host VMM allocates per-process GEM buffers from the host's DRM render node, and the hypervisor projects them into a pre-reserved 128 MiB region of guest physical memory under a write-combining cache policy. Inside the guest, the game and its OpenGL stack issue draw calls directly against these shared buffers with no frame copy or format conversion.
Only the control plane, the ioctl and graphics syscalls on the render node, is forwarded to the host to interact with the physical GPU. This forwarding uses an exception-less shared-memory channel with CPU notifiers instead of virtio, averaging 254 nanoseconds per empty message. The host then displays the frames, which already live in a host-mapped GEM buffer, at native cost using a bridged windowing approach.
The result is that the data plane, the actual pixel data and vertex buffers, never crosses the guest-host boundary. The game writes directly into shared memory that both the guest GPU stack and the host display compositor can access.
Security on Both Sides of the Trust Boundary
The security analysis examines two threat directions. From the developer's side, a malicious anti-cheat inside the PVM could attempt to read host memory, issue DMA attacks, or abuse the in-band interfaces to leak host state. The hypervisor's Extended Page Tables prevent direct memory access. Each interface is constrained: the message-passing channel has pointer sanitization to prevent boomerang-style attacks, the bridged windowing API is allow-listed to the game's own window only, the shared GEM mapping is not enlargable, and the hypercall interface returns only measurement digests, not raw host state.
From the player's side, a malicious player on the host could attempt to read or modify guest memory, tamper with the host kernel, or abuse the filesystem and network. Hypervisor memory isolation prevents guest access. The hypervisor measures initial host kernel state and tracks driver loading. Each file is integrity-checked via the signed manifest. Network communication is end-to-end encrypted via attestation and TLS.
The paper validates these guarantees against three real-world cheat families. Wallhacks, which inject DLLs to tamper with depth testing, are defeated because the guest cannot be debugged and only developer-specified modules load. Aimbots and triggerbots, which use memory reverse-engineering or synthetic input, are blocked because out-of-VM memory access fails and in-guest module injection is rejected by filesystem and module verification. Map hacks, which use packet sniffing or malicious kernel modules, are defeated because the host driver-admission policy refuses unsigned modules and network traffic is encrypted.
The Numbers: Near-Native Performance
The performance evaluation runs on an AMD Ryzen 5600X with 32 GB DDR4 and an AMD Radeon RX 6950 XT, testing Minetest, Quake 2, SuperTuxKart, and Team Fortress 2 at 720p, 1080p, and 1440p.
Tirith achieves average FPS within 4.1 to 5.2 percent of native execution and 1 percent lows within 16.5 to 18.2 percent. Compared to the best existing paravirtualization solutions, this is 2.4 to 2.8 times better on average FPS and 3 to 3.8 times better on 1 percent lows. For SuperTuxKart and Quake 2, Tirith is 1.3 to 7.4 times better than prior solutions with only 0.1 to 8.5 percent overhead versus native.
The initialization cost is about 3.1 seconds total, mostly from address space shadowing in QEMU. Memory overhead is 4.5 to 12.6 MiB, negligible for modern gaming machines. Input latency adds 25 microseconds in Quake 2, from 584 to 609 microseconds. Graphics pipeline latency is at most 0.14 milliseconds over native, compared to up to 25 milliseconds for existing solutions.
The authors note that existing kernel-level anti-cheats already incur 5 to 10 percent overhead and can cause system instability. Tirith's overhead is comparable while providing strong user privacy guarantees that kernel anti-cheats explicitly do not.
What This Means for Game Developers and Players
Tirith demonstrates that the privacy-performance trade-off in anti-cheat is a false dichotomy. The architecture preserves the full set of enforcement primitives that kernel anti-cheats provide today: blocking unsigned drivers, preventing debuggers, isolating devices, attesting platform integrity, scanning game memory, detecting module injection, and collecting game telemetry. It does this without the developer's code ever touching the host system.
For game developers, the deployment model is similar to what exists today. The developer ships a signed manifest and an in-guest anti-cheat module alongside the game. The hypervisor handles platform-level enforcement. The developer attests to the host's integrity state before starting competitive sessions. The anti-cheat runs with full privileges inside the guest, where it can monitor and enforce game integrity.
For players, the benefit is that the developer's code is confined to the PVM. It cannot read your files, monitor your other applications, capture your screen, or persist on your machine. The hypervisor, provisioned by your OS vendor and launched through secure boot, is the only component that mediates between you and the game, and it exposes no raw state to either side.
The immediate deployment target is Linux distributions and controlled platforms like SteamOS and the Steam Deck, where the attestation infrastructure is tractable. The design ports to other platforms, including Windows VBS. The authors argue that as Linux gaming grows, the community will standardize remote attestation requirements, following the precedent set by UEFI Secure Boot.
Open Questions and Limitations
Tirith does not address hardware-based attacks that use interposed display or input devices, which are expensive and error-prone. It excludes memory-based attacks like control-flow hijacking through ROP that compromise the kernel without installing drivers. Micro-architectural side channels are also out of scope.
The shared GEM pipeline requires per-process GEM allocation, which means each game gets its own set of buffers. This works well for single-window games but may need extension for games that manage multiple rendering contexts. The 128 MiB pre-reserved region in guest physical memory is sufficient for current GPU workloads but could become a constraint with future graphics APIs that demand larger buffer pools.
The exception-less message-passing channel for control plane forwarding assumes the host VMM is trusted. In Tirith's architecture this holds because the hypervisor is first-party and signed, but it does mean the VMM becomes part of the trusted computing base alongside the hypervisor itself.
For now, Tirith shows a concrete path away from the kernel anti-cheat paradigm. The gaming industry can have anti-cheat effectiveness and player privacy without asking anyone to install unverifiable ring-0 drivers on their personal computers.
Read the paper on arXiv