r/linux_gaming • u/SufficientLife7766 • 6h ago
EAC Linux v2 does NOT install a kernel anti-cheat module
I've seen quite a few people misunderstanding this announcement and claiming that Epic is bringing kernel-level anti-cheat drivers to Linux.
Epic explicitly confirms that EAC Linux v2 does not install or load a kernel module.
Instead, it uses existing Linux security features, eBPF programs and a systemd service that only runs while the game is running.
That doesn't mean it operates entirely in userspace, though. It still relies on kernel security mechanisms and requires things like Secure Boot, TPM 2.0 and signed kernels.
It's worth actually reading the technical details before assuming it's the same approach used on Windows.
Source: https://onlineservices.epicgames.com/news/introducing-easy-anti-cheat-linux-v2
47
u/GlitchPhoenix98 6h ago edited 5h ago
I think it's largely a good thing, however I am concerned about people with Nvidia drivers or people using distros like Arch where you bring your own keys.
I don't really care about Fortnite, I usually play on console anyways even when I was on Windows, but I'm concerned about them bringing EAC v2 to other games and then it stops working because Nvidia drivers aren't signed with approved keys or because Arch doesn't have their own keys.
Granted, Epic has said they're working with maintainers so this may become a non issue on Arch or other similar distros, but still slightly concerned
Either way, a step in the right direction but I hope they address Nvidia drivers or distros like Arch in the future
8
u/zixaphir 5h ago
The solution for Arch will likely be using a vendored kernel and vendored Nvidia drivers. I've already thought about trying to start a non profit for working with Epic to provide reviewed alternative kernels like Zen, Cachy, or Xanmod, but I don't have the capital lying around to get that started
6
u/BulletDust 4h ago
This is also going to be a problem regarding Nvidia drivers under Ubuntu if you want to run the latest drivers direct from Canonical. Currently the 595's are signed using an Ubuntu key, but the 615's aren't.
11
u/GlitchPhoenix98 3h ago
I mean, I'm sure Canonical will likely step it up and start signing them once EAC v2 is ready, either that or Epic will come up with something considering that most PCs use Nvidia GPUs. But it is probably something that should be voiced early on
4
u/BulletDust 2h ago
Likewise I'm confident it's a problem that can be resolved. TBH I'm not too sure why Canonical don't sign all the drivers available under their repos, it just makes sense to do so.
As it is ATM, it's not a huge deal breaker, the 595's for example are still very capable drivers - however there may come a time where you want a feature that isn't available under the latest production branch driver, and in that instance it seems that self signing drivers isn't gonna cut it regarding EAC v2.
0
u/RAMChYLD 56m ago
I’m hoping that it’s Valve that would be stepping up to do the signing since they lean on Arch a lot for SteamOS.
1
u/RAMChYLD 58m ago
Hopefully this will put pressure on getting the Nvidia-Open drivers to production quality. Nvidia has kinda changed their minds about keeping their drivers closed sourced and are working on an acceptable open source solution that comprises of the Nvidia-Open kernel driver and NVK Vulkan driver. Everything they want to keep secret are in the binary blob firmware, so no different from AMD and Intel OSS driver solutions. The issue is the driver is still far from production quality and GPUs that aren’t from the RTX family isn’t supported.
1
u/Cool-Arrival-2617 59m ago
They said they will support the Nvidia drivers in the article.
1
u/GlitchPhoenix98 7m ago
Oh! Right, I must have missed it. For anyone else wondering what the article said:
There are some exceptions that are maintained separately from the kernel (out-of-tree), notably NVIDIA GPU drivers. If you need to load kernel modules, we require that they meet the same requirements as the kernel—being built by an organization and signed with a well-known key.
1
u/skinnyraf 35m ago
I think it is really time for Nvidia to align their drivers with the rest of the Linux kernel architecture. They cause issues for SteamOS, they cause issues for EAC v2. I hoped that the new "open" architecture would fix it, but it seems it didn't.
31
u/AlwaysLinux 6h ago
Great article! I was a little skeptical about their approach, but the more I read about it the more I like it.
Good times ahead for Linux and gaming!
Thanks for the link!
9
u/hakurou46 6h ago
Ehhhhhh
It's still arbitrarily locking EAC2 away to only work on pre-approved kernels. If you built your system yourself and either compiled your own kernel, or you're maybe on some arch version that rolls a non-standard kernel? sorry, out of luck.
its better than installing kernel modules, but its still a step back from an open computing environment
31
u/kabrandon 5h ago
Right now this is the best news we’re going to get because Linux is the only desktop platform where the anticheat maker doesn’t have a corporate entity to blame if they find they can’t trust the kernel’s code. If you can’t trust the kernel then there’s not much telemetry they can gather that they can trust. So I wouldn’t look a gift horse in the mouth, of course they’re going to require that they have a signed kernel from a key they trust, if anything that’s still a weaker promise than what they’re getting from Microsoft NT.
10
u/steve09089 5h ago
If you take it from the perspective that the previous alternative was running games on only Windows, it's a step forward.
-7
u/forbjok 2h ago
It's really not, because if people accept this and companies get away with it, they'll keep doing it, and then any distro or kernel that isn't approved by these companies will become impractical for games.
7
u/steve09089 2h ago edited 2h ago
As if all games have anti-cheat to begin with, and of the games with anti-cheat, all will adopt this level of security by default anyways just because it is available. It’s a risk, sure, but considering more than half of games with anti-cheat don’t work on Linux (at least according to AreWeAntiCheat), many being top on the Steam chart, it’s an improvement.
Many companies were already getting away with it anyways with or without the Linux’s community’s approval because of how tiny it is, and how rampantly bad cheating is as a whole.
-4
u/forbjok 2h ago
It's a risk, and it's not worth it. Plain and simple. If this becomes a thing, more games will almost certainly start implementing it as well, including ones that don't have any anti-cheat currently and work.
6
u/MadBullBen 2h ago
Most developers don't care about Linux at all, so no, they won't suddenly start to implement anti cheat just because Linux is now available.
We'll have to see exactly how it's implemented and what the requirements are.
1
u/UltraCynar 1h ago
But if they do then they might use this anti cheat which it would be better to not have this be an option. There’s already other options that don’t disrespect the user with malware such as this.
1
u/DAS_AMAN 5h ago
That's how cheaters will be locked out ig
0
u/Emotional-Art2113 3h ago
Lmao cheaters run custom hardware on windows to bypass kernel/OS altogether, so no, they wont, but i wish it was that easy
1
-5
u/NTolerance 5h ago
Sweener approved distros and configs only please. Might as well run fucking Windows.
-1
u/UltraCynar 1h ago
This isn’t exciting. What if you have some obscure hardware that requires you to add your own driver modules? This is still running at kernel level, just sandboxed. We’re handing control of our PCs over to epic of all companies which has a history of shady business practices. This is not a good thing.
8
u/MutualRaid 5h ago
Could the eBPF program used be able to obscure misbehaviour on the part of the application being protected by it from end users? That's the part for me where this goes from a mild headache of jumping through some hoops in to a 'just trust me bro, don't look behind the curtain'.
10
u/_agooglygooglr_ 3h ago
eBPF programs are quite limited on what they can do. They hook into specified kernel subsystems and then execute verified bytecode in a virtual machine, sandboxed to the subsystem its program type limits it to.
EACv2 claims to be running an eBPF program hooked into the LSM subsystem; the same LSM that SELinux uses.
When I first heard they were using eBPF, I was worried they were going to use something like a kprobe program type, which would let them trace everything running on the system (so... spyware). But LSM eBPF programs don't has such capabilities AFAIK.
Also eBPF byte code is relatively simple and thus easy to reverse-engineer.
2
1
u/AmarildoJr 6h ago
Pardon my ignorance on systemd, but doesn't having a systemd service mean they can run as root by default?
8
u/theevilsharpie 3h ago
Systemd services can be run as root, but many just launch as root to do a limited operation (e.g., binding to a privileged port), and then fork off into another process that is running under a more restricted user.
It remains to be seen what EAC v2 will do, but the userspace daemon doesn't necessarily need to be running as root all the time.
9
u/AstronomerDull415 6h ago
systemd has system level and user level, but I don’t know where epic will be placed.
2
u/FlukyS 1h ago
systemd services can run at a load of different privileged levels or even a user specific to the specific service with the dynamic user system. Either way though they can't really get around the fact they need system level access for a lot of that info so I'd be surprised if it isn't root
-1
1
u/JamesLahey08 6h ago
Would CachyOS work
8
u/Jecobe 2h ago
They are actively trying to contact Epic Games
https://www.reddit.com/r/cachyos/comments/1x5u0vz/comment/pgpi76n/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button1
u/Ifnerite 10m ago
Thank you for that info. Good to know.
That is good news for me but the whole thing is bad news for anyone wanting to run any custom kernel.
0
u/Shitty_Human_Being 3h ago
Most likely no, it's Arch-based and brings its own keys afaik, you'll have to wait and see.
7
u/_agooglygooglr_ 2h ago
most likely yes. as said in the blog post, Epic will be adding signing keys from distro maintainers to a well known database.
cachy maintainers will have to start signing their kernels, though
1
u/Actual-Phone-1478 5h ago
I can never get my linux to load if I have secure boot enabled... how would that work if I can't launch linux?
6
4
u/sikkmf 2h ago
Did you follow your distros guide for key enrollment?
1
u/Actual-Phone-1478 1h ago
No, but I am working on that right now actually
1
u/sikkmf 1h ago
Hope you don't have an ASUS board. It makes thing a little more complicated but not impossible. :)
1
u/Actual-Phone-1478 1h ago
Nope, I have a gigabyte board :p
2
-2
u/RAMChYLD 1h ago
That’s even worse. Gigabyte boards suck when it comes to enrolling custom keys.
My x470 Aorus Gaming 5 literally bricks if I upload any key that isn’t signed by Microslop. Even uploading the Ventoy key is enough to make the board brick.
2
u/sikkmf 44m ago
Do you even know what "brick" means?
-1
u/RAMChYLD 42m ago
Yes. The mobo pretty much just gets stuck on a black screen and won't power on unless I pull the cmos battery and let it reset, which also purges the key.
-1
u/forbjok 2h ago
Doesn't matter. It restricts the freedom to use any kernel, and imposes extra work on the distro maintainers that might actually be influential enough to be able to get their kernels signed.
It's just not an acceptable solution.
5
u/nfrances 2h ago
I disagree.
For any competitive gaming this is good thing.
Having 'freedom' equals 'no security', as there is nothing stopping you to do whatever you want.
It does matter HOW it's done, and this so far seems correct way. You losing yout freedom to use anything you want.. well... then skip this.
3
u/UltraCynar 1h ago
Competitive gaming the solution is server side and user space. Invasive malware is never an acceptable solution.
1
u/Fraserbc 17m ago
Userspace is not an option as the user can do anything, and server side anticheat is just not viable
0
u/noblepickle 1h ago
This will be an option to play games that otherwise are unplayable on linux. I would rather have the option than not. People can always skip those games and continue with thier day if they dont wanna do the equired steps. This is 100% a linux win.
1
u/BlackeyeDcs 0m ago
The problem I see with that is that games that are already playable now might latch onto this and require their own version of it.
So for the people not willing to have their system locked down and hand over the keys the number of playable games might actually decrease quite a bit - not a win in my book.
-1
u/funforgiven 1h ago
Kernel signing isn't some unreasonable new requirement invented by EAC. It's been a standard part of Secure Boot for years, and distributions arguably should have had proper signing infrastructure long before anti-cheat software started requiring it.
You're still free to build and run whatever kernel you want, but that doesn't mean third-party software has to trust arbitrary, user-controlled kernels.
I'd agree that Epic's trusted-key approval process should be transparent and accessible to smaller distributions, but that's an argument against centralized gatekeeping, not against kernel signing itself.
-8
u/askc0re 6h ago
Its still require signing akmod/dkms drivers with maintainer keys. Otherwise, you cannot play with AC. What if a user have a network card/printer/other legitimate device that works only with out-of-tree module? What if a user have a NVIDIA GPU with modules from RPMFusion/Packman?
Yes, EAC2 relies on existing features, but i’ll not want reboot my system into “trusted environment” just for Fortnite, and after reboot into “untrusted environment” just for making my printer work correctly.
11
u/friendlyreminder_ 5h ago
Fedora will have to change how they distribute the Nvidia driver.
Opensuse already compiles and signs their kernel driver, it'll work with no issues. It's not in packman.
15
u/ABotelho23 6h ago
Printer drivers don't use kernel modules in Linux.
Otherwise yes, you will not be able to load random kernel modules.
i’ll not want reboot my system into “trusted environment” just for Fortnite, and after reboot into “untrusted environment” just for making my printer work correctly.
Then you will continue to not play Fortnite just like you don't today.
0
u/serwhite 5h ago
only kernel module (besides nvidia) I care about is zenergy, cause nothing else reports cpu power consumption faithfully for my cpu.
so if AC dont like it - I will just not play it, as I did before with many other games that forbid Linux "cAuSe Of SoMe BaD aCtOrS" (that was Bungie on Proton support in Destiny 2)17
u/amepebbles 6h ago
And this is fine, it may not work for you but that's the beauty of it all, we have the choice unlike on Windows.
11
u/PacmanAteMyRAM 6h ago
You have the choice to not do it on Windows too
7
u/steve09089 6h ago
Now I also have the choice to do it and not on Windows.
2
u/UltraCynar 1h ago
While this virus spreads to older games that don’t use it like Elden Ring whenever they “upgrade” their eac
3
u/Ill-Brick-4085 6h ago
Maintainer keys and printers don't have anything to do with each other in most cases. So I'm not really sure what you mean by that.
Also nobody is forcing you to play Fortnite. You don't have to play a game that you don't have a good opinion about.
3
u/UltraCynar 1h ago
This is more than just Fortnite. Other games use easy anti cheat and could no longer be working in a future update due to this spyware.
2
u/franzitronee 2h ago
Also nobody is forcing you to play Fortnite. You don't have to play a game that you don't have a good opinion about.
Sure and that's a good take on video games in general.
However, what about games we have already been able to play? And can we also not be upset that the proposed method will perhaps set a standard that encourages games which would otherwise also be released with the old AC to use the more restrictive, new AC?
Sure it's a good effort to make Linux more trustworthy, but it's worth at least noting that even as it's not kernel anti cheat it goes against the fundamental freedom of linux.
0
u/franzitronee 2h ago
I don't understand why your comment is being downvoted. The reason I use linux is because of its freedom, but the new EAC2 requires us not only to run closed source binaries like now, but in addition to accept Epic as even more authority over what we run and whose programs or kernels/kernel modules we can run.
For example, I use a custom kernel module for a Logitech Joystick because otherwise some axes are weirdly aligned and Force Feedback doesn't work. I'm sure niche modules like that won't be signed with an accepted key.
Yeah, I could just decide to stop playing EAC2 games, but if it becomes the new standard, you can't deny that my options are getting worse.
-11
-6
u/Tranceravers 6h ago
Do we know if this will work on Steam OS? It is Arch based right?
11
u/sjphilsphan 6h ago
Didn't even bother reading the article?
6
u/Tranceravers 6h ago
Sorry I was too busy reading op's post. Ok so they address Valve hardware and that they plan on working on it but that steam deck technically doesn't support their implementation. I know that on a hardware level the Steam Machine does. So I am good there.
93
u/SmileyBMM 6h ago
I mean, eBPF is kernel level, it just is sandboxed.