Lol Epic Games should have stopped being relevant after the 90s.
this post was submitted on 27 Oct 2026
240 points (98.0% liked)
Linux Gaming
28126 readers
198 users here now
Discussions and news about gaming on the GNU/Linux family of operating systems (including the Steam Deck). Potentially a $HOME away from home for disgruntled /r/linux_gaming denizens of the redditarian demesne.
This page can be subscribed to via RSS.
Original /r/linux_gaming pengwing by uoou.
No memes/shitposts/low-effort posts, please.
That includes posts generated by LLMs. It doesn’t matter if you “don’t have the time” or “would’ve written the same anyway”, or if “everyone’s doing it geez get with the times”.
For now it’ll also include “AI”-assisted projects that haven't had at least two months of (public, verifiable) dev time behind them.
Resources
Help:
- ProtonDB
- Are We Anticheat Yet?
- r/linux_gaming FAQ
- Fork of an earlier version of the above
- PCGamingWiki
- LibreGameWiki
Launchers/Game Library Managers:
General:
Discord:
IRC:
Matrix:
Telegram:
founded 3 years ago
MODERATORS
For those unfamiliar, CachyOS doesn’t ship a single kernel…
Well, they ship a default kernel, yes, but one is immediately presented with a dedicated GUI for swapping between them.
There are all sorts of variants. There are kernels with different schedulers, a server/workstation kernel, a “deckified” kernel, a LLVM built kernel, and all sorts of niches optimized for specific applications. Making switching frictionless is central to CachyOS, hence they build variants for different CPUs, and drivers paired to each one, so you don’t even need dkms to switch between them.
They are adding an EAC kernel + guide as an option.
It’s yet another niche option.
That is a critical distinction. I don’t judge people for all the weird niche stuff they want to do on their PC; playing Fortnite isn’t even in the top half of that weirdness. Providing that as an option is fine.
…If they were to ship it by default?
Yeah. Then I would be concerned.
Yeah I can just choose what kernel I want to use in Limine.
Exactly. I personally have 4 different kernel presets in systems-boot, all for different thunks I use the PC for.
But didn't Exact Audio Copy stop at v1.8?
Linux not being able to run Fortnite was a feature, not an issue.
TBH, Epic Games EACv2 looks decently well designed, and robust:
Requirements:
- Signed Kernel & Kernel Modules
- TPM 2.0
- Secure Boot
- Measured Boot
- Input-Output Memory Management Unit (IOMMU)
- Kernel Lockdown Integrity Mode
- Kexec Disabled
- Linux Security Module BPF
- systemd service (with hopefully introspectable code) which all it does is checks the above and gives a verified bool (also locks memory regions for Epic games)
Generally it is a good system of locking down any potential paths for code that can work on other processes' memory.
Signed boot kernel is big problem for most distros (though most people don't modify their ramdisk, or cmdline, so... probably fine?). Kernel modules would be iffy too, I guess, but presumable even for Arch it would mean .ko from only the official repos. The others are just annoyances.
Would not be a huge amount of pain to set this up for distros. Definitely political momentum is not there and I think will never be. Linux is just a different beast and won't bend to their corporational "Lock it down!" mentality, better find other ways to combat cheating.
I have yet to see a machine that doesn't have a tainted kernel (meaning the kernel wasn't signed, a module wasn't signed, or both) in the wild. Not even with Ubuntu.
At the same time, requiring TPM 2.0 is the same anti consumer thing Win11 did.
Secure boot is a pain to set up on Linux because it was never meant to be for Linux. It's a Microsoft invention that Microsoft holds the keys for.
Kexec is useful on a lot of machines for faster reboot times, and disabling it can make them significantly longer.
LSM BPF is scary and sketchy, especially if you're giving a proprietary blackbox access to it. You should not have random software accessing that.
Actually, I setup secure boot, it isnt that much of a pain. If the docs were more clear, it's like a nice 4-7 commands, with some reboots (clarity missing in arch wiki)
Congrats CachyOS. Now you get to wait for Epic to approve any new release or risk losing all your users who will come to depend on EAC.
Hell yeah let's BACKDOOR ALL USERS to accommodate a single PRIVATE CORPORATION HELL YEAH
Hmmm... do I want to run unverified code in my kernel from the "Programming is too hard!" guys?
No.
We need to keep boycotting Epic Games.
That's not what this is doing. From my understanding, the kernel doesn't include any new code made by Epic. It just needs to support Secure Boot and a bunch of other requirements, all of which are already possible with existing Linux solutions.
The anti-cheat wants to verify that you haven't fucked with your system, there are ways to do that and EAC requires that your setup can credibly after attest to it.
Video going over the requirements (with timestamp): https://youtu.be/3Xi7m0CYk5s?t=7m39s
Source: https://onlineservices.epicgames.com/news/introducing-easy-anti-cheat-linux-v2
On Windows, we rely heavily on a kernel driver to protect the games. This driver isn’t always on, it starts when a game is launched and stops when the player exits. For EAC Linux v2 we will not leverage an equivalent kernel module, and instead we’ll take full advantage of existing Linux platform security features like measured boot, the kernel lockdown LSM, and IOMMU support, plus our own eBPF logic to maintain integrity and detect cheaters. These security features are not available on every distro and may require configuration changes to activate.
I agree with your sentiment though. But somehow, against all odds, the "programming is too hard" people landed on a solution that sounds pretty good to me.
eBPF does run in kernel mode.
Maybe better than a module, but I wouldn't say "the kernel doesn't include any new code"
It's also why they have to use "integrity" mode of kernel lockdown
If they used "confidentiality" mode, their eBPF code would be untrusted by the kernel and couldn't be loaded
The problem is not the high-level solution. If the anti-cheat does what they claim -- great.
If.
The problem is that EACv2 itself is unverified machine code running with elevated privileges. Unless the source code is released, it will be impossible to know what kinds of shenanigans it engages in. It demands that users trust it implicitly, along with the people and clankers that wrote it, the mistakes they made, and the people and interests they are beholden to.
Trust should be earned, and the fact that people have been indoctrinated to give it away freely should be deeply concerning to everyone.
If you wanted to test it, you could try sandboxing it to run as an unprivileged user with access to nothing else on the operating system. They claim it will run without needing sudo or root.
I'm not gonna test it though. I'm not willing to use a distro that doesn't let me compile and install my own kernel modules.
[edit] I read a bit more, looks like they are allowing unprivileged code into the kernel. That's apparently what eBPF does.
Stay far away from this project.
what eBPF does
Holy shit, that's like curl | sudo bash on steroids. Fucking hilarious.
I don't care how good the solution is, I'm not having my shit get attested for no good reason. If needed I'll just wait for a game to get cracked. I'm not installing any anti-cheat enabling bullshit.
Someone on reddit wondered if this is the embrace phase of embrace, extend, extinguish.
This is what most people arguing in favor of this don't get. This changes the entire ecosystem via some kind of peer-pressure once more and more game developers implement EACv2 (from the side of both developers as well as players). And other AC vendors like BattlEye will likely also follow suit. Imagine letting Tim into your kernel... I'm not even letting Gabe into my kernel.
Also RIP custom kernel modifications/tweaks for the sake of performance or new features if you want to play any future game which will implement EACv2. Also RIP applying in-development or bugfix patches, especially AMDGPU ones. And RIP OOT modules for niche hardware that's not packaged by the distro.
https://www.reddit.com/r/linux_gaming/comments/1xgm7qi/comment/19rq81f8dnsyt/?context=3
...modules for niche hardware that's not packaged by the distro.
...like the current Nvidia drivers that you need to build (and sign in case of secure boot) the kernel module for ?
There's a reason people recommend AMD over NVIDIA for Linux use.
load more comments
(4 replies)
load more comments
(1 replies)
If you're stupid enough to install an Epic store, you don't deserve a Linux distro holding your hand.
I understand why this might appeal to some gamers, I really do. I promise I sympathize, but if you're willing to run EAC on your Linux install it's worth asking why you're running Linux and what you think you're getting out of it?
At this point we're starting to see some better gaming performance due to good compatibility layers and Microsoft just repeatedly shooting themselves in the dick, but for me at least a large part of it was escaping that ecosystem that gives them control over your system. Giving them that kernel level access so you can keep playing Fortnite is a devil's bargain. Seriously, please find a new game and I'm trying to convey that in the least judgmental way possible.
I don't play EAC games, so I don't really have a stake in this.
There are plenty of reasons to run Linux apart from "I want complete and utter freedom" or something like that.
I would gently remind you that we have been giving kernel-level access to e.g. Nvidia for decades too.
It's a trade-off, and there are still plenty of actual day-to-day practical benefits of running Linux beyond philosophy.
Valid points, I type from a laptop running proprietary drivers. But I do argue there's a difference worth considering what Nvidia might be doing with those closed drivers (something that does increasingly worry me given the current state of things) vs. the much more clear intent of what Secure Boot and TPM implementations are outright stating they intend. These are documented DRM applications with direct control over your system, mostly right of denial, over what software you can or can't run depending on the state it's in and what they think about it.
It's not a zero sum game, every choice matters and comes with its own weight. I understand making these philosophical arguments is difficult and tedious, but if you don't at least make them, there are a lot of people who aren't ever going to hear them. EAC is the wide open door to demanding you run services, telemetry, and online accounts on your Linux system enshittifying that, too.
load more comments
(4 replies)
EAC on your Linux install it’s worth asking why you’re running Linux
Why is that even a question? Running EAC doesn't undermine why you run Linux (which can have many different reasons). It's not like EAC takes over your PC like on Windows. The Linux implementation is completely different and uses Linux features, controlled by Linux and not the EAC anticheat. EAC cannot do whatever they want and they don't get root rights (unlike Windows version of the anticheat).
Which I'm very grateful for since Helldivers just switched to it
I thought Helldivers is playable on Linux already?
You misunderstand me: I'm grateful that the current Linux EAC doesn't do kernel/root level bullshit like the Windows version because Helldivers players just got it foisted on us
Ah I see. Mee too. I was playing a lot Marvel Rivals, and their anticheat doesn't have this rootkit behavior, nor is it even possible without giving it root access.
load more comments
(14 replies)
This seems worse than just dual booting Windows, which you'd end up having to dual boot Linux if the reason you got into Linux was to get away from sketchy permissions.
I don't like the normalization of this type of anticheat for Linux, and if other games adopt this it seems like this would lead to a worse situation than having games not support Linux if more Linux games start adopting this EACv2 requirement.
load more comments
(10 replies)
I've made this comment before, but to reiterate, I think that consoles are generally a better solution for competitive multiplayer games.
Consoles were designed from the ground up to be locked down. PCs were designed to be open and modifiable. Trying to figure out ways to jury-rig a PC to act locked-down is always gonna be an uphill battle.
Also, since this is for competitive multiplayer games, consoles also provide a level playing field on hardware. No pay-to-win "buy this hardware to get an edge" stuff. There's a whole industry of PC "gamer" hardware sold using basically "pay to win" marketing.
PCs are nice because they're open. That lets you make one faster or prettier or use any input device or rig up macro software or mod games, fiddle with memory or whatever. And that's a good thing for games that aren't competitive multiplayer games. You can play the game however you want, and it's not like it negatively affects anyone else. But that same characteristic that's an advantage for non-competitive-multiplayer gaming is a drawback for competitive multiplayer gaming.
For competitive multiplayer gaming, you want a platform that provides equal footing for all players as much as possible and is hard to modify, and that's what consoles do well.
You don't need to force competitive games to console to do this, just have the tournament or league provide the hardware for tournaments. If a "pro" shows up and suddenly sucks when playing on the league machine then you figure out pretty quick they are getting help from something.
Also, consoles doesn't stop cheating. This is the same mentality that thinks EAC or Vanguard stops cheating. Hardware cheat tools can work on console exactly as well as they do on a PC. There are already plenty of options for people that really want to cheat that the host computer doesn't even know about, just sees a standard mouse and/or keyboard plugged in. This can do the exact same thing with a console and a controller.
load more comments
(4 replies)
load more comments
(18 replies)
view more: next ›