Source-linked AI summary
You Shall Not Pass into Ring-0! A User Privacy-Friendly Anti-Cheat Architecture for Personal Computers
Santosh Gokul Narayanan, Giovanni Paladino, Chuqi Zhang, Sangho Lee, Zhenkai Liang, Adil Ahmad
TL;DR
Kernel-level anti-cheats protect competitive games but expose users to unverifiable privileged software, while prior work largely leaves that privacy problem unaddressed. Tirith runs games in Protected Virtual Machines, delegates host monitoring to a trusted virtualization monitor, and adds a game-focused kernel with efficient graphics sharing. It preserves common anti-cheat protections while achieving near-native performance, though its scope excludes several hardware, memory-based, and side-channel attacks.
Problem
Kernel-level anti-cheats create significant privacy risks through developer-controlled privileged software, while prior anti-cheat research has largely ignored this concern.
Method
Tirith combines Protected Virtual Machine sandboxing, split responsibility between a trusted hypervisor and guest anti-cheat, a Library OS kernel, and native shared-GEM graphics.
Results
Tirith preserves anti-cheat protection and achieves average FPS and 1% lows within 4.1-5.2% and 16.5-18.2% of native, respectively.
Takeaways & Limitations
Tirith demonstrates that strong user privacy can coexist with cheat prevention and near-native gaming performance on personal computers.
Takeaways & Limitations
Tirith excludes hardware-based display or input interposition, memory-based kernel compromises, microarchitectural defects, and side channels.
Abstract
from arXiv · showhide
Kernel-level anti-cheats are effective against malicious player behavior in competitive video games, but raise significant user privacy concerns regarding installing unverifiable components at privileged modes (i.e., ring-0 in x86). While existing research has focused on improving the effectiveness of anti-cheats, the user privacy concern has been largely ignored. Tirith is an anti-cheat architecture that addresses this problem using two key ideas. First, instead of running video games within regular processes that players (as root admins) have control over, Tirith executes video games in Protected Virtual Machines that naturally sandbox computations from untrusted admins. Second, to monitor user behavior outside the sandbox (e.g., see if they are running malicious drivers), Tirith leverages a virtualization monitor that is trusted by both players and developers. Together, these ideas remove the need to run untrusted kernel-level anti-cheats, while providing the same level of protection compared to such solutions against a wide-range of common cheating mechanisms. The main challenge we face in implementing these ideas, however, is that the existing software stack for virtual machines is not designed to run video games and creates significant security and performance problems. We address these problems by proposing a security-focused Library OS kernel for games and an efficient graphics sharing pipeline for near-native rendering and display performance. In summary, without compromising on cheating behavior detection or performance, this work makes user privacy a first-class citizen in personal computers.
1 Introduction
Tirith replaces developer-controlled kernel-level anti-cheats with Protected Virtual Machines and a trusted virtualization monitor, addressing privacy risks while preserving cheat detection and performance. Its prototype combines a game-centric Library OS with shared-GEM graphics to support secure, near-native gaming.
- Motivation: Kernel-level anti-cheats create privacy risks because privileged developer-controlled software can collect telemetry beyond gameplay and exhibit spyware- or rootkit-like behavior.Existing research has mainly improved detection effectiveness or protected detector logic, rather than addressing this privacy problem.
- Architecture: Tirith removes the need for developer-controlled kernel-level anti-cheat components by combining Protected Virtual Machines with a trusted virtualization monitor.The architecture separates game execution from the player-controlled host while monitoring host behavior through a trusted component.
- Implementation: The prototype places the game and anti-cheat module in a minimized Library OS and uses shared GEM buffers to avoid graphics command encoding, decoding, frame copies, and VM exits.The implementation extends Gramine with virtual devices, signed asset manifests, host RPC, attestation hypercalls, and a native OpenGL rendering pipeline.
- Security: Tirith’s security analysis shows preserved host privacy and anti-cheat protection against wallhacks, aimbots or triggerbots, and map hacks.These cheat families are addressed using combinations of in-guest and monitor-delegated primitives.
- Performance: Average FPS and 1% lows remain within 4.1-5.2% and 16.5-18.2% of native, while improving 2.4-2.8× and 3-3.8× over existing paravirtualization solutions.The evaluation covers benchmarks and real-world games, with reduced guest CPU and memory utilization.
2 Motivation
Kernel-level anti-cheats combine user-level and privileged kernel components to monitor cheating, but their broad system access creates serious privacy and security concerns. Prior work improves detection or protects selected defenses without addressing the underlying privacy risks.
- Existing anti-cheats: Kernel-level anti-cheats use privileged drivers alongside user-level components to observe memory, injections, drivers, debugging, input, and display activity.Their high privilege also helps them resist tampering and bypass attempts.
- Risks: These systems expose players to privacy risks because closed-source developer software can access unrelated host data, interfere with benign applications, and support screenshot capture or rootkit-like behavior.The cited examples include Vanguard’s display interposition and concerns about concealment and resistance to removal.
- Research gap: The existing literature does not address the privacy risks introduced by kernel-level anti-cheat software itself.This gap motivates an architecture that treats privacy and anti-cheat security together.
- Prior work: Prior research falls mainly into cheat-detection techniques such as replayability, behavioral analysis, and rendering perturbation, or trusted-execution defenses targeting selected behaviors.Examples include AVM, machine-learning aimbot detection, Invisibility Cloak, BlackMirror, and BotScreen.
3 Goal and Approach
Tirith targets Linux gaming with a Protected Virtual Machine that isolates games from root users and a split architecture that assigns platform security to a trusted hypervisor. The approach preserves developer control inside the guest while limiting host visibility and interfaces.
- Goal: Tirith targets Linux because proprietary kernel coupling and user-customizable kernels make conventional kernel-level anti-cheats difficult to deploy and trust.The goal is a privacy-friendly architecture without developer-controlled privileged components.
- Virtualization-Based Sandboxing: Protected Virtual Machines replace ordinary processes by isolating game CPU and memory state from an untrusted root user while giving the developer control inside the guest.The hypervisor is first-party, higher-privileged than the kernel, and launched through secure boot.
- Design challenge: Because GPUs, input devices, and host-backed assets remain shared, complete game protection requires trusted host visibility and control beyond CPU sandboxing.Malicious drivers or modified assets could otherwise tamper with display output or game execution.
- Split Responsibility Architecture: Tirith splits enforcement: the hypervisor handles boot integrity, driver verification, anti-debugging, device isolation, and attestation, while guest components handle memory scanning, hardening, integrity, and data collection.This partition lets the developer query platform trust before sessions while retaining game-specific enforcement in the protected guest.
- Deployment scope: The initial deployment target is mature Linux distributions and controlled platforms because ecosystem fragmentation complicates remote attestation.Examples include Ubuntu, SteamOS, Steam Deck, and Steam Box.
4 System and Threat Model
Tirith assumes mutually distrustful players and developers, with the OS vendor as the trusted platform provider. Its threat model relies on a trusted hypervisor and excludes several hardware, memory-based, microarchitectural, and side-channel attacks.
- Trust assumptions: The player has root or administrator privileges and may attack game execution, while the developer’s code is not trusted with host data.The model therefore treats both player and developer as mutually distrustful parties.
- Trust assumptions: The OS vendor is trusted to provide the platform, but the player may manipulate the host kernel at runtime by installing malicious drivers.The hypervisor is the shared trusted computing base for isolation, integrity, and mediation.
- System model: The architecture partitions protection between an attested hypervisor and guest-side game enforcement, using virtualization to mediate host interaction.The figures summarize the VM sandboxing and native graphics/display pipeline underlying this design.
- Out of scope: The scope excludes hardware interposition attacks, memory-based kernel compromises that avoid malicious drivers, microarchitectural defects, and side channels.These exclusions are consistent with the stated threat-model boundary.
5 Running Video Games under Virtualization
The case study finds that existing virtual-machine stacks impose substantial resource, isolation, and graphics-performance costs for running video games. These costs arise from heavyweight guest kernels and repeated guest–host graphics crossings, motivating more specialized virtualization designs.
- 5.1 Preliminary Knowledge: Virtio provides guest–host device sharing through shared ring buffers and MMIO doorbells, but GPU access is especially costly because graphics is the most latency-sensitive device.CPU virtualization can approach native speed, whereas device sharing relies on slower software techniques.
- 5.2 Case-Study and Findings: The evaluated case study used muvm with libkrun, KVM hardware acceleration, and both VirGL and DRM-Native on three open-source Linux games.Performance was compared with execution on the host.
- 5.2 Case-Study and Findings: Full-fledged guest kernels increased CPU utilization by 4.9× in one game and added approximately 600 MiB of memory while exposing around 911 guest–hypervisor communication pathways.These findings create both resource-utilization and isolation challenges for gaming workloads.
- 5.2 Case-Study and Findings: 1.4-13.3× and 1.9-21.3× fewer average and 1%-low frames, respectively, occurred under both VirGL and DRM-Native versus native execution.The resulting performance was below what high-performance games tolerate.
- 5.2 Case-Study and Findings: Up to 82.9× higher graphics-pipeline latency than native execution occurred with VirGL, while both paravirtualized solutions incurred at least an order-of-magnitude overhead.The latency measurement covered graphics commands submitted to DRM and frames submitted to the window manager.
- 5.1 Preliminary Knowledge: Virtio-based GPU paravirtualization imposes excessive cost because each batch crosses the guest–host boundary through exits, dispatch, copying, and interrupt injection.VirGL additionally performs command-stream encoding and decoding; DRM-Native removes that translation but retains the per-batch world switch.
6 Tirith Design
Tirith combines a minimized, game-centric LibOS with a trusted hypervisor and shared GEM graphics to keep interfaces narrow while supporting unmodified Linux games and efficient rendering.
- 6 Tirith Design: Tirith’s design uses a lightweight LibOS kernel and a graphics-sharing pipeline that avoid the security and performance limitations of existing virtualization stacks.The LibOS minimizes outside interfaces for Linux games, while the graphics pipeline avoids slow paravirtualization interfaces.
- 6.1 Minimized Game-Centric LibOS Kernel: The LibOS exposes virtual graphics, input, sound, and platform-attestation devices while using virtio for less latency-critical networking, sound, and storage.These interfaces redirect system calls either to internal LibOS components or the host manager, with controlled host interaction.
- 6.1 Minimized Game-Centric LibOS Kernel: Developer-signed manifests, measured Zygote images, and remote attestation verify the game environment before a competitive session starts.The hypervisor records launch measurements, while the guest verifies the signed manifest and reports measurements to the game server.
- 6.2 Shared GEM Context Graphics Pipeline: Shared GEM objects let the guest render directly into host graphics buffers, avoiding frame copies, format conversion, and most guest-host graphics overhead.Only small command-submission packets cross to the host, and rendered frames can be displayed directly from GEM objects.
- 6.2 Shared GEM Context Graphics Pipeline: The hypervisor projects GEM buffers into reserved guest memory and mediates their allocation, preserving protected graphics sharing while supporting dynamic regions.A 128MiB region was mostly sufficient for the evaluated applications; additional regions can be securely registered when needed.
7 Security Analysis
Tirith uses a trusted hypervisor and a narrow, mediated interface surface to protect host privacy while preserving kernel-level anti-cheat enforcement inside the guest.
- 7 Security Analysis: Tirith’s interfaces are fixed-direction, single-mediator channels with typed payloads, supporting analysis of host privacy and game-security guarantees.The design adds four interfaces for graphics, windowing, input, and host attestation.
- 7.1 Host Privacy: The hypervisor isolates guest CPU state and memory, while the IOMMU and interrupt remapping constrain DMA-capable devices against host access.The guest cannot use the CPU to read or write memory outside its shared regions.
- 7.1 Host Privacy: Mediated message and windowing interfaces block out-of-bounds pointers, cross-window operations, and unsanctioned host actions.The host sanitizer bounds-checks guest pointers, and the window bridge allow-lists lifecycle operations on the game’s own window.
- 7.2 Game Security: Host-side protections prevent players from reading guest memory, installing undetected malicious drivers, tampering with game files, or bypassing the trusted boot path.Memory isolation blocks debugging and DMA, driver measurements report configuration changes, signed manifests detect file tampering, and TPM measurements expose non-virtualized boots.
- 7.3 Cheat Prevention Case Studies: Tirith preserves the enforcement categories of kernel-level anti-cheats by delegating system-level checks to the hypervisor and retaining game-specific anti-cheat logic inside the guest.PoC tests cover wallhacks, aimbots or triggerbots, and map hacks using the protected guest and monitored host environment.
8 Implementation
The prototype targets AMD x86 Linux with KVM, extends Gramine for game compatibility, and implements the graphics path through OpenGL/EGL helpers and a host-side virtual GPU.
- 8 Implementation: The prototype runs on AMD x86 Linux with KVM because protected KVM was still under development and being ported from Android ARM.The authors note that prior work similarly emulated Protected VM infrastructure.
- 8 Implementation: Tirith’s LibOS derives from Gramine, adds 13 system calls for SDL compatibility, and supports more than 170 existing POSIX system calls.The implementation includes 6.2k lines of changes and targets Linux-native games using SDL.
- 8 Implementation: The rendering helper supports OpenGL 4.6 by translating context creation to EGL, while a second helper handles direct display in Tirith’s pipeline.These helpers are loaded into the LibOS during boot to support the efficient graphics path.
- 8 Implementation: The host implementation uses QEMU 10.1 and a lockless virtual-GPU listener with multiple threads to process guest system-call and display requests.The listener executes commands passed from the guest and scales across multithreaded game environments.
9 Performance Evaluation
Tirith was evaluated on four games and achieved near-native performance while substantially outperforming existing GPU paravirtualization solutions. Its measured input and graphics overheads remained small, although Minetest exposed larger performance gaps.
- 9.1 Microbenchmarks: Initialization added 2.9 s for QEMU address-space shadowing and message passing, 56 ms for LibOS and devices, and 16 ms for rendering and window contexts.Measured additional memory overhead was 4.5-12.6 MiB, while empty-message round trips averaged 254 ns.
- 9.1 Microbenchmarks: Tirith increased Quake 2 input latency by 25 μs and a continuously polling GLX application’s latency by 73 μs.Most overhead came from forwarding input through QEMU and Gramine via shared memory.
- 9.2 Real-World Video Game Performance: 4.1-5.2% geometric mean overhead in average FPS and 16.5-18.2% in 1% lows versus Native, outperforming existing solutions by 2.4-2.8× and 3-3.8×.The games ran for at least five minutes at or near maximum graphics settings; 1% lows capture frame-time consistency and FPS dips.
- 9.2 Real-World Video Game Performance: Supertuxkart and Quake 2 showed 1.3-7.4× better average FPS and 1% lows than prior work, with only 0.1-8.5% overhead versus Native.Team Fortress 2 incurred 2.7-4.9% average-FPS and 15.8-16.5% 1%-low overhead, achieving 1.1-2.2× better performance than existing work.
- 9.2 Real-World Video Game Performance: Minetest incurred 7.7-9.4% average-FPS and 30.1-35.4% 1%-low overhead versus Native, while outperforming prior solutions by 1.9-16.4×.DRM-Native delivered only 4-7.5% of Native performance in Minetest and was identified as an outlier requiring further investigation.
- 9.2 Real-World Video Game Performance: Tirith achieved 2.4-4.1% average-FPS and 11.5-13.8% 1%-low overhead versus Unmodified Native, with graphics latency at most 0.14 ms above Native.The zero-copy Native Shared GEM Context minimizes CPU overhead in the graphics pipeline.
10 Related Work
Related work progresses from user-space trusted execution environments to whole-VM virtualization for isolating workloads from untrusted hosts. Existing enclave approaches protect selected applications or defenses but do not provide the kernel-level functionality needed to replace privileged anti-cheats.
- 10 Related Work: Tirith belongs to the broader effort to isolate code running on machines whose root user is untrusted, using a coarser whole-VM boundary than user-space enclaves.The paper organizes prior work along this progression of increasingly coarse isolation primitives.
- 10 Related Work: User-space TEEs such as SGX-based systems isolate applications from compromised host kernels but cannot provide driver admission or anti-debugging.Consequently, they cannot themselves replace a privileged kernel anti-cheat on the host.
- 10 Related Work: Recent consumer-machine systems move isolation to whole-VM virtualization, including Windows VBS Enclaves, Android Protected KVM, and TwinVisor.These systems use hardware-assisted isolation to protect workloads from host operating-system components.
11 Conclusion
The paper concludes that Tirith replaces kernel-level anti-cheats with a two-way Protected VM while preserving enforcement capabilities and removing host-side privacy concerns. Native shared-GEM rendering and bridged split-windowing provide near-native performance with modest overhead.
- 11 Conclusion: Tirith replaces today’s kernel-level anti-cheats with a two-way Protected VM for private and secure PC gaming.Responsibility is split between the host’s first-party virtualization monitor and the game developer’s code.
- 11 Conclusion: Evaluations on real games and cheating mechanisms show strong security guarantees with modest performance overheads.The architecture preserves the enforcement primitives provided by kernel-level anti-cheats while removing the host-side privacy concern.
B Generative AI Usage
The authors used LLMs for copy-editing and implementation debugging, with all usage reviewed by the paper’s authors.
- B Generative AI Usage: LLMs supported copy-editing and implementation debugging, and the authors reviewed all such usage.