Rendered at 00:55:56 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
ashpool37 1 hours ago [-]
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.
Terr_ 20 minutes ago [-]
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.
ashpool37 30 minutes ago [-]
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.
waterTanuki 11 minutes ago [-]
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.
Terr_ 4 minutes ago [-]
[delayed]
tfrancisl 9 hours ago [-]
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).
pjmlp 9 hours ago [-]
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.
tfrancisl 8 hours ago [-]
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.
pjmlp 8 hours ago [-]
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.
deathsentience 2 hours ago [-]
Valves failure? Didn’t realize they were done trying.
tfrancisl 8 hours ago [-]
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.
anthk 2 hours ago [-]
Today you can find recompilations for everything.
ChocolateGod 8 hours ago [-]
> 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.
tfrancisl 7 hours ago [-]
> 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.
jasomill 1 hours ago [-]
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.
tuna74 6 hours ago [-]
If you don't want to use this then it really does not matter to you. Or am I missing something?
tuna74 6 hours ago [-]
"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.
kyxsc 6 hours ago [-]
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.
tancop 7 hours ago [-]
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.
Archit3ch 7 hours ago [-]
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.
jasomill 1 hours ago [-]
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.
tfrancisl 7 hours ago [-]
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.
Archit3ch 6 hours ago [-]
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.
tfrancisl 6 hours ago [-]
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.
tapoxi 7 hours ago [-]
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.
tfrancisl 7 hours ago [-]
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.
not_a9 7 hours ago [-]
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
tfrancisl 6 hours ago [-]
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!
not_a9 6 hours ago [-]
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
ronsor 7 hours ago [-]
All of this will defeated by one of the now regular Linux LPEs anyway.
tfrancisl 7 hours ago [-]
No, LPEs escalate you to root. Root access is specifically protected against by their requirements.
ronsor 2 hours ago [-]
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.
not_a9 6 hours ago [-]
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.
jasomill 1 hours ago [-]
I for one have no problem with cheat/anticheat developers discovering/patching Linux vulnerabilities that could otherwise be exploited in far more dangerous capacities.
Retr0id 6 hours ago [-]
Good LPEs escalate you to kernel (which is true for most exploitable kernel bugs).
water-drummer 7 hours ago [-]
> 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.
tfrancisl 7 hours ago [-]
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.
water-drummer 7 hours ago [-]
> 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.
iugtmkbdfil834 1 hours ago [-]
<< 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.
tancop 7 hours ago [-]
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.
pjmlp 10 hours ago [-]
Looking at those requirements, I doubt this will ever get that much adoption.
tfrancisl 9 hours ago [-]
And luckily, according to the article, Valve has no immediate intention of getting the Steam Deck to meet those requirements.
theevilsharpie 8 hours ago [-]
> 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.
wildzzz 7 hours ago [-]
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.
tfrancisl 7 hours ago [-]
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...
samgranieri 7 hours ago [-]
Yeah, the arch omission is a bit telling.
pjmlp 9 hours ago [-]
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?
ChocolateGod 8 hours ago [-]
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.
tfrancisl 7 hours ago [-]
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.
pjmlp 7 hours ago [-]
Yes, but that alone doesn't prevent the cheats, because you get developer access.
sylens 8 hours ago [-]
It's clearly targeted at Linux servers for cloud gaming
tancop 7 hours ago [-]
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.
novafunc 2 hours ago [-]
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.
tfrancisl 7 hours ago [-]
Now you're thinking like ... NVIDIA circa 2015 or something like that
aniceperson 3 hours ago [-]
the era of dual booting linux signed and linux unsigned has started...
Archit3ch 2 hours ago [-]
Always has been. Your signed Android can open banking apps.
Retr0id 6 hours ago [-]
Very exciting, I've been looking for a fun target to demo my attestation bypass techniques against.
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.
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.
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 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.
> 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.
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.
Because otherwise you can cheat of course. You can code in whatever you want in your own Linux.
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.
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.
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.
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.
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
Userspace bugs is where I’d look first.
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.
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.
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.
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.
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.
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?
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.
Stadia used Linux and they never had anti-cheat.