The quiet part needs to be said out loud: ensuring "fairness" in online games and letting clients meaningfully remain in control over their hardware and software are two fundamentally incompatible goals. One goal puts the interests of the game publisher and community first, the other upholds the individual clients' interests.
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.
I think it's for the best to just accept that retaining control over your machine is just incompatible with the competitive online gaming, and that's fine. There is plenty of gaming to be had that isn't competitive, and/or isn't online.
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.
In my mind these two worlds don't have to be incompatible with each other, I am fully aware of the issues with cheating in competitive online gaming and am ready to give up some freedoms to improve the quality of my experience, but I believe we can do this still using Linux clients.
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.
> 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.
Right, because they warranted EAC’s Linux offering as insufficient for protecting their titles from cheaters.
The proposed solution from Epic would resolve that.
If it were just used for e-sports or online multiplayer situations, I'd be fine, but there is nothing to keep game developers from using this for single player or multiplayer with friends as well, all in the name of "protecting revenue streams"...
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 feel this is incomplete because it omits some cases where the publisher is the "bad guy" and their interests oppose the community.
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.
Absolutely. This ties in to the whole Stop Killing Games saga, and my comment was long enough. Suffice it to say widespread push of cryptographically locked-down gaming clients and distros will not make that battle any easier for the little guy in the Linux world.
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.
> 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."
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.
Sorry, I don't see your point. There are plenty of mods that require modification of both the server and the client software, e.g. if new items or game modes are added and the client needs to be able to recognize them. As long as all players on a server agree on the acceptable configurations of both, I don't see why they shouldn't be allowed to implement it for their own community.
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.
> When the mod must be loaded & run on the server's end
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]
It looks like we are not talking about the same things. you are talking about a casual minecraft server where a group of user want to mod their experience and the person you are replying with is talking about CSGO or League of Legends where only one environnement is tolerated (the one created with the publisher) and custom experience are not tolerated because its virtually identical to a cheating attempt
> ensuring "fairness" in online games and letting clients meaningfully remain in control over their hardware and software are two fundamentally incompatible goals
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
> The quiet part needs to be said out loud: ensuring "fairness" in online games and letting clients meaningfully remain in control over their hardware and software are two fundamentally incompatible goals. One goal puts the interests of the game publisher and community first, the other upholds the individual clients' interests.
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.
This fairness vs hardware control dichotomy isn't unsolvable. I believe that I have personally found an extremely good technical solution to this problem which will debut in my upcoming FPS game supporting the browser and other platforms, allowing things like reliable client-side anti-ESP (yes you heard that right).
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.
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.
The only proper answer is retroactive bans (a-la competitive doping: "retrospective testing").
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.
The consequences are all the more worrisome if you suppose this arrangement is able to gain any real traction as proposed.
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.
You're right that these two goals are fundamentally incompatible, which means the only possible solution is to remove the clients' hardware from the equation for online competitive games.
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.
For sure, the solution sounds in line with the interests of users who really want to play the protected games, more so than any alternative I can think of right now. I'm supportive of people who will knowingly make this trade-off, especially if they are patient/resourceful enough to maintain a separate gaming environment.
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.
Cloud gaming is incompatible with any online competitive game because it adds additional latency that simply feels bad for the user. Console-esque locked down systems are the only real solution
> the only possible solution is to remove the clients' hardware from the equation for online competitive games.
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.
Cloud gaming is a big inspiration for some of my own innovations indeed. But why run expensive server-side GPUs and stream video over the Internet when you don't have to, and can still get the same anti-cheat properties? :)
Many, many issues with the requirements here that essentially make this unusable for most Linux users. I really hope they don't force current EAC games to upgrade. I would also love to see companies like this actual give behavior-based AC the college try before resorting to shipping spyware.
> 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).
When I used Arch I had full secure boot set up. Making a second kernel image with the Epic required settings is not hard.
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.
"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?"
Because otherwise you can cheat of course. You can code in whatever you want in your own Linux.
Right, well, for me I ditched Windows entirely because every serious development workflow is way more involved and complex, performance is really poor, random weird bugs after mandated updates, and so on. The cherry on top is all of Valve and the open source folks work on Proton and gaming on Linux in general.
All good and dandy, except Valve's failure to have studios target Linux, including games that already make use of compatible APIs, like those using Android NDK.
Thus Proton depends on Windows as source ecosystem, only yet another platform to "emulate" on Linux, like MAME, Amiga, Playstation, whatever.
I can't disagree with that, of course. I can only point to Valve at least shipping their games (notably CS2 and Deadlock) native, and the overall improvement in the performance and ergonomics of Proton in the past decade.
I play online games and i hate cheaters. Like they said, cheats are a huge industry now with talented people working hard on them. This is what it takes to stop them.
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.
True, and at least until the new scheme supports Steam hardware, it's unlikely that vendors that support user-mode EAC today will move to require kernel EAC tomorrow, since I assume Steam Deck users represent the majority of their Linux player base.
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.
If this were about solely myself and no one else, I might agree. However, even I do play one or two games that use EAC v1 and they work perfectly fine on Linux. They also have very few cheaters, and employ behavior-based detection as their first line. I would hate to lose those games.
Games have already begun to remove Linux support, most notably Apex Legends and Wardogs. Embark (The Finals, Arc Raiders) recently gave a talk that userspace anti-cheat is dead and they plan to enforce similar requirements.
And it's all a shame, in my opinion. They're too lazy to develop effective behavior-based anticheat (should be easier than ever with better NN architectures and more compute), and so they resolve to screwing over consumers or spying on them. Did not know about Embark's stance, that's too bad.
How is Valve’s VACNET doing? I think you should take a look at what’s happening in Counter-Strike 2 these days to see what the true frontier of ML based anticheat looks like.
Frankly at this point I’m pretty sure John McDonald plays HvH too
I play CS2 plenty. The cheating problem is overstated as all hell. It seems to be concentrated around accounts that are being sold for lots of cash, so Valve is apparently taking that route for banning accounts more often lately.
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!
What ranks are you playing on? While a player of any rank can buy Neverlose and win and if they wanna just pwn cleans they can buy Midnight (speaking of buying P2Cs: if Faceit is apparently riddled with cheaters, where can I buy a P2C that I can pwn on Faceit with for an affordable price?), said cyber athletes will naturally gravitate towards higher ranks.
> 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
I haven't kept up with mainstream gaming in a while. IIRC, EAC v1 doesn't require TPM 2.0 and thus is security theater, right? An attacker could just tamper the binary.
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.
I would argue TPM 2.0 is the security theater. A leaked key is all it takes to throw it all away. EAC v1 combined with behavior-based detection seems to be sufficient for some of these studios, so I don't know what Epic is struggling with.
There is news - from 2h ago - talking about Fortnite and EAC userspace coming to Linux soon. As someone not too knowledgeable on Linux kernel anti-cheat games, I wonder: is this big news or just a farce?
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.
> 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?
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.
> Because your kernel could have the ability to allow a program to modify the game memory and hide the fact it's doing so?
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.
Anticheat that allows an unsigned kernel is equivalent to user-mode only anticheat, which is already an opt-in feature of Easy Anti-Cheat.
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.
Most likely there’ll be lots more hunting for physmem read/write vulnerabilities as well as bugs in userspace stuff like GUI whatsits that’d give code execution/memory readwrite.
I for one have no problem with cheat/anticheat developers discovering/patching Linux vulnerabilities that could otherwise be exploited in far more dangerous capacities.
LPEs are usually used to escalate to root, but in many of them, the kernel itself is compromised. There's just little reason to do stuff in kernel space when you can get root and load kernel modules anyway.
> 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?
So you can't compile cheats into your kernel? You want your own custom compiled kernel for hypothetical 2℅ performance gains in a synthetic benchmark? Just don't boot into it when you wanna play the game.
> Also all impractical for most linux users.
You don't represent "most" linux users. Define impracticality here because these are genuinely useful security features that you ideally should have even if you don't wanna play Fortnite.
> You may not spy on my memory, thank you very much. What's stopping Epic from taking snapshots and phoning home?
The fact that it would be a huge legal and PR nightmare for them upon getting caught which is very much in the realm of possibilities given the fact that it's not hard to tell if some eBPF byte code is doing that especially with LLMs making it a 100x easier nowadays.
> Preventing root from doing root things for the sake of it. I mean, maybe this makes sense.
Just don't boot into the kernel you want to tamper with when you want to play an EAC game. Problem solved
> 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).
You just made that up in your head. You can install a kernel that EAC will accept into any of these distros. Oh, and, did you just say most gamers in the online spaces you frequent use Arch, Gentoo and NixOS? I can buy Arch, sure, but NixOS? and especially Gentoo?! I guess that explains your comment and gives me context on why you decided to write what you have written. You're far from "most" linux users, buddy. Most people don't care if they've haven't hand-compiled their own kernel on the back of a notebook they bought in 1998. I myself use Arch and if I ever want to play such a game, I'll just boot into a kernel that has been signed by a key that EAC accepts and won't go around whining that Arch maintainers are bad or anything.
This is a good thing but I guess it takes time to let the copium wear off that a lot of neck beard linux users kept sniffing over the years when they couldn't find a good answer for people not wanting to switch because their favorite game wouldn't run by calling literally any closed source code running below ring 0, "rootkit" as if their UEFI and firmware is GPL licensed.
You could have just not replied if you werent going to try to be productive. Yes, lots and lots of people play video games on NixOS and Gentoo. Who is playing video games on Fedora, Debian? I dont care that I can switch kernels, I shouldnt have to.
> You could have just not replied if you werent going to try to be productive.
I could say the same about you cause you didn't bother explaining why a bunch of security features were impractical for most people.
> Yes, lots and lots of people play video games on NixOS and Gentoo. Who is playing video games on Fedora, Debian?
I think we might be having a case of a bubble here. I suggest looking into Steam survey results. Also, you said "most" people not "lots" so you're now backpedaling on your claim.
> I dont care that I can switch kernels, I shouldnt have to.
You're right, in fact, in an ideal world, you shouldn't even have to install the anti-cheat as everyone plays nicely and nobody cheats. Unfortunately, we don't live in that world.
You still don't have to switch your kernels or install the AC by simply not choosing to install the game if you think them not trusting random kernels to be free of cheats is unreasonable of them.
<< I could say the same about you cause you didn't bother explaining why a bunch of security features were impractical for most people.
Well, that part is simple: 'security features' is a nice way of saying 'your rights as an administrator are restricted'. In other words, it is not the security of the end user, but rather some major corporation. And it is not even even real security.. it is financial security. It is not that just that it is impractical; that is not even a consideration here: it is dumb for me to artificially restrict myself from being able to do things as I see fit on my machine.
<< I think we might be having a case of a bubble here. I suggest looking into Steam survey results. Also, you said "most" people not "lots" so you're now backpedaling on your claim.
Eh, I am on those Steam charts and I am shown as Windows 7 user for some games. Do you really think those are that accurate to begin with?
<< You still don't have to switch your kernels or install the AC by simply not choosing to install the game if you think them not trusting random kernels to be free of cheats is unreasonable of them.
Or, alternatively, ostracize anyone who would consider shilling, installing, or even maintaining this unholy abomination.
I like that they went with the obvious best solution, combining all the existing security features instead of making a closed source kernel module. I thought about this problem many times ever since I first used Proton, and I wouldn't have implemented it any other way.
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.
Closed source eBPF code is somewhat similar to a closed source kernel module, just one that doesn't need to be recompiled for every kernel version and cpu architecture. Good luck figuring out what it's going to be doing.
eBPF is a very restrictive format. It's closer to .NET bytecode (trivial to decompile) than native machine code and the verifier sets strict limits to prevent things like unbounded loops. That makes any obfuscation a lot weaker.
> And luckily, according to the article, Valve has no immediate intention of getting the Steam Deck to meet those requirements.
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.
Arch-based doesn't mean EA needs to use the kernel that the Archlinux devs sign. I'm sure Valve compiles their own kernel and would eventually sign it using their own key.
I suppose I read into the Steam Deck not supporting all of the requirements right now a bit much. Thats the section I was referencing. I am still hopeful they'll at least object to IOMMU and get some movement from Epic there...
Cloud gaming servers don't need any of this because you know exactly what OS runs on them. No root access, immutable file system and all dangerous tools stripped out. All you have to do is validate the image with the simplest form of hardware attestation.
And Cloud gaming only gives you a video and audio stream. Cheats cannot peek into the game to reveal information. They can only see and hear what you see and hear and control input devices.
Aside from the fact that this is obviously not true (secure boot is possible on Linux, limine/lanzaboote come to mind), I would argue these security modules / attestations do very little for security and are more about lock in and control.
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.
> Aside from the fact that this is obviously not true (secure boot is possible on Linux, limine/lanzaboote come to mind)
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.
I feel this might be the beginning of a new trend: With software becoming more malleable due to coding agents that can do reverse engineering, I could imagine that software companies in general, not just for games, will increasingly try to lock down distribution channels.
If you cannot control anymore what is being built, the desperation to try and control what is being run will only become larger.
eBPF programs do run at kernel level, but don't have the same full access that a kernel driver would have, they are limited to the APIs that are available for the subsystem they are loaded for. And they can (usually) be unloaded.
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.
It's rather awkward to me because it runs almost entirely through userspace or eBPF. Both of which are trivial to spoof and bypass.
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.
Meanwhile I'm over here probably wanting to play offline solo games I can "cheat" more in (sometimes unlimited health is a fun feature or other "cheat codes")
> We will bring the level of protection much closer to par with Windows, in the very near-term, using existing Linux features including signed kernel, signed kernel modules, and secure boot with attestation.
Yeah fuck that and fuck them for suggesting it. Do they even understand what running linux means?
The quiet part needs to be said out loud: ensuring "fairness" in online games and letting clients meaningfully remain in control over their hardware and software are two fundamentally incompatible goals. One goal puts the interests of the game publisher and community first, the other upholds the individual clients' interests.
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.
I think it's for the best to just accept that retaining control over your machine is just incompatible with the competitive online gaming, and that's fine. There is plenty of gaming to be had that isn't competitive, and/or isn't online.
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.
In my mind these two worlds don't have to be incompatible with each other, I am fully aware of the issues with cheating in competitive online gaming and am ready to give up some freedoms to improve the quality of my experience, but I believe we can do this still using Linux clients.
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.
> 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.
Right, because they warranted EAC’s Linux offering as insufficient for protecting their titles from cheaters.
The proposed solution from Epic would resolve that.
No, it did not. Their own graph even shows it. The downward trajectory in infected matches was ongoing before they made the flip
If it were just used for e-sports or online multiplayer situations, I'd be fine, but there is nothing to keep game developers from using this for single player or multiplayer with friends as well, all in the name of "protecting revenue streams"...
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 feel this is incomplete because it omits some cases where the publisher is the "bad guy" and their interests oppose the community.
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.
Absolutely. This ties in to the whole Stop Killing Games saga, and my comment was long enough. Suffice it to say widespread push of cryptographically locked-down gaming clients and distros will not make that battle any easier for the little guy in the Linux world.
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.
> 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."
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.
Sorry, I don't see your point. There are plenty of mods that require modification of both the server and the client software, e.g. if new items or game modes are added and the client needs to be able to recognize them. As long as all players on a server agree on the acceptable configurations of both, I don't see why they shouldn't be allowed to implement it for their own community.
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.
> When the mod must be loaded & run on the server's end
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...
It looks like we are not talking about the same things. you are talking about a casual minecraft server where a group of user want to mod their experience and the person you are replying with is talking about CSGO or League of Legends where only one environnement is tolerated (the one created with the publisher) and custom experience are not tolerated because its virtually identical to a cheating attempt
yes monetizing a video game (or any piece of software) is almost always opposed to allowing the user to freely modify the software
> ensuring "fairness" in online games and letting clients meaningfully remain in control over their hardware and software are two fundamentally incompatible goals
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
> The quiet part needs to be said out loud: ensuring "fairness" in online games and letting clients meaningfully remain in control over their hardware and software are two fundamentally incompatible goals. One goal puts the interests of the game publisher and community first, the other upholds the individual clients' interests.
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.
This fairness vs hardware control dichotomy isn't unsolvable. I believe that I have personally found an extremely good technical solution to this problem which will debut in my upcoming FPS game supporting the browser and other platforms, allowing things like reliable client-side anti-ESP (yes you heard that right).
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.
If a client sends its game inputs and those inputs can be analyzed for legitimacy, I think you could make some decent progress on this problem.
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?
I think so, to various degrees, and increasing in sophistication over time.
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.
The only proper answer is retroactive bans (a-la competitive doping: "retrospective testing").
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.
The consequences are all the more worrisome if you suppose this arrangement is able to gain any real traction as proposed.
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.
You're right that these two goals are fundamentally incompatible, which means the only possible solution is to remove the clients' hardware from the equation for online competitive games.
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.
For sure, the solution sounds in line with the interests of users who really want to play the protected games, more so than any alternative I can think of right now. I'm supportive of people who will knowingly make this trade-off, especially if they are patient/resourceful enough to maintain a separate gaming environment.
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.
Cloud gaming is incompatible with any online competitive game because it adds additional latency that simply feels bad for the user. Console-esque locked down systems are the only real solution
> the only possible solution is to remove the clients' hardware from the equation for online competitive games.
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.
Cloud gaming is a big inspiration for some of my own innovations indeed. But why run expensive server-side GPUs and stream video over the Internet when you don't have to, and can still get the same anti-cheat properties? :)
Many, many issues with the requirements here that essentially make this unusable for most Linux users. I really hope they don't force current EAC games to upgrade. I would also love to see companies like this actual give behavior-based AC the college try before resorting to shipping spyware.
> 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).
When I used Arch I had full secure boot set up. Making a second kernel image with the Epic required settings is not hard.
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.
"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?"
Because otherwise you can cheat of course. You can code in whatever you want in your own Linux.
Even on Windows I don't install such games.
There are so many to chose from, even retrogaming content is more than I can play during my remaining lifetime.
Right, well, for me I ditched Windows entirely because every serious development workflow is way more involved and complex, performance is really poor, random weird bugs after mandated updates, and so on. The cherry on top is all of Valve and the open source folks work on Proton and gaming on Linux in general.
All good and dandy, except Valve's failure to have studios target Linux, including games that already make use of compatible APIs, like those using Android NDK.
Thus Proton depends on Windows as source ecosystem, only yet another platform to "emulate" on Linux, like MAME, Amiga, Playstation, whatever.
I can't disagree with that, of course. I can only point to Valve at least shipping their games (notably CS2 and Deadlock) native, and the overall improvement in the performance and ergonomics of Proton in the past decade.
Valves failure? Didn’t realize they were done trying.
They've been going at it for what, 16 years now, and game publishers haven't played ball.
Windows is just that much better for game devs.
Today you can find recompilations for everything.
I play online games and i hate cheaters. Like they said, cheats are a huge industry now with talented people working hard on them. This is what it takes to stop them.
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.
Before: it wasn't possible to run these specific games that require this competitive anti-cheat on Linux.
So you can ignore the newly-enabled games in this proposal and you're not missing anything you had previously.
True, and at least until the new scheme supports Steam hardware, it's unlikely that vendors that support user-mode EAC today will move to require kernel EAC tomorrow, since I assume Steam Deck users represent the majority of their Linux player base.
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.
If this were about solely myself and no one else, I might agree. However, even I do play one or two games that use EAC v1 and they work perfectly fine on Linux. They also have very few cheaters, and employ behavior-based detection as their first line. I would hate to lose those games.
Games have already begun to remove Linux support, most notably Apex Legends and Wardogs. Embark (The Finals, Arc Raiders) recently gave a talk that userspace anti-cheat is dead and they plan to enforce similar requirements.
And it's all a shame, in my opinion. They're too lazy to develop effective behavior-based anticheat (should be easier than ever with better NN architectures and more compute), and so they resolve to screwing over consumers or spying on them. Did not know about Embark's stance, that's too bad.
How is Valve’s VACNET doing? I think you should take a look at what’s happening in Counter-Strike 2 these days to see what the true frontier of ML based anticheat looks like.
Frankly at this point I’m pretty sure John McDonald plays HvH too
I play CS2 plenty. The cheating problem is overstated as all hell. It seems to be concentrated around accounts that are being sold for lots of cash, so Valve is apparently taking that route for banning accounts more often lately.
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!
What ranks are you playing on? While a player of any rank can buy Neverlose and win and if they wanna just pwn cleans they can buy Midnight (speaking of buying P2Cs: if Faceit is apparently riddled with cheaters, where can I buy a P2C that I can pwn on Faceit with for an affordable price?), said cyber athletes will naturally gravitate towards higher ranks.
> 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
I haven't kept up with mainstream gaming in a while. IIRC, EAC v1 doesn't require TPM 2.0 and thus is security theater, right? An attacker could just tamper the binary.
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.
I would argue TPM 2.0 is the security theater. A leaked key is all it takes to throw it all away. EAC v1 combined with behavior-based detection seems to be sufficient for some of these studios, so I don't know what Epic is struggling with.
There is news - from 2h ago - talking about Fortnite and EAC userspace coming to Linux soon. As someone not too knowledgeable on Linux kernel anti-cheat games, I wonder: is this big news or just a farce?
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.
> 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?
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.
> Because your kernel could have the ability to allow a program to modify the game memory and hide the fact it's doing so?
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.
Anticheat that allows an unsigned kernel is equivalent to user-mode only anticheat, which is already an opt-in feature of Easy Anti-Cheat.
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.
SteamOS doesn't support secure boot, that's probably why.
If you don't want to use this then it really does not matter to you. Or am I missing something?
All of this will defeated by one of the now regular Linux LPEs anyway.
No, LPEs escalate you to root. Root access is specifically protected against by their requirements.
Most likely there’ll be lots more hunting for physmem read/write vulnerabilities as well as bugs in userspace stuff like GUI whatsits that’d give code execution/memory readwrite.
Userspace bugs is where I’d look first.
I for one have no problem with cheat/anticheat developers discovering/patching Linux vulnerabilities that could otherwise be exploited in far more dangerous capacities.
LPEs are usually used to escalate to root, but in many of them, the kernel itself is compromised. There's just little reason to do stuff in kernel space when you can get root and load kernel modules anyway.
Good LPEs escalate you to kernel (which is true for most exploitable kernel bugs).
> 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?
So you can't compile cheats into your kernel? You want your own custom compiled kernel for hypothetical 2℅ performance gains in a synthetic benchmark? Just don't boot into it when you wanna play the game.
> Also all impractical for most linux users.
You don't represent "most" linux users. Define impracticality here because these are genuinely useful security features that you ideally should have even if you don't wanna play Fortnite.
> You may not spy on my memory, thank you very much. What's stopping Epic from taking snapshots and phoning home?
The fact that it would be a huge legal and PR nightmare for them upon getting caught which is very much in the realm of possibilities given the fact that it's not hard to tell if some eBPF byte code is doing that especially with LLMs making it a 100x easier nowadays.
> Preventing root from doing root things for the sake of it. I mean, maybe this makes sense.
Just don't boot into the kernel you want to tamper with when you want to play an EAC game. Problem solved
> 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).
You just made that up in your head. You can install a kernel that EAC will accept into any of these distros. Oh, and, did you just say most gamers in the online spaces you frequent use Arch, Gentoo and NixOS? I can buy Arch, sure, but NixOS? and especially Gentoo?! I guess that explains your comment and gives me context on why you decided to write what you have written. You're far from "most" linux users, buddy. Most people don't care if they've haven't hand-compiled their own kernel on the back of a notebook they bought in 1998. I myself use Arch and if I ever want to play such a game, I'll just boot into a kernel that has been signed by a key that EAC accepts and won't go around whining that Arch maintainers are bad or anything.
This is a good thing but I guess it takes time to let the copium wear off that a lot of neck beard linux users kept sniffing over the years when they couldn't find a good answer for people not wanting to switch because their favorite game wouldn't run by calling literally any closed source code running below ring 0, "rootkit" as if their UEFI and firmware is GPL licensed.
You could have just not replied if you werent going to try to be productive. Yes, lots and lots of people play video games on NixOS and Gentoo. Who is playing video games on Fedora, Debian? I dont care that I can switch kernels, I shouldnt have to.
> You could have just not replied if you werent going to try to be productive.
I could say the same about you cause you didn't bother explaining why a bunch of security features were impractical for most people.
> Yes, lots and lots of people play video games on NixOS and Gentoo. Who is playing video games on Fedora, Debian?
I think we might be having a case of a bubble here. I suggest looking into Steam survey results. Also, you said "most" people not "lots" so you're now backpedaling on your claim.
> I dont care that I can switch kernels, I shouldnt have to.
You're right, in fact, in an ideal world, you shouldn't even have to install the anti-cheat as everyone plays nicely and nobody cheats. Unfortunately, we don't live in that world.
You still don't have to switch your kernels or install the AC by simply not choosing to install the game if you think them not trusting random kernels to be free of cheats is unreasonable of them.
<< I could say the same about you cause you didn't bother explaining why a bunch of security features were impractical for most people.
Well, that part is simple: 'security features' is a nice way of saying 'your rights as an administrator are restricted'. In other words, it is not the security of the end user, but rather some major corporation. And it is not even even real security.. it is financial security. It is not that just that it is impractical; that is not even a consideration here: it is dumb for me to artificially restrict myself from being able to do things as I see fit on my machine.
<< I think we might be having a case of a bubble here. I suggest looking into Steam survey results. Also, you said "most" people not "lots" so you're now backpedaling on your claim.
Eh, I am on those Steam charts and I am shown as Windows 7 user for some games. Do you really think those are that accurate to begin with?
<< You still don't have to switch your kernels or install the AC by simply not choosing to install the game if you think them not trusting random kernels to be free of cheats is unreasonable of them.
Or, alternatively, ostracize anyone who would consider shilling, installing, or even maintaining this unholy abomination.
I like that they went with the obvious best solution, combining all the existing security features instead of making a closed source kernel module. I thought about this problem many times ever since I first used Proton, and I wouldn't have implemented it any other way.
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.
You can't easily make a closed source kernel module due to the GPL.
Many Linux drivers (ethernet, gfx, wifi) use closed source binary blobs. Linus has said many times that he is fine with it.
EDIT: More info here: https://lwn.net/Articles/13398/
Closed source eBPF code is somewhat similar to a closed source kernel module, just one that doesn't need to be recompiled for every kernel version and cpu architecture. Good luck figuring out what it's going to be doing.
eBPF is a very restrictive format. It's closer to .NET bytecode (trivial to decompile) than native machine code and the verifier sets strict limits to prevent things like unbounded loops. That makes any obfuscation a lot weaker.
Looking at those requirements, I doubt this will ever get that much adoption.
And luckily, according to the article, Valve has no immediate intention of getting the Steam Deck to meet those requirements.
> And luckily, according to the article, Valve has no immediate intention of getting the Steam Deck to meet those requirements.
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.
Arch-based doesn't mean EA needs to use the kernel that the Archlinux devs sign. I'm sure Valve compiles their own kernel and would eventually sign it using their own key.
I suppose I read into the Steam Deck not supporting all of the requirements right now a bit much. Thats the section I was referencing. I am still hopeful they'll at least object to IOMMU and get some movement from Epic there...
Yeah, the arch omission is a bit telling.
Arch doesn't sign their kernels but SteamOS it not Arch.
The thing is, Android, iDevices don't do kernel drivers for apps.
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?
It's clearly targeted at Linux servers for cloud gaming
Cloud gaming servers don't need any of this because you know exactly what OS runs on them. No root access, immutable file system and all dangerous tools stripped out. All you have to do is validate the image with the simplest form of hardware attestation.
Stadia used Linux and they never had anti-cheat.
And Cloud gaming only gives you a video and audio stream. Cheats cannot peek into the game to reveal information. They can only see and hear what you see and hear and control input devices.
Now you're thinking like ... NVIDIA circa 2015 or something like that
iOS and Android both have remote attestation services and security coprocessors you can use to establish the integrity of the booted environment.
Desktop Linux has none of that.
Aside from the fact that this is obviously not true (secure boot is possible on Linux, limine/lanzaboote come to mind), I would argue these security modules / attestations do very little for security and are more about lock in and control.
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.
> Aside from the fact that this is obviously not true (secure boot is possible on Linux, limine/lanzaboote come to mind)
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
Yes, but that alone doesn't prevent the cheats, because you get developer access.
Very exciting, I've been looking for a fun target to demo my attestation bypass techniques against.
I feel this might be the beginning of a new trend: With software becoming more malleable due to coding agents that can do reverse engineering, I could imagine that software companies in general, not just for games, will increasingly try to lock down distribution channels.
If you cannot control anymore what is being built, the desperation to try and control what is being run will only become larger.
the era of dual booting linux signed and linux unsigned has started...
Always has been. Your signed Android can open banking apps.
> Does EAC Linux v2 use a kernel driver?
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...
eBPF programs do run at kernel level, but don't have the same full access that a kernel driver would have, they are limited to the APIs that are available for the subsystem they are loaded for. And they can (usually) be unloaded.
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.
It's rather awkward to me because it runs almost entirely through userspace or eBPF. Both of which are trivial to spoof and bypass.
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.
Meanwhile I'm over here probably wanting to play offline solo games I can "cheat" more in (sometimes unlimited health is a fun feature or other "cheat codes")
Vote with your wallet peeps
> We will bring the level of protection much closer to par with Windows, in the very near-term, using existing Linux features including signed kernel, signed kernel modules, and secure boot with attestation.
Yeah fuck that and fuck them for suggesting it. Do they even understand what running linux means?
No arch?
un acc epti cal