The Duff CEO with a Windows-Logo on his forehead: “Gamers use Windows because of its’ user experience not our de facto monopoly.”
Next Image: Duff CEO with Windows-Logo in front of a “Out of Business” sign. Subtitle: “30 minutes after SteamOS is released”
Edit: Yo, I’m not saying this is gonna happen. I just want to say that Windew’s UX sucks ass.
Technically, all the major anti cheats have Linux userspace binaries that even support wine/proton passthrough, so there are actually a lot of anti cheat games that run on linux as shown in the list.
The issue is not entirely something SteamOS can solve or is even linux’s fault because no sane distro would ever support running a kernel level anticheat module. It would break the defining security features of linux, and I’m not even sure DKMS or Akmod would support it out of box on secure boot.
The games in question refuse to enable anticheat on linux because they know the userspace binaries are limited, but then their windows solution is just a crappy rootkit. It’s not a very good or longterm solution either. EAC and Battleye both have demonstrable bypasses with various methods of fooling. Only Vangaurd seems to aggressively keep up with the arms race by literally scanning your PCIe devices for hardware cheats.
What they can do is to convince game OEMs to enable their linux AC support by marketing the potential customers they are losing out on. That’s basically what happened with Halo MCC and Infinite. I’m still surprised they actually convinced Microsoft to allow both games to run on Linux with EAC.
I am an idiot, so this is probably a dumb question, but it sounds like you might be able to shine some light.
Why could we not run kernel level anticheat in a sandbox? Does kernel level inherently mean a sandbox cannot contain it?
As an aside is kernel level anticheat required for anti-cheat to function? Or are the developers of anti-cheat software just doing kernel level because its easier?
The linux kernel actually does have several sandboxing paradigms and techniques, but by the definition of anti cheat means that it cannot be sandboxed.
The anticheat essentially scans the entire system memory, filesystem, and loaded kernel modules to ensure the userspace software is not being tampered with. It would be impossible to do that in a sandbox, hence it breaks all the security standards linux has for kernel modules (ex: why would a wireless driver need to access a printer module?).
Even for windows, kernel level solutions are not very well suited to be running there. The recent crowdstrike outage is a notable example, because it did essentially the same thing but then a bad update bluescreened every machine because giving a kernel module complete access is almost like modifying the kernel itself.
It’s not required to function, but kernel level anticheat is just harder to bypass (still doable). They’re choosing kernel level because it’s cheaper to slap on a 3rd party AC than to make effective server-side software and pay for server moderation. Even Valve is hesitant with their VAC 3 system, even though it has been a major upgrade, it still requires manual moderating.
The thing is, most devs have finally realized kernel level anticheat still isn’t an effective solution, so they have been fine with the userspace anticheat on linux and opting for server side stuff. It’s just these last few holdouts that refuse to budge because they don’t value the linux market (yet).
Thank you for the insightful response! Its sad that the cheapest option is the only choice ever chosen, sounds like we could create jobs and foster better security choices simultaneously here (and probably end up with a better online experience to boot).