Online cheating as existed for as long as online games have existed. Long before companies cared about online gaming as a serious generator of revenue. There is a certain percentage of the population which enjoys hurting others and making them have a bad time. The anonymity of online games allows them to be antisocial with very few social repercussions.

I think equating having the option of KLAC with Windows is totally disingenuous. There are countless other differentiators. You would be free to just not use KLAC if you so desired.

If it's on Linux then it wasn't kernel-level anti-cheat, and therefore mostly useless. It's not surprising that it did nothing to slow down cheating. Even KLAC can be circumvented. It increases friction and cost for cheaters but it doesn't solve the issue completely.

Ideally you would be free to not play KLAC games, and I would be free to play KLAC games. I just hope for the option one day, as I would very much like to make the move to Linux.

I agree, it's a curve. I don't think we'll ever completely eliminate cheating, but we can make it so difficult and expensive that most people don't do it. That's good enough for me.

It's very simple: I like the games more than I want to move to Linux. Playing Fortnite isn't going to give me lung cancer.

What if those games are the only games they and their friends play together? I wouldnt want to stop that.

Thanks. I intentionally avoid games without KLAC now because the cheating is so bad. The most recent example is Arc Raiders. Such a fun game at launch, very quickly overrun by cheaters. They eventually added KLAC but because they also offer a Linux build, they could not stop the cheating. The game is mostly dead now, [down to just 6% of its peak.](https://steamcharts.com/app/1808500#All)

I would like to respond because you're speaking authoritatively but this is mostly your opinion.

> I want to clarify to anyone reading this that this only effects high-competitive games, like LoL, Valorant, PUBG, R6S; and not all of them (e.g. Counter Strike).

It affected a game I really care about: Arc Raiders. That's not a "high-competitive" game. It's PvPvE, shooting at funny robots and scavenging rubber duckies. Cheating killed the game. [It's down to 6% of its peak.](https://steamcharts.com/app/1808500#All) Just because this hasn't affected the games you love doesn't mean it's not affecting many games. See Titanfall, H1Z1, and The Cycle: Frontier, among many more.

> It does not affect "multiplayer" in general, to the contrary, most multiplayer games are not affected (coop games, MMOs, RTS).

I was going to ask you to back that up, but I realise I made a broad claim and can also not back it up, so we're just giving each other our opinions, I suppose.

> Ofc, cheating is also present with KLAC, its just the next level of the cat and mouse game (Driver exploits, DMA access via PCIe, Network Packet analysis, ...)

Indeed. The goal is to reduce cheating to a manageable level. It is impossible to eliminate.

> Nonsense. 1. Almost no anticheat is implemented on Linux in the first place. Most "working" anti-cheat solutions for Linux are just a #if Linux doNothing(); #else ... 2. KLAC requires SecureBoot/ChainOfTrust + closed source code running with highest privileges. This does not make sense for any PC, but I dont see why it would be harder to do on Linux than on Windows, Linux just has a smaller install base in general and a lower acceptance rate for KLAC, therefore its not worth it to implement.

Linux does not properly support KLAC because its architecture and development philosophy work against it. For example, Valve explicitly recommends user-space anti-cheat for Proton and says kernel-space anti-cheat is “not currently supported and is not recommended”.

The Linux kernel also deliberately does not provide a stable binary kernel-driver interface. Kernel maintainer Greg Kroah-Hartman has said that Linux has neither a stable in-kernel API nor a stable binary kernel interface, because maintainers want the freedom to change kernel internals rather than permanently support proprietary out-of-tree drivers.

Riot is on the record as explaining that Linux does not give Vanguard sufficient ability to attest boot state and kernel modules. They also claim that distribution differences make enforcement harder, and that cheats can potentially operate outside an emulated environment where the anti-cheat cannot see them. Riot is on the record saying that anti-cheat is “extremely hard on Linux by design”.

So you're technically correct, but I think you misunderstand a lot of the architecture which underpins this issue, and the ideological boundaries which many developers prefer to enforce around security, FOSS, and ownership.

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.