Kernel-level vs. user-space anti-cheat
4 min read
Why some anti-cheats work on Linux and others never will.
Two privilege levels
Operating systems separate code into privilege levels. Ordinary programs, including most games, run in user space. They can only touch their own memory and must ask the operating system for anything else. The kernel (often called Ring 0 on x86 CPUs) sits underneath with unrestricted access to the whole machine.
A user-space anti-cheat lives in the same restricted world as the cheat it is trying to catch. A kernel-level anti-cheat installs a driver, so it can see processes, drivers and memory that user-space software cannot.
Why developers choose kernel drivers
Many modern cheats run at high privilege themselves, or read game memory from outside the game process. A user-space anti-cheat has a hard time seeing them. A kernel driver can inspect loaded drivers, block suspicious memory access and detect tampering earlier. That is the reason behind the always-on drivers of systems like Riot Vanguard and RICOCHET.
Why that matters for Linux
A Windows kernel driver cannot load under Wine or Proton. Wine translates Windows API calls to Linux, but it does not run a Windows kernel. A kernel anti-cheat that insists on its driver therefore cannot work on Linux or the Steam Deck.
The trade-off cuts both ways. Kernel drivers raise the security stakes for players, because a bug in a driver can crash or compromise the whole system. Linux's own security model also makes it hard to prove to a game that the system has not been tampered with, which is a common reason vendors give for not supporting it.
Hybrid approaches
Easy Anti-Cheat and BattlEye ship a kernel driver on Windows but also a separate Linux runtime that works in user space. That is why they can work on Proton when the developer enables it. Valve's VAC is user-space on every platform, so it has no such problem.