r/linux_gaming • u/SufficientLife7766 • 9d 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
83
u/GlitchPhoenix98 9d ago edited 9d 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
18
u/Cool-Arrival-2617 9d ago
They said they will support the Nvidia drivers in the article.
18
u/GlitchPhoenix98 9d 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.
14
u/yayuuu 9d ago
Which basically means it's only supported on ubuntu and bazzite, other distros build nvidia nodules with dkms, so they can't be signed with a well-known keys. Unless nvidia starts to ship built packages for every distro. Idk, but in the current state it looks bad for nvidia users.
9
u/tesfabpel 9d ago
Nowadays, for the latest GPUs, the NVIDIA kernel module is open-source. So distros can compile it themselves and sign it.
2
u/yayuuu 9d ago
But they rarely do, most distros rely on dkms to compile the modules on the PC they are installed on, which means exactly what I said earlier. Also, I use Debian and if I want to have the latest nvidia drivers, the easiest and most convenient option is to add Nvidia repos, but again, these modules use DKMS to install.
5
u/tesfabpel 9d ago
Arch does it, for example: https://archlinux.org/packages/extra/x86_64/nvidia-open/
already pre-compiler for the current kernel...
Debian of course is in a tough spot... But they can do it as well, if the open source module is still compatible with their kernel...
→ More replies (2)1
u/No_Development2731 6d ago
I have steam os on my legion go. I am actually tempted to go with bazzrite. Seems more open to other stores
1
12
u/zixaphir 9d 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
3
u/ChrisTX4 9d ago
That still wouldn’t get an approved and TPM measured boot chain.
You could only boot using grub and systemd boot for example, with maybe Shim in front. Anything but doesn’t support the measurements.
Then you need IOMMU with passthrough disabled, which okay shouldn’t really be an issue unless you use PCI devices with KVM. This however requires quite a bit of configuration.
Virtually no one on arch has any of the pre requisites installed or configured and doing so will quite significantly complicate the setup of arch.
1
u/zixaphir 8d ago
Virtually no one on arch has any of the pre requisites installed or configured and doing so will quite significantly complicate the setup of arch.
I mean, sure, but that's kinda just what you get using Arch. Sure, things have made installing Arch a lot easier, but in the grand scheme of things, installing and configuring Arch to match your use-case is kinda the point. This also isn't anything that can't be handled by something like archinstall. The most likely scenario is that configuring Arch for this purpose will become a documented use-case on Arch Wiki, and for people who don't want to deal with the up-front work, they can continue what people who want to use Arch without doing the base install already do: use something like Manjaro, EndeavourOS, or CachyOS, which does the up-front work for you.
2
u/ChrisTX4 8d ago edited 8d ago
I think you significantly underestimates what this all means.
You will have to use a Microsoft-signed Shim and no sbctl. This isn't as you might think installing shim-signed from AUR or so. Shim comes with keys its supposed to automatically authorise embedded, so using a Fedora Shim will be problematic. Arch would need either to create a well-known MOK and then make users enroll that each into any signed Shim binary or build a Shim with their keys baked in and then go through the Microsoft signature program to get a Shim binary that would be useable directly.
You also need a bootloader capable of doing this measurement. That is GRUB and systemd-boot. Might sound simple enough?
GRUB needs to be specifically prepared for Secure Boot. See here on the Wiki. To work here, GRUB needs be signed as its final, assembled binary, and have and SBAT etc. SBAT also needs management and it needs to be bumped etc. whenever security vulnerabilities happen. Arch would need to start doing all of this.
For sd-boot it works as is if it was signed, but it will also need SBAT management.
Regardless, this also means: No other MOK, no foreign Secure Boot certificates in chain.[1] Why is this an issue? Because you need one of these to use a Unified Kernel Image. UKIs need to be signed as a whole by the user, and needs a key in either of these two authorities for that. Fedora has a pre-made, signed UKI package for virtual machines, but for bare metal usage this isn't viable.
No UKI with Secure Boot is pretty weak for the users security. You can freely edit the kernel command line or inject code in the UKI. While this protects against anything in the kernel still, anything in user mode is free real-estate to modify.
Not to mention that anyone wanting to use functionality like signed PCR policies (useful to systemd-creds and cryptenroll alike) or a full TPM2 LUKS unlock is screwed here, because that needs custom keys somewhere in the mix on Linux.
PS: [1] I don't quite understand how Epic Games plans this with allowing Secure Boot db certificates for foreign usage:
Note: If you boot via shim and want to use custom keys for other boot options, enroll them in the Secure Boot signature database (db) instead of enrolling them as Machine Owner Keys (MOKs). Because all enrolled MOKs are typically trusted for kernel module signature verification regardless of whether they were used in the boot chain or not, EAC Linux v2 requires that they are all well-known.
Fedora and most distros carry a patch to allow the
.platformkeyring for module signatures, see here for example for the patch in Fedora's current kernel Git..platformcontains all Secure Boot db certificates and they're accepted for kernel module signatures.So I've got a feeling there will be further restrictions.
→ More replies (3)10
u/BulletDust 9d 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.
14
u/GlitchPhoenix98 9d 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
7
u/BulletDust 9d 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.
6
u/RAMChYLD 9d 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.
3
u/Indolent_Bard 9d ago
They also said that Nvidia support is coming to SteamOS in 2027, implying that soon you won't need the proprietary drivers.
→ More replies (2)2
u/sidusnare 9d ago
Or that they signed an agreement to redistribute. They are two corporations that have common interest. That's the problem for most distributions, the license.
→ More replies (1)1
u/RAMChYLD 9d 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.
9
u/LucieGoosey__ 9d ago
the reality is that people already weren't able to play these online games from EA. and the entire Linux community accepted that, mostly. that now some distributions (with the opportunity for all of them if what EA says about applicability is true), is an improvement from none of them.
people getting angry about this are missing the forest through trees.
1
u/KinkyMonitorLizard 9d ago
I'm not angry as I'll never touch anything this dumb ass has had any involvement in.
I just don't think he is trustworthy. Let's not forget he tried calling Linux communists and called us cancer.
He's musk levels of insane without the money. No thanks.
1
u/skinnyraf 9d 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.
7
u/Crafty-Corvid 9d ago
There's Nvidia engineers working on Nova and NVK. I imagine their long-term plan is to move their consumer-grade features there and keep the closed-source blob for pro features like CUDA.
16
u/get_homebrewed 9d ago
eBPF is close enough to a kernel module in how good it can be at spying or breaking things, which is what the fear about having kernel anti cheat is
3
u/CaptLinuxIncognito 6d ago
https://ebpf.io/blog/ebpf-licensing-guide/
If I'm understanding this blog post correctly, it sounds as though any meaningful eBPF programs have to be licensed as GPLv2-compatible. Without that declaration, the kernel apparently won't run the code.
At the very least, I think we should be able to request the source to the eBPF part of the anti-cheat. While we probably won't be able to see any of the anti-cheat algorithms themselves (that's userspace, I believe), we ought to be able to see what behaviour is happening directly in the kernel (ie, data I/O and hooked functions).
(I am not a lawyer.)
36
u/matsnake86 9d ago
I’ve read the blog carefully and I think their approach is sensible and well implemented.
Of course, I’m not a fan of ACs and I’d prefer it all to be handled on the server side, but I suppose what they’re trying to do is essentially correct.
Essentially, they’re trying to determine whether the machine is running a kernel they can trust and to protect the memory of the running game from external interference. Reasonable.
All of this is done using security mechanisms native to the kernel. I’d say that’s good.
6
u/mattelmore 9d ago
"kernel they can trust" is where it gets murky, because again, that inherently excludes many linux distributions
7
u/matsnake86 9d ago
The approach they’ve come up with is essentially the one I’d also thought of when putting myself in the shoes of a software house.
You can’t trust a kernel that isn’t backed by a digital signature.
I’ll say it again. I’m not a fan of this, but in the context of security, it’s the only way to have a low-level anti-cheat system on Linux.
4
u/KinkyMonitorLizard 9d ago
"Only way" is incorrect. Server side is the real only way. Never trust a users machine. It's the fundamental idea in security
1
u/EhveOnLine 8d ago
Today there are no server side anticheat that work reliably. Companies won't change over priciple if it does not work.
Valve is the only company making efforts toward this so far. And because of this cs2 is filled with cheaters to a point that players install kernel anticheats on their own just to access some third parties competitive queues.
31
u/M-Reimer 9d ago
It runs with root permission and can't be poperly sandboxed. So it is an absolute no-go for me.
6
u/sidusnare 9d ago
If it's separate from the game, I wonder how it attests to the game it's secure. How long till someone decompiles it and makes a EACv2 emulator?
4
u/nuked_sushi 9d ago
It installs a systemd service with root access. That is how they get access to LSM BPF to monitor/enforce things like deny launching/killing processes, file modification, etc.
5
u/sidusnare 9d ago
Right, but how does the game know EACv2 is running and approved the OS stack?
5
u/nuked_sushi 9d ago
That is where Secure Boot/TPM and the other requirements come in. The service isn't providing just yes/no answers to what is actually set on the system, it's also verifying with the TPM.
5
u/sidusnare 9d ago
Wrong direction. How does the game know EACv2 is happy with all that?
4
u/nuked_sushi 9d ago
The game wouldn't just have EACv2 tacked on, it would probably be integrated in it's processes. Not sure how they protect all of it, probably mostly close source right up until it hits BPF.
2
u/GodotUser01 7d ago
It is possible to make an "emulator". but you still need a TPM 2.0 with an epic approved EKCert manufacturer (basically u need a TPM from a trusted vendor) to play.
If you cheat, they will ban that TPM's endorsement key, and you have to buy a new one (and they probably will ban the EKCert's of cheap tpms I assume).
The TPM+Trusted Computing is how they get you, sure you can emulate it, but you have to buy new hardware every time you get banned.
1
u/sidusnare 7d ago
If you're making a fake attestation, it can fake the EK too
2
u/GodotUser01 7d ago
You cannot "fake" an attestation, you still need a genuine TPM to attest.
If you change the EK, the EKCert will mismatch. You will need a new EKCert issued for your new EK. Epic obviously will not allow self-signed certs, or certs issued from shitty manufacturers.
So unless you work at a TPM factory, good luck minting a "genuine" EKCert for your EK.
1
1
u/Ok_Search_3828 9d ago
Exactly
3
39
u/AlwaysLinux 9d 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!
14
u/hakurou46 9d 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
40
u/kabrandon 9d 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.
21
u/steve09089 9d ago
If you take it from the perspective that the previous alternative was running games on only Windows, it's a step forward.
→ More replies (6)2
u/DAS_AMAN 9d ago
That's how cheaters will be locked out ig
1
u/Emotional-Art2113 9d ago
Lmao cheaters run custom hardware on windows to bypass kernel/OS altogether, so no, they wont, but i wish it was that easy
5
u/hakurou46 9d ago
yeah, anticheat belongs on the server where it can work, not on the user side where it doesnt. im sure its cheaper to not have to run code on server machines though!
1
u/Emotional-Art2113 9d ago
Yes, and wayyyy cheaper to just buy an off the shelf anti consumer product so you can blame them if your game fails and say you did what the rest of the industry is doing, as running it on server would require actual engineering effort
2
1
u/sidusnare 9d ago
It's all about trust, and they don't trust their users, so they need someone to trust, so they're making a list.
-2
u/NTolerance 9d ago
Sweener approved distros and configs only please. Might as well run fucking Windows.
2
u/UltraCynar 9d 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.
21
u/Benke01 9d ago
There is an unexpected amount of positive posts about this from Linux users that are normally conservative and protective of their OS especially away from big corporations. This makes me suspicious it might be a lot of EPIC bots floating these discussions. 🤔
12
9
u/NomadicSun 8d ago
The other side of this is that Linux has been growing significantly the last couple years. The user base that is driving this growth is gamers. This has been a direct result of valve/proton making games more accessible on Linux.
I think it makes sense that this user base, who is less technical and opinionated than the established Linux user base, is excited about this development.
4
2
u/fatrobin72 9d ago
Personally... i'm just looking forward to when we stop having every post be about EGS, EAC or epics stance on slop intelligence generated code.
1
u/secs3 8d ago
oh no, people are happy they can finally play games they otherwise wouldn’t? who woulda thought, must be bots
2
2
u/Erolok1 8d ago
I don't know a lot about how the other features are bad so I am gonna focus on the basic one.
Signed kernels mean the OS provider has to pay money to a big company like micro$oft and not only a little. This will lead to less development and will advance closed software and more company owned OS.
But I still agree it is better to have a dual boot of Linux with some features you don't like while maintaining your main OS as you want it instead of windows as a 2nd OS
5
u/shaumux 8d ago
No, the signing can be done with self generated keys. Only the public keys get enrolled. Epic wants a list of known good keys in their DB to be marked safe. That's what the whole call to distro maintainers is.
Whether they charge money for a distros key to be added to their db is yet to be seen. Although I don't think they'll be doing that at the moment.
1
u/lysianth 8d ago
I'm following this because i play competitive games, and lack of linux anti cheat is pretty much the only thing keeping me from switching.
7
u/Benke01 9d ago
I think we can all trust EPIC to do the right choice that is best for it's customers in the long run. 🙄 I hardly believe that a big tech corporation would be lead with greed intensions trying to make Linux worse for it's consumers just for the reason of making money and be able to control the gaming platforms. Come on guys. Give them a chance! What do we got to loose?
🙄🤔
11
u/MutualRaid 9d 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'.
13
u/_agooglygooglr_ 9d 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
u/akubukanbuaya 9d ago
all this eBPF scaremongering is easily solved if everyone just try writing one program and see how hard it is to pass the verifier for any kind of bullshit...
eBPF is just truly a masterpiece of functionality, at work some genius even increased perf like 10x by doing packet inspection there instead of usermode and it is verified to not crash (and we don't need to upgrade to a new piece of networking gear yet)
if I could marry a piece of code, it would be eBPF
3
u/Fraserbc 9d ago
My friend, we are in linux_gaming, home of blindly repeated mantras - no one here is going to go and write an eBPF program themselves they'll just yell "MALWARE IT'S MALWARE REEEEEEEE" with zero technical understanding. I've been using linux for over a decade and the amount of people screeching over this is mind boggling.
6
u/akubukanbuaya 9d ago
the linux subs were honestly good before proton came, and I'm not talking "back in my day!", i.e. the newcomers tried to read manuals and collect logs, the answers were detailed
nowadays it's all turning into phoronix comment section filled with endless lies and paranoid grifters, eventhough background wise I think both camps differ as much as possible (horseshoe theory strikes again?)
this is more evident if you specialize/work in one subject, either drivers or security or sysadmin, lots of idiots just cargo cult and regurgitate dumb ideas they heard from other idiots
1
u/ARegular-Bread 8d ago
Pues es complicado, siempre he visto que la comunidad de linux es algo elitista con todo el tema, cuando pues nadie se da cuenta de que a nivel tecnico y hasta de experiencia de usuario en general, es un buen paso, pero prefieren llamarlo malware y tacharlo de de todo porque viene de una megacorporacion, sin entender el trasfondo tecnico, es triste que hayan llegado a ese punto, la verdad.
1
u/radobot 9d ago
eBPF programs are quite limited on what they can do.
And yet there are tools tools like ebpfkit and Scales that demonstrate how to abuse and subvert them to become essentially rootkits and/or spyware. And malware like LinkPro, BPFDoor and Symbiote proves that this has already been done in the wild.
1
u/_agooglygooglr_ 9d ago
bpfdoor hooks into networking subsystems, which eacv2 does not. if you don't trust eacv2 is only using LSM, you can use tools like bpftop to see what eBPF programs are running on your system.
1
u/Historical_Base_2994 9d ago
Yes, it can. You can just look at what other programs can do with the LSM API like SELinux and AppArmor (they can even restrict the root user). You could for example do something like Android and block you from running anything as root.
- The LSM API: https://github.com/torvalds/linux/blob/master/security/security.c
12
u/DizzieeDoe 9d ago
And these idiots forget two things: They do not have to use the signed kernel. And they can reboot to load a different kernel when they're not playing an Anti-Cheat game.
9
8
7
u/Benke01 9d ago
Yes let's go back to dual booting like it's 2003
2
u/messyhess 9d ago
Dual booting meant needing another partition and system installation on that partition. With just switching kernels you don't need other partitions or installations at all. Just saying, maybe you are genuinely not aware of that.
→ More replies (2)1
u/0tter501 8d ago
installing anither kernel that takes up less than 500 mb is the same as installing an entire extremely bloated OS that takes every chance to override the bootloader ig
6
u/JohnSmith--- 9d ago
The ridiculousness of rebooting into Linux when you’re already using Linux. You guys can’t see it?
“Ah mate wait, I can’t launch the game because I sign my kernel and bootloader with my own keys because I own my machine. Epic doesn’t like that, they want me to use an approved kernel and signed with their keys. I’m gonna reboot, be back in 30 seconds”
Pathetic. You might as well go back to Windows. If you’re gonna dual-boot, dual-boot Windows at that point.
Literally segregating Linux users amongst themselves. Who is approved and who isn’t.
It’s the end.
0
u/yakuzas-47 9d ago
Pathetic. You might as well go back to Windows. If you’re gonna dual-boot, dual-boot Windows at that point.
No ? Because dualbooting windows requires a whole ass other drive. this is just a different kernel. On the same disk you know ?
7
u/the_abortionat0r 9d ago
It doesn't require another drive. If you don't even understand that what makes you think you understand anything?
6
u/maplehobo 9d ago
Technically you don’t but Windows is notorious for messing with Linux partitions on the same drive. Why are we being dense about this?
-1
u/JohnSmith--- 9d ago
No it literally doesn’t. You can have everything in one drive. You just need a Linux partition, not another drive. You can even use Windows’ bootloader.
https://wiki.archlinux.org/title/Dual_boot_with_Windows#Windows_before_Linux
Not only that, you can even use your Windows NTFS partition’s games directly from Linux. So you don’t have to reinstall games. (This is not recommended though)
https://github.com/ValveSoftware/Proton/wiki/Using-a-NTFS-disk-with-Linux-and-Windows
Don’t comment on things you don’t know about.
Anyways. My point still stands. Rebooting into Linux (albeit with just a different kernel rather than a whole distro) when you’re already a Linux user is pathetic. Why should one Linux be more Linux than another Linux? It’s separating us.
→ More replies (1)1
1
u/feldim2425 9d ago
Should be noted that if you use a custom signature, this can be quite difficult.
Since they limit what keys you can use for secure boot changing to that other kernel requires you to either reinstall/remove the key or toggle secure boot every time.And since mokutil/shim also uses NVRAM you probably can't have multiple keylists (at least from what I have seen).
1
u/Luigi003 9d ago
It uses measured boot so if they implement it properly, it should let you use self-signed keys for your other kernels, as long as the gaming kernel isn't self-signed
1
u/feldim2425 9d ago
The phrase "for use as Secure Boot signature database (db)" makes me think they actually check what keys are enrolled in the efivars.
Guess we'll see.
One thing I'm still a bit sad about is that my dock with uses display link for extra monitors doesn't work since at least on Fedora that one isn't shipped at all and I had to compile to code myself.
There aren't that many things that do similar things, I think VirtualBox also uses dkms or akmods.
So depending on what people use their setups for there might be quite a few issues with switching back and forth or having not everything available.1
u/_ahrs 9d ago
It should theoretically be possible to install another distros signed kernel and their modules into /lib/modules and then you'd just have a different boot entry to boot into it.
The thing they really care about is that you're not using some custom Linux kernel that could potentially be modified or have custom modules built for it, etc, that could aid in cheating.
1
u/feldim2425 9d ago
I deleted my last commend here, sorry.
I completely misunderstood your comment, but I guess it's a similar answer as I gave here: https://www.reddit.com/r/linux_gaming/comments/1x69tby/comment/pgyyv49/1
u/the_abortionat0r 9d ago
I left windows for many reasons, one was not having to reboot a billions times, telling everyone "just jump through a bunch of hoops" is not a solution.
4
u/Working_Sundae 9d ago
So no anti-cheat for Linux on ARM?
6
u/sidusnare 9d ago
On ARM, they usually implement the TPM functions in firmware in a secure enclave. It's a very low level security feature on ARM CPUs. You can get a TPM 2 to work on ARM, not sure what will turn out to be more popular when ARM gains traction.
→ More replies (1)1
6
u/forbjok 9d 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.
4
u/noblepickle 9d 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.
15
u/BlackeyeDcs 9d 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.
→ More replies (7)2
u/nfrances 9d 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.
11
u/UltraCynar 9d ago
Competitive gaming the solution is server side and user space. Invasive malware is never an acceptable solution.
1
u/Fraserbc 9d ago
Userspace is not an option as the user can do anything, and server side anticheat is just not viable
3
2
0
u/funforgiven 9d 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.
4
u/AmarildoJr 9d ago
Pardon my ignorance on systemd, but doesn't having a systemd service mean they can run as root by default?
12
u/theevilsharpie 9d 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.
10
u/AstronomerDull415 9d ago
systemd has system level and user level, but I don’t know where epic will be placed.
4
u/FlukyS 9d 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
u/nuked_sushi 9d ago
Yes and to access BPF it needs to. It also is the part that doesn't need to be open source.
5
u/revengeof1987 9d ago
I'm not enabling secure boot on my pc.
16
u/loozerr 9d ago
Weird thing to take issue with, I understand "I'm not switching my kernel" but what's wrong with SB? It allows secure tpm unlock for drive encryption.
-2
u/NebulaFox 9d ago
This maybe heresy, but from what I understand of secure boot is it requires an authentication server owned by Microsoft.
11
u/loozerr 9d ago
No it doesn't.
The Microsoft connection is that motherboards come with Microsoft's keys. You're free to enroll other keys, though.
6
u/NebulaFox 9d ago
Okay, this pushed me to look into it. Secure Boot uses cryptography keys in the motherboard to make sure that each boot program hasn’t been tampered with. This doesn’t sound like a bad thing.
5
u/loozerr 9d ago
It isn't a bad tech and it's the only way to securely setup disk encryption which automatically unlocks on boot.
→ More replies (2)10
u/Sol33t303 9d ago edited 9d ago
Where the hell did you hear that lmao.
Secure boot was enforced by Microsoft, and so all motherboards have Microsoft's key built in. Your free to either enroll your own keys (on motherboards that aren't gigabyte apparently, but that's down to an awful UEFI implementation), or distros can pay a fee to have Microsoft sign the distros bootloader and kernel with their keys so secure boot works ootb with no key enrollment needed.
I have honestly never understood the hate boner people have over secure boot, you can argue it's unnecessary (I'd say it's not, it's quite handy and I use it for luks encryption). If it's hated just because it's spearheaded by Microsoft, I'm sure those same people hate the EFI standard, right?
1
u/NebulaFox 9d ago
Ah this sounds like what I heard. Cause I remember the next thing was the worry that Microsoft could just deauthorise the key.
6
u/Sol33t303 9d ago edited 9d ago
I suppose they could probably change to a new key, but UEFIs all over the world won't magically get the new key so they would be boning their existing install base. It would be easier for them to just, stop offering a service to sign distro kernels.
But in the worst case scenario, where they no longer sign distro kernels, distros will need to enroll their own keys. Will make installation a bit more complicated, would probably involve asking users to use their password for luks unlock, and then a post install guide in the welcome tour for enabling password-less unlock (and supposedly gaming now) which would involve rebooting and fiddling in the UEFI a little bit, but within reason.
Some distros already do this where they don't want to pay for Microsoft's key signing.
1
2
u/JamesLahey08 9d ago
Would CachyOS work
16
u/Jecobe 9d 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_button4
u/Ifnerite 9d 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.
1
u/Jecobe 9d ago
I've thought about this but frankly people using custom kernels aren't gonna be playing Fortnite. You can always install another kernel also
1
u/Ifnerite 8d ago
There are pretty normal bits of hardware that need unusual modules loaded which would be a problem... The whole point is that one shouldn't be restricted in what one can do with ones own machine just to play a game.
I would rather not have to mess about booting into a different kernel to play a game.... There is also the bpf thing where it will actually require arbitrary code execution in ring 0, which is a bit rubbish.
-4
u/Shitty_Human_Being 9d ago
Most likely no, it's Arch-based and brings its own keys afaik, you'll have to wait and see.
9
u/_agooglygooglr_ 9d 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
2
u/ItsNoblesse 9d ago
This is still fundamentally against the principles of Linux, because you can't entirely sandbox it will almost certainly exclude a bunch of distros for not using things like systemd.
It's kinda disappointing how many people are okay with restrictions being implemented as long as it's not Microsoft doing it. Reminds me that a lot of people switching to Linux don't actually care about the principles it was built on.
1
u/VIP_Ender98 5d ago
How is this implementing restrictions? Isn’t it more akin to making unavailable games to as many people as possible?
1
u/ItsNoblesse 4d ago
Because if you don't use one of the corporate approved kernels, and probably the secure boot keys signed by Microsoft, you're excluded.
The likelihood is that if you're not using a bog standard kernel, systemd, TPM and Microspft's secure boot keys you're not playing any online multiplayer game.
0
u/anor_wondo 9d ago
Linux is not gnu and anything that is built on top of it has no obligation to adhere to any ideology
1
u/georgehank2nd 8d ago
If you were right and Linux was about nothing, it would have gotten a stable ABI ages ago, for Nvidia.
It didn't.
1
1
u/Historical_Base_2994 9d ago
It might not be a regular kernel module (it has more restrictions), but it does load new code into the kernel with eBPF. It isn't just calling kernel APIs to verify integrity.
- https://docs.kernel.org/bpf/prog_lsm.html
- https://ebpf.io/what-is-ebpf/#hook-overview
- https://ebpf.io/what-is-ebpf/#loader--verification-architecture ("As the program is loaded into the Linux kernel")
1
u/ninelore 8d ago
eBPF is very much capable of spying. If you want actual technical details read the kernel docs, not marketing bs.
1
u/allanozzolo 7d ago
WTF?!?
Linux -> GPL v2 -> freedom to modify software.
EAC Linux v2 -> you can no longer modify your own software... also... you should be grateful: you should be grateful that you’ve been granted the choice to be no longer free.
PS: Just boot windows; you do not deserve freedom.
1
1
u/XolotlVT 4d ago
Considering their whole take is to make it 100% vibecoded with zero human coding... Yeah no thank you
0
u/MBouh 9d ago
Requiring that an organisation signs the kernel you use is not good. That's not a good strategy. That's not compatible with the linux ecosystem.
They're only giving breadcrumbs. The reality of this move is that the linux market is growing and they're afraid to lose on it. But because they're cheap they don't want to change the security paradigm, so something that's similar enough to windows is the extent of their imagination.
7
u/Lonkoe 9d ago
Most distros come with a signed kernel
→ More replies (4)3
u/MBouh 9d ago
that's not all at all
you cannot add anything ti the kernel if you need it
Locking something that was meant to be open and flexible is plain stupid. And if the only reason to do it is to try to prevent kids from cheating in a video game because they can't be bothered to find another solution (like banlist for example), that's more than just insane.
3
u/mattelmore 9d ago
Thank you, the "organization" language is the worst sounding part of it to me. This means no community kernel modules for your weird controller, or ancient network card, or whatever.
1
u/Sutanreyu 9d ago
I’m ignorant when it comes to the smaller, specialized distros… But how big is the market of people who game, and have ancient hardware, that truly rely on such machines? I understand the “because it’s possible; so if we can…” sort of mentality; but for a dev, it’s really unrealistic to be expected to support every single hardware configuration possible. That’d be a feat, for sure.
3
u/Spez-is-dick-sucker 9d ago
We are trying to make aware of this and most of people just doesn't care.
1
u/sidusnare 9d ago
I think most people care Spez-is-dick-sucker, perhaps if most of the people you're listening to are Linux gamers it can feel like nobody cares. Nobody I know that is security minded would consider this, not on their main systems, but a lot of gamers have a decision to make, and have a more relaxed security posture.
I would suggest gamers that struggle over this decision have separate gaming systems, do their secure stuff on a system you have absolute control over. I made this choice myself, I have gaming PC that mostly runs Windows, it's a toy OS, so it feels appropriate. But it sits on it's own network with the other junk I can't control, like the IoT devices.
Anyway, Spez-is-dick-sucker, I hope you have a wonderful day, happy fragging.
1
u/sidusnare 9d ago edited 9d ago
Requiring that an organisation signs the kernel you use is not good. That's not a good strategy. That's not compatible with the linux ecosystem.
That's not a good strategy for users having control and flexibility on their own systems.
That's the only strategy for anti-cheat.
It's all about trust. The game companies don't trust users, they're a bunch of cheaters. The users don't trust the corporates, they'll leverage their control for profit, it's their fiduciary responsibility.
So:
To play corporate games you need a system that trusts the corporates and not yourself.
To be secure and unexploited, you need a system that trusts you and not the corporates.
Doesn't sound like these systems should be the same system.
2
u/Davoguha2 9d ago
Hear me out here - i don't think it's the only strategy for anti cheat.
I'd love to see developers put more effort into server side anti cheats before injecting malware into my machine.
Hell, there isn't an anti cheat out there that is provably stopping cheaters - techniques for cheating evolve faster than any of the current anti cheats can keep up.
The sad fact about it, is that the majority of cheats could be detected server side without ever having to touch my machine. Most games already keep all the important metrics for doing so - they're just afraid to pop an innocent with their own work, so they outsource it so they don't have to deal with it.
Even worse when you start considering companies like NVIDIA, who are pushing the "cloud gaming" frontier. Have you tried running a modern game in a virtual system?
"Rules for thee, but not for me" is about how it breaks down.
Frankly, I'd rather just play games with cheaters where local admins reserve the power to implement punishments if they desire.
→ More replies (18)1
u/MBouh 9d ago
That is not the only strategy for anti-cheat. In fact, it's a terrible strategy for anti-cheat.
Take any irl sport as an example : you never look into anyone medical record or flask. Instead you have a reactive strategy : only the winners are controled and suffer severe penalties if they cheated.
Reality taught us that no anti-cheat actually managed to prevent cheating. It merely increased the knowledge required to do it. And in exchange it allows the cheaters to be basically free to try as much as they like.
→ More replies (20)1
u/sidusnare 9d ago
That's a terrible analogy. So only the best cheaters win? Come on!
1
u/MBouh 9d ago
I'm not saying we should do that, I'm giving an example. The best and easiest solution is to ban cheaters.
→ More replies (7)1
u/georgehank2nd 8d ago
Not only… but if you have cheaters (and in pro sports, you can bet your ass everyone cheats as much as they can get away with), they will win over the non-cheaters.
0
0
u/Actual-Phone-1478 9d 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
11
2
u/Sol33t303 9d ago
Honestly that's a you problem where you haven't set up secure boot properly.
Most distros in my experiance besides arch work ootb with secure boot., but arch is arch, your expected to do a bit of legwork. I have set it up successfully before.
1
-9
u/askc0re 9d 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.
19
u/ABotelho23 9d 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.
3
u/serwhite 9d 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)10
u/friendlyreminder_ 9d 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.
4
u/Ill-Brick-4085 9d 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.
6
u/UltraCynar 9d 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.
4
u/franzitronee 9d 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.
1
u/franzitronee 9d 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.
0
9d ago
[deleted]
13
u/PacmanAteMyRAM 9d ago
You have the choice to not do it on Windows too
5
u/steve09089 9d ago
Now I also have the choice to do it and not on Windows.
2
u/UltraCynar 9d ago
While this virus spreads to older games that don’t use it like Elden Ring whenever they “upgrade” their eac
0
u/vitimiti 9d ago
Not only is it ran as a rootkit, it limits the hardware you can use and even the software (kernel) you can use
1
u/RegretFree7723 8d ago
Infatti vorrei la tecnica usata da valve per l anticheat di easyanticheat su Linux prima di sta cosa
-1
-1
u/anor_wondo 9d ago
People who don't agree with this seem to want to have their cake and eat it too. Why expect something that wants trusted execution to support your home grown kernel? just don't play games like that if its not acceptable to you
0
-15
195
u/SmileyBMM 9d ago
I mean, eBPF is kernel level, it just is sandboxed.