Gaming on Linux without cheating
onlineservices.epicgames.com
onlineservices.epicgames.com
> Signed Kernel and Kernel modules
Probably the most egregious. Why am I not allowed to compile my own kernel? Why do I have to get a kernel, and modules, from specific, approved, vendors?
> TPM 2.0, Secure Boot, Measured Boot
Also all impractical for most linux users.
> IOMMU
You may not spy on my memory, thank you very much. What's stopping Epic from taking snapshots and phoning home?
> Kernel Lockdown Integrity mode at boot time
Preventing root from doing root things for the sake of it. I mean, maybe this makes sense.
They're also trying really hard to make Linux distros that "don't support this" look like the bad guys. They encourage distro maintainers to reach out to work together on the requirements, but many distros are effectively excluded by default (Arch, Gentoo, NixOS, which I believe have most of the gamers, at least in the online spaces I chat in).
There are so many to chose from, even retrogaming content is more than I can play during my remaining lifetime.
Thus Proton depends on Windows as source ecosystem, only yet another platform to "emulate" on Linux, like MAME, Amiga, Playstation, whatever.
Windows is just that much better for game devs.
Because your kernel could have the ability to allow a program to modify the game memory and hide the fact it's doing so?
Most Linux users are probably using a signed kernel. I don't think this is as big of a deal as you're making out.
I understand this, and my contention with this is that a signed kernel could have that too, so requiring the kernel to be signed locks us into very few ways of getting the kernel with little benefit to the AC if a key is leaked.
> Most Linux users are probably using a signed kernel. I don't think this is as big of a deal as you're making out.
I don't think this is true of most people interested in gaming on Linux in particular. Aside from that, the chain of things you need to do to prove you have a signed kernel are onerous and incompatible with many bootloaders and other tools many Linux users use regularly.
The goal here is to expand support to games that have chosen not to opt-in to user-mode anticheat, which isn't going to happen without some form of kernel protection.
With that said, I'm pleasently surprised that Epic's initial list of supported signing keys includes a number of noncommercial entities (AlmaLinux, Debian, Rocky Linux, Universal Blue) in addition to the usual commercial suspects (Canonical, Red Hat, SUSE).
The only real sticking point with popular gaming distro support appears to be Steam devices / SteamOS, which the phrase "to the maximum extent technically possible" suggests might be problematic for reasons other than including a signing key.
This seems like it could be a potential problem in getting game developers whose sole interest in supporting Linux is the Steam Deck to play along with the scheme, or alternatively a potential problem for Valve if there's enough uptake that Linux gamers start considering non-Steam devices, and by extension, storefronts, due to the fact that other devices could support a superset of games, given that neither Steam nor Proton are Steam hardware or SteamOS-specific.
Userspace bugs is where I’d look first.
I think most people will dual boot a ready made gaming distro like Garuda next to their normal one anyway because the kind of setup you need to really optimize game performance is not easy, and you can get a console/Steam Deck like experience right from boot.
Even a locked down Linux is infinitely better than Windows if you care about privacy, because you only have two closed source components (EAC and the game itself) instead of the whole OS. If any of them tries to read your private data it will turn to a scandal immediately and they can't blame Microsoft.
And IOMMU does not let anyone spy on memory. The whole point of it is making sure no one can do that, to avoid DMA hacks.
So you can ignore the newly-enabled games in this proposal and you're not missing anything you had previously.
Frankly at this point I’m pretty sure John McDonald plays HvH too
Now, if we want an interesting case study in intrusive anticheat not necessarily being more effective than behavior-based, we should compare FACEIT to Valve servers. FACEIT is riddled with cheaters, and yet requires ring-0 anticheat on Windows. So fascinating!
> FACEIT is riddled with cheaters
According to sources of… what? In any case it’s sure as shit less riddled with cheaters than Premier LMAO
The same goes for a binary protected by TPM 2.0, but the attacker would have to re-implement the protected parts. The defender's bet is that this should require too much effort/time/knowledge to bother.
This is a risk if Valve plays along in the future, however, or if players are willing to migrate away from the Steam ecosystem to run games that require the new scheme.
I use CachyOS but don’t really play many games on Linux. I’ve enabled secure boot so I can seamlessly swap to Windows for certain kernel-level anti-cheat games like Valorant. Using a shell alias/function (and menu bar buttons), I can boot into Windows (yay Limine one-shots!) in one command/click and next reboot, while in windows, gets me back into Linux. I really like this setup and believe it’s the most seamless you can get, besides a Windows VM with GPU handoff in Linux, which when I tried a couple years ago, was able to work with Apex.
Because otherwise you can cheat of course. You can code in whatever you want in your own Linux.
If you don’t want to play these games you don’t need to install any of this. But this is not unusable and none of this is impossible for distros. Most of this stuff is super common and the average linux user wouldn’t even notice.
Distros will just offer a “gaming-ready” image/mode that enables these restrictions and users can choose to use it or not.
> > TPM 2.0, Secure Boot, Measured Boot
> Also all impractical for most linux users.
Ideally there should be little conflict between the two, however, modern online games require running sophisticated software locally that encapsulates core game logic. The fairness (compliance) goal demands that this software runs correctly and only conveys information and processes input as designed. The user control (freedom) goal demands that the individual user is allowed to run and modify any software as they see fit, including any game software, meaning that he or she must be able to tamper with the game software behaviour to gain advantage.
Now remember that online gaming is an extremely low-trust environment. Competitive online gaming is often supposed to emulate sportsmanship, thus widespread trust in the games' rules is essential so that players continue to participate. At the same time, building that trust dictates enforcing compliance down to the level of each individual user's hardware. So if you want to participate, you must be willing to give up ultimate control over your hardware and software, even if you believe it's only temporary.
All of this might sound very obvious, tautological even. However, lots of comments on this sound like they come from a place of unawareness of this contradiction. More people need to see that this is not a tech incompatibility issue, but rather a more serious values clash. Linux folks are (still) mostly the ones who prefer more freedom and control over their software, and competitive online gaming asks that they give that up. For a lot of people this defeats the purpose of using Linux in the first place.
Each participating distro's maintainers will need to publish a compliant distro flavour in binary form in order to remain on the "good guys" key list. Negotiating and implementing the compliance criteria, as well as maintaining the entire thing will all consume additional man hours, which open source maintainers famously have very little of.
If a distro/appliance maintainer is committed to continue to participate, an incentive emerges to gradually push the compliant version as the default, the later possibly the only supported version of their offering. Unhappy users may of course switch, but the more this proliferates the less good places will remain for them to go to. This pattern of enshittification by infiltration and complacency manipulation is the one we see almost everywhere in the modern tech.
Hopefully a well-enough organised minority of uncompromising users and developers always remains in tech, if not in the Linux world then in the BSDs. We will always need to keep our eyes open for the false values masquerading as tech dilemmas like this one.
I'm not a lawyer so I will not get into the legal ramifications of distributing locked-down binary versions of free software. However, it's clear that without obtaining the private signing key a user will never be able to modify that software on their system for the purpose of running the game, which may or may not infringe on their freedoms as provided by the licenses.
For example, the players may want to wants to mod the game-server with features, bug-fixes, or moderation-tools, while the publisher wants a strict lockdown to their artificial monopoly on "digital goods."
> Now remember that online gaming is an extremely low-trust environment.
Tied to the above point, I believe this trust was slightly-but-meaningfully higher when people could form their own servers/communities and be "regulars".
However publishers didn't like that arrangement, because it threatened their ability to sell cosmetics, collectibles, and sometimes outright gameplay advantages.
A more federated future for online gaming is theoretically possible, but seeing how much the Fediverse struggles with the adoption of alternatives to software that most people consider bare basics, I don't think it's the future that the arrow of entropy points to.
Then the mod must be loaded & run on the server's end, with its logic enforced on all players on that server. The client shouldn't have free reign over the server's internal logic & state.
The one exception to this are visual mods that modify the presentation. But even then I'm skeptical, as modifying the presentation layer can affect the decisions that X makes, or even worse, give them an unfair advantage that other players should also have if X has them.
Yes, I know, I'm already talking about that scenario.
Even with well-behaved clients, publishers have moved away from allowing server-mods because the operator could just as easily mod-in "players can equip stuff without paying the publisher $50 for the privilege of skipping hundreds of hours of artificial grind."
Or, in other words, skipping on "their sense of pride and accomplishment." [0]
[0] https://massivelyop.com/2017/11/13/ea-claims-star-wars-battl...
Moreover, restricting mods to only the server side doesn't solve the trust issue: if you don't trust your players, your only option is still to try and enforce their local configuration somehow. The problem with big publishers trying to centralize this authority is their audience will always be too big to trust without enforcing compliance, and relying solely on behavour report and review system will not scale.
Even without any mods, there's a lot of trust required between the client and the server in pretty much any online game. The client has more information that it is allowed to show, and the server often trusts it reports the user's actions faithfully, because enforcing all of that on the server side would be prohibitively expensive performance-wise.
For as much hate as cloud gaming gets (the whole "you will own nothing and be happy" schtick) I see it as the perfect solution to online competitive games:
- Even if you own physical media, you don't own the servers or data necessary to run the game.
- Games can be run by an accountable third party who runs signed kernels and hardware with attestation.
- None of your personal information ever touches this hardware.
There is a middle ground where instead of playing all of your games remotely, you only play the online competitive ones remotely in order to protect your data and ensure a fair environment. Too many companies have become rent-seekers to the detriment of their customers that this won't be seen as a viable solution because of the negative connotations.
Do not mistake this for complacency. I will gladly pick up a torch or pitchfork the moment NVIDIA suggests I rent their servers to play Minecraft or Stardew Valley, but for games like Battlefield 6 I think this solution works perfectly.
Or stop trying to run a "competitive" game across a global network of strangers, and trade some hard/brittle technological approaches for soft/resilient social ones.
As for the latter part, I know that I myself am too busy and not patient enough, and if I really, really wanted to play a protected game I'd probably just switch to a compliant distro and daily drive it.
It isn't as good as kernel level AC in some sense but is equal in others - it's easier to cheat at all on my AC because you don't need hardware, but it limits cheaters' opportunities enough that my AC + server-side detection is equal to kernel AC + server-side detection at catching any given cheater.
And in fact there are many online games that are competitive not in the narrow sense used above, but in a more general sense where people don't cheat because they choose not to, usually because a sense of community does exist among players of such games.
I would not have an issue with having a "gaming kernel" installed that I can reboot to when I want to game, one that gives EAC and other similar softwares access to my hardware so they can do their jobs, I don't love it, but I'm ready to make that sacrifice because I have experienced gaming with rampant cheating.
The problem is nobody is providing that option, and game developers are instead actively excluding Linux as a target platform entirely, e.g. Apex Legends, a game that ran well on Linux until October 2024 when Respawn decided to actively block it from joining online matches by toggling a flag in EAC.
I want to get off Micro$lops wild ride please.
Right, because they warranted EAC’s Linux offering as insufficient for protecting their titles from cheaters.
The proposed solution from Epic would resolve that.
There is also nothing from stopping other companies that have nothing to do with gaming from jumping on the bandwagon and requiring EAC Linux if it's already available.
I always had issues with this argument because the console fps are full of cheaters and they are better locked down than computers ever will be.
We know what works, heuristics and paid moderation. Unfortunately for gaming companies, it does cost money, they can't just slap an anti-cheat and call it a day.
It doesn't solve all methods for cheating, and it doesn't prevent cheating. But it does help you remediate it.
Are game companies training AI models to detect aimbot-like crosshair movement, for example?
Valve was talking about using machine learning to recognize cheating back in 2017: https://www.pcgamer.com/valve-wants-to-take-a-machine-learni... and more info from 2018: https://www.youtube.com/watch?v=ObhK8lUfIlc
And this one from 2023 is about using an RNN Deep Learning model for cheat detection: https://www.usenix.org/conference/usenixsecurity23/presentat...
It's a cat-and-mouse game. A detector detects inhuman speed? Aimbots adapt by limiting movement speed and reaction time. Detectors start looking for unnaturally smooth movement? Aimbots add randomness to make the movements less consistent and smooth.
Cheaters (athletes) are always incentivized to cheat in "new and exciting ways" today. It's impossible to defend against all possible new forms of cheating, but they instead keep blood samples for up to ten years so that "when they figure out what to test for", they can retroactively penalize participants.
Same with online cheating, save high fidelity recordings and be able to replay. As detection catches up to exploitation, you ban hammer the prior exploiters.
This is only if the clients aren't people that know each other. Cheating is, fundamentally, a social problem. No amount of technical solution will ever fix it, just make it more expensive. The biggest example of game that has cheaters and nobody is clamoring for anticheats is Meccha Chameleon.
Social enforcement does need tooling for communities to self-moderate, but that’s an argument for designing games around trust, like community servers, not for locking down the client. Any dev could ship community server support... but not doing so is a publisher choice, not something the customer should provide, but can demand
Doing it this way is strictly more private and secure than any anti-cheat on Windows, even the ones with no kernel access that run as administrator. The systemd service runs as a normal user, only when you're playing a game and you can verify that with one command. The same lockdown mode that blocks cheats also prevents EAC from reading arbitrary process memory.
I'm just waiting to see what distros Epic will whitelist next. I hope SteamOS gets support day one when the official desktop ISO comes out.
EDIT: More info here: https://lwn.net/Articles/13398/
Additionally macOS is transitioning to have only userspace drivers.
I suspect that eventually Microsoft will be pressured to do the same with the ongoing cyber security liability laws, and disasters like in 2024.
So will they only do consoles when it comes to it?
Stadia used Linux and they never had anti-cheat.
Desktop Linux has none of that.
Look, if Canonical had one of their keys leaked, I can go and sign my kernel and kernel modules and secure boot just fine as if my kernel is one distributed by Canonical. There are no checks on whether the contents of the kernel are correct. So, let's exclude people entirely from tuning their kernel for performance etc, and tell them they have to go to a narrow set of approved vendors, who must listen to Epic rather than their users. This is about control over the ecosystem, an ecosystem Epic has spent their years spitting in the face of.
Secure boot is not attestation. It does not provide userspace any guarantee the system booted a secure boot chain.
Secure boot can be bypassed by dodgy firmware (cough cough msi) or the kernel can lie to userspace about the secure boot state.
The moment the UEFI firmware jumps to the bootloader, secure boot is no longer useful.
> Look, if Canonical had one of their keys leaked, I can go and sign my kernel and kernel modules and secure boot just fine as if my kernel is one distributed by Canonical. There are no checks on whether the contents of the kernel are correct
This is literally where the TPM comes into play because your kernels signature would get written to the PCR register and fail an attestation check.
> This is about control over the ecosystem, an ecosystem Epic has spent their years spitting in the face of.
This is just FUD
I'm not sure how you get that from the article (maybe it was pointed to a different article earlier?).
I don't have a Steam Deck, but as I understand it, it does not support Secure Boot out-of-the-box. Also, SteamOS is Arch-based, and it doesn't look like Arch is listed among the "well-known" signing keys that EACv2 lists as trusted.
But not supporting the EACv2's requirements today, doesn't mean that Valve is inherently opposed to doing so. If you have a statement from Valve claiming that, please share it.
If you cannot control anymore what is being built, the desperation to try and control what is being run will only become larger.
No. [...]
Does EAC Linux v2 run in the background all the time?
No. [...]
Those seem a bit misleading if the anticheat encompasses the entire operating system...
The "Does EAC Linux v2 use a kernel driver?" does feel slightly misleading, especially considering the API stability guarantees are also the same as regular kernel drivers, but the "Does EAC Linux v2 run in the background all the time?" doesn't necessarily feel misleading to my understanding.
You can create a fake efivarfs, fake integrity states, etc, and if they actually try to test the integrity features to see if it's true, you can easily determine that and conditionally provide the vanilla behavior.
Yeah fuck that and fuck them for suggesting it. Do they even understand what running linux means?
Why ? These are features that are built into linux. Source code you can audit.
Having a "signed gaming kernel" doesn't mean you are running arbitrary kernel level code. You'll always have the source code and can check it matches what you run.