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.

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.

> 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?

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.

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.

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.

    > > TPM 2.0, Secure Boot, Measured Boot
    > Also all impractical for most linux users.

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.

All of this will defeated by one of the now regular Linux LPEs 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 can't easily make a closed source kernel module due to the GPL.

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.

And luckily, according to the article, Valve has no immediate intention of getting the Steam Deck to meet those requirements.

Always has been. Your signed Android can open banking apps.

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.