Summary
Despite whatever was hinted at in the past, it was only a matter of time until Fortnite came to Linux. Epic Games recently launched a preview of its vibe-coded EGS game client for Linux as a native app — along with a rather lengthy post on porting Easy Anti-Cheat to Linux systems. This article also happens to explicitly mention that Fortnite will be (officially) coming to Linux very soon, even if it has been on other platforms for a while now. While this is indeed a victory for Linux gamers, there’s far more in the fine print than you’d realize at first glance. There are some legitimate challenges in porting anti-cheat software to Linux Kernel-level anti-cheat does not behave nicely Kernel level anti-cheat relies on Ring 0 access on Windows to work. Linux does not allow for this kind of behavior by default and is less “secure” by this comparison. The client and server need to establish a stable connection that provides regular assurances of the game being untampered. Modern cheat programs are quite complex, and a kernel-level solution is often the only way to detect them these days. To be clear, it’s not like anti-cheat hasn’t worked on Linux before. Easy Anti-Cheat v1 and more do work, but it’s more often than not an opt-in toggle for most developers. It doesn’t help that most developers choose to ignore Linux players, often blocking online access entirely in the name of security. Anti-cheat is legitimately tricky to set up on Linux, since there are far too many pitfalls and no standards when it comes to its implementation. A Linux-specific version of anti-cheat that actually works would then require privileged access, and Epic Games’ Easy Anti-Cheat Linux v2 aims to be that standard, even if it might open a can of worms in the process. Epic Games’ solution is no better than Windows’ own cumbersome setup Secure Boot is just the start of it To ensure a secure environment, Epic Games mandates the following requirements to be able to play EAC v2 games on Linux systems:
- Hardware TPM 2.0 module to be present.
- Secure Boot must be enabled.
- Signed, non-custom kernels with signed modules are a must.
- IOMMU must be enabled — with passthrough disabled.
- Kernel lockdown integrity mode must be enabled, which prevents root users from tampering with the kernel.
- Kexec must be disabled to prevent kernel swapping to a modified kernel mid-runtime.
- The BPF Linux Security Module must be installed and authenticated during a first-time systemd service setup for EAC v2 to work. As you can see, the list is extensive and depends on a lot of components for the anti-cheat to work. In many ways, this is no different from using Windows 11 with Secure Boot and TPM 2.0 enabled, and so the issue of a cumbersome setup process remains. In fact, I’d argue it’s more of a pain to set up on Linux for what is essentially not needed most of the time. Still, this is a one-time setup. Assuming you’ve followed the prerequisites, this should successfully authenticate the OS and let you boot into games like Fortnite on Linux without any further configuration. Trusting Epic Games‘ modules on the other hand (along with their implications on user privacy), is a different matter entirely. This is no better than kernel-level anti-cheat BPF modules aren’t my thing While EAC v2 might not advertise itself as a kernel level driver (it technically isn’t), the way it functions is worth scrutinizing. EAC v2 uses a systemd service that starts every time you launch an Easy Anti-Cheat protected game, making use of eBPF programs to maintain a “safe” environment. Thankfully, this isn’t meant to run in the background all the time, but I’m wary of installing a systemd service that monitors my PC. It just sounds like a disaster waiting to happen; no anti-cheat software is truly bulletproof, after all, and I expect vulnerabilities to creep up. Obtaining secure key certificates is also a bit of a hassle. I use Arch Linux, and it’s currently not on the list of supported entries, which means I’ll be locked out of Fortnite until Arch figures things out with Epic Games. Combine this with Secure Boot, TPM 2.0, and a bunch of other hardware attestations, and it just turns out to be a real pain to set up. I’d much rather play anything else and move on, or just configure a separate Windows box with these games. Epic Games does offer a bit of leeway here, though. You can always maintain two separate boot entries — one with your usual custom kernel/modules and the other with the signed kernel and modules exclusively for playing EAC v2 games. You might not like it, but expect this to be the only option moving forward Like it or not, this might be the only way forward. BPF modules and Secure Boot with signed keys might be the only way to ensure that a machine is “uncompromised” and fit to run a legitimate copy of the game. A lot can be said about anti-cheat and the need for its existence. If this were an ideal world, we would never need anti-cheats, being able to run all games on Linux through Wine/Proton as is. Unfortunately, the world is far from perfect, and cheaters are a real issue in online games, ruining friendly matches for everyone. Epic Games’ solution seems like the only viable, long-term option here, and it’s okay not to like it. And all of this relies on Epic Games keeping these modules open-source. Assuming they do take the open-source route, I personally see no reason to not give it a try (albeit in a separate machine or boot entry). More game support on Linux is always appreciated. If not, there will be a trust problem. There is no way I’m installing unverified modules without knowing what they do first — it’s just bad security practice. Unfortunately, we don’t have any decent alternatives. This might just be a necessary compromise to popularize gaming on Linux. But at least we have a choice.