There is no doubt an economics problem here, where it might not make sense to invest a lot of effort into a system from which less than 1% of revenue is derived.

However, KVM does not solve the problem. In fact, Riot explicitly explains why virtualisation can make the problem worse: if Vanguard runs inside a guest, a cheat can run on the host and manipulate the VM in ways the anti-cheat cannot see. Riot says Linux currently does not give it sufficient ability to attest the boot state or kernel modules, with distro differences making the problem harder.

Linux also deliberately does not provide a stable in-kernel ABI for proprietary out-of-tree drivers. The kernel documentation explicitly says there is neither a stable binary kernel interface nor a stable internal kernel interface. The preferred model is for drivers to be upstreamed and maintained with the kernel, which is almost the opposite of how closed-source kernel anti-cheat is normally deployed.

And this isn't just Riot. EA actually supported EAC through Proton for Apex and then removed Linux access because its anti-cheat team said Linux was being used for impactful cheats, that Linux cheats were harder to detect, and that they couldn't reliably distinguish a legitimate Steam Deck from a malicious Linux client pretending to be one.

Valve itself tells developers that Proton's recommended solution is user-space anti-cheat and that kernel-space anti-cheat is “not currently supported and is not recommended”.

So I guess it's technically possible for a game dev to effectively create their own Linux distro, but I hope we agree that's never going to happen. They're game devs, not Linux devs. Anti-cheat needs a trust chain that the hostile user cannot control and not just an API through which it can inspect the system. Linux deliberately gives the machine owner far more control over the kernel and environment, which is exactly what makes strong client-side attestation difficult.

FYI bhyve isn't a Linux hypervisor. It's part of FreeBSD.