I can't wait until I am able to give random programs kernel access on my system! That doesn't sound problematic in the least! After all, I have the fullest confidence that for companies developing anticheat, my security is their highest concern! /s
Linux
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
I surely hope they never will, no user program should ever be allowed to run at kernel level, that's what malware does.
I personally avoid those kind of games, but those who won't can dual-boot.
Same
From technical point of view it is possible. eBPF already has almost everything needed for doing that. And I think it can be done with a simple LKM but if they want it included in the main tree I'm sure they'll get some colorful email from Linus.
I really want to see that email.
kernel level anti cheat is malware
abandon ranked, return to private lobbies
I sure hope not. Play on someone else's pc if you want them to have control.
It's the other way around. Windows will stop supporting kernel level anti-cheat because of Crowdstrike
They want to provide APIs that basically do an equal job but will restrict direct access.
Good one
Doesn't Splitgate 2 have kernel level anti cheat that works on Linux? Maybe it is "trapped" inside wine/proton but they explicitly made it work and people are thanking them on steam discussions.
Helldivers 2 works (or at least used to when I played it) as well, while requiring kernel access on windows
No Wine/Proton cannot translate calls that run too deep into the Kernel
AFAIK Microsoft have plans to block kernel level anti-cheat on Windows. After the CrowdSec issues last year, they're rethinking which types of programs should even be allowed to run in kernel space.
Edit: I was wrong. They actually want to increase what can be done in user mode, to reduce reliance on kernel mode code.
They actually want to increase what can be done in user mode, to reduce reliance on kernel mode code.
That's basically what Apple did with macOS 11. They deprecated kernel extensions and replaced them with "system extensions", and created new APIs so security tools, VPNs and such could function without kernel-level privileges.
They don't. One article lied, people never read anything but the title and here we are this getting mentioned every once in a while.
Thanks. I looked into it a bit more and it looks like they actually want to increase what can be done in userland, to reduce the reliance on kernel mode. That's still a good solution, if things the anti-cheat code needs to do can be moved into userland.
No.
Sure hope not. If I wanted to run rookits I'd just use Windows. Why bother with Linux?
This is why I don't want more Linux adoption and don't understand people cheering every new user. We're in a sweet spot where a lot of games enable userland anticheat while we don't get kernel level ports (however they may be shipped doesn't matter). The only thing that'll come out of more adoption is kernel level anticheat ports that'll probably work with a few corporate backed distros only and we'll actually lose the games we have today. Because those will switch over the kernel level alternatives too.
The only way I'd like Linux to be a generic multiplayer platform is server side anticheats. It is very obviously the way to go and we are seeing extremely slow adoption (e.g. Marvel Rivals).
I think the more people who aren't using corporate operating systems, the better.
I'm firmly against Microsoft, Red Hat, and Ubuntu.
On one side, I'm one of those glad for people coming to Linux because Linux is truly fantastic and it can make your life easier on many things, I'm happy for them.
On the other side, I share your concerns, because everything that gets adopted by the masses is inevitably subject to enshittification, I would never want that to happen to Linux.
We should find a sweet middle-point tho I have no idea what that would be.
TBH I'm not sure wider adoption would worsen things ? Gaming distros would probably ship bullshit anticheat modules by default while the others would not, or at most provide some documentation on how to opt in.
I think it's quite similar to the situation with NVIDIA proprietary drivers? (I don't own a graphics card so I'm not super aware on this topic)
My point is you would either have to run those modules on Linux or not play the games. Which is the same as running them on Windows or not play the games with the exception that you'd lose the games that run on Linux with userland anticheat now.
Meanwhile in indie land, I just tried to cheat my way through a Chapter 3 minigame in Deltarune, and Toby Fox himself showed up in his dogsona to blow up the game and make me start the minigame over.
This is the extent to which anti-cheat measures should go.
I think its less a question of the technical feasibility, and more of an issue that we, as users, don't want more closed-source blobs in our kernels. Meanwhile, the publishers insist that they can't open-source their anti-cheat code; Their idea being that if we know what's in it, it will be easier to bypass.
Basically, one distro or a few(at most) may get anti-cheat integrated one day(like, say, SteamOS), but it will likely never be in your standard Linux kernal.
They could go the rought of kernel modules, I would think, but for whatever reason, we're still having this conversation.
Shite is still shite, even if it's open source shite.
Basically, one distro or a few(at most) may get anti-cheat integrated one day(like, say, SteamOS), but it will likely never be in your standard Linux kernal.
Valve also has server side anticheat in his games (Counter Strike or Deadlock). They are also against it.
Kernel-level anticheats can be bypassed anyways, but they are the easy solution for the corps that want to sell their multiplayer game.
It is probably actually easier to create on linux as it is foss and there are also good projects like eBPF which can maybe even simplify and make it more secure.
Absolutely nothing prevents somebody from writing a kernel level anticheat on Linux.
Users would throw a fit, and it would be way easier to bypass, but it certainly could be made.
One way I can imagine it being some certified Linux kernel versions that are accepted and worked together with anticheat creators. That way Valve could use the Kernel in Steam Deck or SteamOS, so any game works out of the box. And other distribution users can just install this Kernel too, if their distributions provide it.
Anyone who don't want to have Kernel level anticheat systems enabled on their system, do not need to install the Kernel. Therefore they are secure against it. But for anyone else who wants it, they can. At least this option would be a compromise.
if it's linux, it has to be open source. If it's open source, people will code around it immediately. How about not trying to shoehorn this useless crap in the first place?
It doesn’t have to be open source. There’s plenty of binary firmware and drivers around.
I'm not a programmer or cheater or anything, but I think the answer is yes and no. Yes it could technically be done and even work as intended as long as the device is locked down to prevent the user from replacing the shipped kernel (which would be a bad thing for users). However, savvy people could (in theory) make custom kernels that lie to the kernel module, causing the module to report there is no cheating when there is. It's my understanding that it's close to the current situation with Windows and virtual machines and anticheat: you can cheat by running your game in a VM and then have that virtual hardware extract secret information or flip bits in the right spots. Most competitive games will refuse to run in a VM for this reason.
This is where TPMs, measured boot, and remote attestation come in.
You can run whatever kernel you want, but if it is not an approved kernel, you wouldn't be able to attest to running an approved kernel; allowing whatever DRM scheme the developer put in to active.
I believe this is how the higher levels of Android's Play Integrity system work.
When Microsoft first proposed something like that a couple decades ago, it was widely seen as the nightmarish corporate power grab it was. Even mainstream, non-techy publications were critical.
I believe this is how the higher levels of Android’s Play Integrity system work.
It is.
How the fuck did this become acceptable?
It already works, but studios using anticheats that DO support Linux CURRENTLY don't bother implementing it because we're maaaaaybe 3% of the market on a good day, so they say "fuck it" and don't expend a few dev hours to enable it because they see it as a pain to deal with v users who need it.
AFAIK the current anticheat systems on Linux only run in userspace not at kernel level. This does mean Linux is theoretically easier to bypass compared to windows, some games just dont seem to want to take that risk. For as you said 3% of the market.
I personally disagree with that stance though, because all it takes is a hardware device and all software anticheats are useless no matter the os (think a raspberry pi, and capture card). So anticheat is really a losing battle anyways.
we're maaaaaybe 3% of the market on a good day, so they say "fuck it"
So true. And worse than that, we're probably also the 3% most likely to skip buying a game that requires anti-cheat, anyway. Many of us are famously un-friendly toward closed source code running with invasive permissions.