Comment by hebejebelus
3 months 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.
on the other hand you can't play any of the older battlefields due to cheating (not like "is he cheating?" more like blatant "this guy is speedhacking and heashotting everyone" cheating that the server could easily detect if they cared about it)
Is that the same Battlefields that removed support for private servers ?
There are hacks these days that sniff the pcie bus with an FPGA to mitm the ram, render out the game state, and render an overlay on top of the monitor.
It's a crazy arms race that IDK even kernel mode can compete with at the end of the day.
I think this shift away from community-led multiplayer is approaching a dead-end with respect to this hacking arms race.
Player bans and votekicks used to be so easy to do. And while there were some badmins, I argue it still resulted in an overall healthier multiplayer ecosystem.
OF course we know this shift is so the developer can control the game more tightly for monetization purposes. But i think the end result of this is more harm than good.
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
2 replies →
It doesn't have to be bypassed. Those same anti-cheats used by many unsupported titles are enabled for some games and work fine on Linux. So you just have to give the developers some incentive to enable it for their titles. It is a choice made by game developers. Currently they don't see a market on Linux/Steam OS but if Steam Machines become popular, potentially they would be missing a market and decide to join in.
2 replies →
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?
I sincerely hope it doesn't happen then. I'd rather have game developers come up with a different solution that is not a rootkit
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.
I don't know how EFI boot works but I am running a gaming PC in dual boot and I have both Microsoft and my own personal secure boot keys loaded (for linux and grub)
I boot my own signed bootloader (grub) from which I can also boot Windows. Windows shows it is in secure boot mode and it works fine with BF6 for me.
But I have a feeling this allows users to run some bootkit/rootkit and bypass any of those kernel level anti-cheats. Maybe I'm wrong and EFI handover to Windows clears all the memory, but I somehow doubt it.
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.
Maybe the user friction would be too much, but I'd be happy for the system to just straight up reboot for games which require anti cheat. So while that game is running, the system is in a verified state. But once you close the game all of your mods and custom drivers can be loaded just fine.
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?
I'd have Secure Boot, and then one root for an user-modifiable regular Linux installation, and another root that is read-only, signed, custom kernel etc.
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.
You clearly are very misinformed on how Valve operates and runs the competitive CS2 environment.
Valve does not require a Kernel Level Anti-Cheat for "first party" tournaments. It is not stipulated anywhere in the Major Rulebook: https://github.com/ValveSoftware/counter-strike_rules_and_re...
The reason third-party anti-cheats are commonplace at these events is because most tournaments opt to use Faceit or similar for game scheduling. This was the case before VRS (with RMRs) and the TO could choose an anti-cheat of their choosing. This always ended up being Faceit AC or whatever platform the matches are scheduled via (For example, PGL used Challenger Mode, which used Akros Anti-Cheat). ESL of course uses Faceit because (ESL Faceit Group).
You do not understand how Majors are run. It is very hands off from Valve. Only recently, with the introduction of VRS has Valve started controlling and implementing dedicated rules into the ecosystem for TOs.
1 reply →
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 →
Games can leave Steam, but whenever they do they run into the awkward issue that gamers aren't usually coming with them, at least not in numbers that justify trying to create your own thing.
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.
Ironically, this might create a perverse incentive to shift gamers to linux as all the hackers jump from windows to linux to take advantage of the lack of KMAC.
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.
24 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.
I wonder what ever happened to all those AI based anti-cheat solutions that I heard about. Was that last year maybe?
Even without anticheat, ProtonDB has a lot of "gold" ratings it really shouldn't; the comments explain the real experience. See BeamNG and AOE2:DE.
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.
Ahh cool, thanks
It is running Valve's immutable fork of Archlinux, you can find their source package mirror online.
Awesome, thanks!
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)
BattleEye is supported on Linux and Steam Deck, Bungie simply decided not to enable support for it. https://areweanticheatyet.com/?search=battleye&sortOrder=&so...