Comment by hebejebelus
4 hours ago
Very interesting! The one killer issue that jumps to mind is anti-cheat. I switched away from gaming on Linux via Proton to gaming on Windows because Battlefield 6's anti-cheat won't work under Proton. Many games are like this, particularly some of the most popular (Rainbow 6 Siege for instance). And BF6 made this decision only recently despite the growing number of Steam Deck players (and other players on linux - in fairness I don't think there would have been that many BF6 players on a handheld).
Edit: I specifically use a gaming-only PC. The hardware is used for nothing else. Hence, discussions of rootkits don't really bother me personally much and on balance I'd really rather see fewer cheaters in my games. I think it would be the same with any of these machines - anything Steam-branded is likely to be a 99% gaming machine and their users will only care that their games work, not about the mechanisms of the anti-cheat software.
I view it as Valve is doing me a favor by adding friction towards me installing a rootkit to play video games.
There's also been numerous userspace ACs that work well and also run in userspace (EAC, Battleye, etc.) that have been enabled for Linux/Proton users (including by EA with Apex Legends at one point). A lot of the support for Linux mostly comes down to the developer/publishers not wanting to and not because of technical reasons.
Perhaps a trusted execution environment based anti-cheat system could be possible.
I think Valve said something about working with anti-cheat developers to find a solution for the Steam Deck, but nothing happened. Perhaps they will do something this time.
With a TEE, you could scan the system or even completely isolate your game, preventing even the OS from manipulating it. As a last resort, you could simply blacklist the machine if cheats are detected.
There would probably still be some cheaters, but the numbers would be so low as to not be a problem.
This is a issue of critical mass. With the continued growth of steamos, steamdeck, and linux as a game platform, eventually it will pull over support.
I have to wonder if it's possible to ever even guarantee something that can't be trivially bypassed on Linux - Windows, sure, it's possible with DMA, but it's damn hard. On Linux you could just compile a spoofed kernel or a DKMS module or something.
Look at android, locked bootloader, no root, se linux, and voila
1 reply →
you can make a signed readonly linux installation, and restrict your games to it. this would be like "support steamos but not linux".
Or deliver the game as a container format, like snap or appimage to bypass most of the system.
Or demand the installation of a kernel driver like they do on windows.
or just give up on kernel level aticheat since they're been breached all the same, just as windows are restricting their power too.
easy-anticheat has a linux version. Developers have to disable the support intentionally.
is it not possible for someone to have Linux spoof that it's Windows to the game?
It's worse than that, BF6's anticheat is kernel level and requires the Windows-only version secure boot to be enabled, at least on my motherboard. There is no way I'm going to faff about with my BIOS when rebooting just to play this game.
Same. I mainline Destiny2 (well, a bit less these days), and Bungie won't support Linux/Steam Deck because they depend on BattlEye kernel anti-cheat.
(and yet still have a problem with cheaters, see all the bans following the Desert Perpetual raid race)
Looking at the specs and marketing copy, it sounds to me like you could secure boot windows 11 on this machine.
> ... a discrete semi-custom AMD desktop class CPU and GPU.
> Yes, Steam Machine is optimized for gaming, but it's still your PC. Install your own apps, or even another operating system. Who are we to tell you how to use your computer?
Do we know what kernel SteamOS uses? Is it built on linux, or could it be some sort of kiosk'd mode Windows where this will be a non-issue? One could hope but I truly don't know.
SteamOS on the Deck is just a standard (tuned) Linux distribution under the hood. It would be very surprising to me if Valve shifted to an entirely different OS for the Cube.
All Valve has to do is say “Your software cannot deliberately exclude linux support including kernel anti-cheat to be listed on Steam.” And that would be that, the few devs big enough to make it on their own would leave, and everyone else would adapt.
Worth noting: Valve’s own first party tournaments for their own game require kernel level anti-cheat (from a third party vendor). Valve themselves have given up on allowing players in their own title play competitively in a Valve sponsored event with a kernel level anti-cheat. I can’t imagine they’d ever be this brash.
There is no adapting without a proper solution for securing game integrity.
[dead]
The games would just leave Steam. The big publishers want their own platforms and launchers anyway.
The big publishers already have their own launcher and platforms and are increasingly moving back onto Steam because they see higher PC player counts and sales when their games are there
That's not the trend that we're observing. As much as publishers and developers want to control their sales channels, the current trend is for them to move towards Steam, not away from it.
The more likely outcome is that developers would segment matchmaking into people with kernel-level anti-cheat, and people without it. This seems fair to me.
1 reply →
Yeah, I would hope not. Trying to impose your will on suppliers and b2b customers like this is how you get hit with an antitrust lawsuit.
Is there an feasible alternative to "kernel anti-cheat" available on Linux?
There isn't.
When it comes to anti-cheat on Linux, it's basically an elephant in the room that nobody wants to address.
Anti-cheat on Linux would need root access to have any effectiveness. Alternatively, you'd need to be running a custom kernel with anti-cheat built into it.
This is the part of the conversation where someone says anti-cheat needs to be server-side, but that's an incredibly naive and poorly thought out idea. You can't prevent aim-bots server-side. You can't even detect aim-bots server-side. At best, you could come up with heuristics to determine if someone's possibly cheating, but you'd probably have a very hard time distinguishing between a cheater and a highly skilled player.
Something I think the anti-anti-cheat people fail to recognize is that cheaters don't care about their cheats requiring root/admin, which makes it trivial to evade anti-cheat that only runs with user-level permissions.
When it comes to cheating in games, there are two options:
1. Anti-cheat runs as admin/root/rootkit/SYSTEM/etc.
2. The games you play have tons of cheaters.
You can't have it both ways: No cheaters and anti-cheat runs with user-level permissions.
19 replies →
Today, no. Very simplified but the broad goal of those tools is to prevent manipulation and monitoring of the in-process state of the game. Consoles and PCs require this to varying degrees by requiring a signed boot chain at minimum. Consoles require a fully signed chain for every program, so you can't deploy a hacking tool anyway; no anti-cheat is needed. PCs can run unsigned and signed programs -- so instead they require the kernel at minimum to be signed & trusted, and then you put the anti-cheat system inside it so it cannot be interfered with. If you do not do this then there is basically no way to actually trust any claim the computer makes about its state. For PCs, the problem is you have to basically trust the anti-cheat isn't a piece of shit and thus have to trust both Microsoft and also random corporations. Also PCs are generally insecure anyway at the hardware level due to a number of factors, so it only does so much.
You could make a Linux distro with a signed boot chain and a kernel anti-cheat, then you'd mostly need to get developers on board with trusting that solution. Nobody is doing that today, even Valve.
Funny enough, macOS of all things is maybe "best" theoretical platform for all this because it does not require you to trust anyone beyond Apple. All major macOS programs are signed by their developers, so macOS as an OS knows exactly where each program came from. macOS can also attest that it is running in secure mode, and it can run a process at user-mode level such that it can't be interfered with by another process. So you could enforce a policy like this: if Battlefield6.app is launched, it cannot be examined by any other process, but likewise it may run in a full sandbox. Next, Battlefield6.app needs to login online, so it can ask macOS to provide an attestation saying it is running on genuine Apple hardware in secure mode, and then it could submit that attestation to EA which can validate it as genuine. Then the program launch is trusted. This setup requires you to only trust Apple security and that macOS is functioning correctly, not EA or whatever nor does it require actual anti-cheat mechanisms.