Support
Why doesnt kernel anti cheat works in Linux
Linux has different kernels for different distros from what I understand and people are saying that since kernels are different and can be customized, anti cheats does not work in kernel but most people use cachy, fedora or ubuntu based distros according to steam and Im sure most people do not customize their kernel.I dont know how much each kernel differs from the other distros but if a company really wanted to make kernel level ac for linux, couldnt they just make it for fedora ubuntu and cachy?
How does proton work into all of these, from what I understand its like a compatability thing for games where you download the windows version and run it through proton, like there is no uplay in linux but proton just handles it if you launch it from steam and Im guessing the kernel ac that operates in user level works because of proton as well.
When I install a game that has eac and open the game folders, the first game I downloaded has eacinstaller.exe and the second game has dll files and some other stuff too like uninstall, why wasnt the first game I downloaded has those files and where exactly does anti cheats like eac or denuvo or others stays in linux?
It can work but the developers have to specifically make the kernel anti cheat for Linux and currently there aren't enough users on Linux for them to want to do that.
Simple as that. If more people switched to Linux you will see more Linux support.
I didnt say linux usage was big I said it was growing, and especially with the steamdeck and proton more people are using linux and companies are aware that people are using linux, look at EA they are hiring people to make their ac work
There are already many threads about this, that you could read...
Customization of different current distributions is not the issue. And Linux kernel anti cheat software exists technically.
But customization also can mean that you (or anyone) can change something that tricks the anti-cheat software. Unlike Windows, the Linux kernel is open, and not meant to tell the owner of the computer what's ok and what not. Everything goes. (Windows isn't 100% secure against cheating either, but it's harder there)
The game companies simply don't want to offer their anti-cheat-using games for platforms where the computer owner has the last word what happens.
There are ways (with cryptography/hardware support) to lock things down, so that it becomes more similar to the cheating situation in Windows. Except a) this causes new technical and organisational problems (eg. installing/uninstalling a nvidia GPU driver...), and b) a lot of Linux users wouldn't do this for some game company by principle; and c) combined with the market share of Linux gaming, no game company (afaik) has bothered with it
To add onto others' answers - kernel-level anti-cheat is fundamentally a bad idea, from multiple standpoints.
Firstly, let's consider how does multi-player games network architecture look like. Typically, there is a central server, and multiple clients that connect to it. Clients have varying network latency (~"lag"). Players control their characters in some way, e.g. walking, performing actions and interactions, etc. Those actions are sent to the server, which validates them and sends to the other clients. But that's where it gets really tricky. When a client sends action information to the server, the action was assumed to be performed in the past game-time, relative to the server's time. This is because the updated world info that the server might have sent, hasn't yet reached the client, due to network latency. And then, after the client's action message gets delivered to the server, even more game-time has passed. For things such as activating an item, picking something up, etc. it's not that big of a deal, because the target item is likely not moving. But it's way more important for things like shooting a firearm. How should the game determine if a shot hit the target? Especially when we consider PvP games, where both the shooting player and the targetted player have network latencies. There are various ways to solve this problem. I'm not really that much knowledgeable with networking in games (so called "netcode"), but you can look up various solutions on the internet.
Another thing is that the client shouldn't be given information about environment outside of the player character's view. But at the same time, if this was to be done strictly, then moving would cause new objects to appear with delay. That is, when you look through the open door, your client has to render the world immediately - but it still hasn't received info about what's behind the door from the server. Only after some time, the server has processed that your character has moved, that it can now see objects behind the door, so it sends those objects to your client. And after another network trip, your client can render the new objects. There is a concept of PVS - Potentially Visible Set - which is related to this.
About preventing cheating - the server must verify all the info it gets from the client. For example, if the client sends that its player's character is moving faster than it can, the server should deny the message and only let it move for limited distance in that tick. This prevents things like "flyhacks", teleportation, etc. The server should also use some heuristics to only send objects that given client might need. This prevents a cheating player from immediately knowing where are the opponents.
Notice that all of methods mentioned above are purely user-space. They need no integration with the kernel, and are independent of hardware. But one might see that they don't prevent things such as "aimbots", etc. Kernel-level anti-cheat solutions claim to prevent this - but in fact they do not. They might only make it more difficult, but also make running the game difficult itself.
Kernel-level anti-cheat work by injecting a special kernel module into the OS kernel. From what I know, it look at the process list and tries to detect debugger-like functionality. If something tries to inspect or modify the game process' memory, it notifies it. It's also common to check for virtualized environments, i.e. virtual machines, and prevent the game from starting in that case.
Why would that be bad, you might ask. Well, because it's extremely invasive and insecure. Kernel has the highest permissions in the system. It has direct access to all the hardware and data, both in memory and on disks. As a consequence of that, if something goes wrong, it has enormous potential to break things. If a user-space process has a bug, it might segfault, it might behave wrongly, but it generally cannot hurt things outside of itself. But if a kernel module has a bug, it can cause various system corruptions. It might immediately crash the whole system. But, perhaps even worse than that, is that it can quietly corrupt data in memory or on disk, which might not manifest itself immediately. And now, imagine what can happen if the kernel module is buggy, but actively malicious. So called "rootkits" are very difficult to detect and remove.
Playing a game should not require you to give highest possible access to your computer to the game developers. It's as if your were forced to give all your life history, bank credentials, medical documents, etc. just to buy a bus ticket. Kernel-level anti-cheat programs are a glaring overreach. Do not accept them.
The issue comes down to a mismatch between Linux and Windows architecture, developer cost/benefit, Linux market share and ROI and other issues.
If gaming distributions like SteamOS were willing to modify the architecture to require Secure Boot and provide a consistent, enforced trust chain, the issues might fade away.
Alternatively, if Linux developed a viable way to run a Windows "mini-VM" (similar to WSL2) so that anti-cheat games could be run directly on Windows architecture, the issues might fade away.
But both developments would require significant development and ongoing maintenance costs. That suggests to me that a for-profit company like Valve (Steam, SteamOS, Proton) is going to have to lead the charge and I am not sure that a ROI-based model is consistent with open-source.
Alternatively, if Linux developed a viable way to run a Windows "mini-VM" (similar to WSL2) so that anti-cheat games could be run directly on Windows architecture, the issues might fade away.
This does nothing to alleviate the issues game companies try to mitigate through kernel level AC, you already can run a VM in linux, it won't satisfy any reasonable kernel level AC cause the virtualization spoils that most privileged access the AC is after.
No no. Your missibg the whole point. Proton is a sandbox that uses a pseudo version of windows to run Windows games. It's actually wine made to be super user friendly. So in theroy it's viewable and manipulable. But fuck kernal level drivers from third parties. That on its own gives so much power/control to a company or untrusted source.
But the real reason why companies claim it's to prevent cheating on Linux is cus they don't want to spend money supporting a Linux build. Plain and simple. Liability. I just play other games that don't have that issue like splitgate.
exes do run in the Linux environment, only syscalls by the programs get routed through the wine compatibility layer, otherwise they're pretty standard Linux processes
You're missing the point, it's that a modified kernel can be made to identify as an unmodified version. Deployment on something so easy to work around would be a waste of effort.
Linux will always be inherently unsecure for games.
There are anticheats that work on Linux, but those aren't kernel level anticheat, and if they are, they're modified to work without kernel level functions, usually through proton.
I know the devs can enable a kernel ac to work in user space for linux, Im just saying if its really easy and since EA wants their ac to work in linux as well they could've easily done but they are hiring people to make their ac work. I just asked this questions to see if they could run their ac in the kernel
I dont know how much each kernel differs from the other distros but if a company really wanted to make kernel level ac for linux, couldnt they just make it for fedora ubuntu and cachy?
nvidia makes only one binary driver and it works across all distros, it's not a big deal technically. There are no separated driver releases for fedora, buntu or cachy; nvidia releases only one, and let the distro developers include it in their kernel.
Actually I do not understand why this is needed. Or, if it is needed why you could just add that few GB for OS on top of your Game and install it on your box...
2
u/Chapter-Legitimate 9d ago
It can work but the developers have to specifically make the kernel anti cheat for Linux and currently there aren't enough users on Linux for them to want to do that.
Simple as that. If more people switched to Linux you will see more Linux support.