Easy Anti-Cheat (EAC) has supported native Linux game clients since 2014. In 2021, we added support for running Windows game builds on Linux via Wine/Proton. However, that support is opt-in for each game and many haven’t opted in because our Linux implementation couldn’t offer the same level of protection as our Windows implementation. This is why Fortnite isn’t available on Linux yet, but it’s coming.
Cheating in online games was once a small cottage industry, but it has become a billion-dollar market where cheat operators sell subscriptions for cheating tools that are updated frequently and require minimal technical skill to use. Without effective anti-cheat measures, these operators can drive enough players away from a game that it's no longer financially viable for the game developer to run.
The long-term solution
The ideal solution for a cheat-free gaming environment is one where the operating system provides assurances to players that their data remains isolated from both anticheat and game companies while also ensuring that the gameplay cannot be tampered with. There have been many efforts over the years to build solutions like this including virtualization techniques to enable cheat free gaming, but to date they haven't gained traction. We hope they soon will, and we'll work with all willing companies in the industry to make this happen in the future. This includes continuing the Easy Anti-Cheat team's open line of communications with Valve to support Steam Hardware devices to the maximum extent technically possible.
The immediate solution - What Epic is doing right now
To close the gap for Linux, we are rebuilding our Linux anti-cheat implementation into EAC Linux v2. We will bring the level of protection much closer to par with Windows, in the very near-term, using existing Linux features including signed kernel, signed kernel modules, and secure boot with attestation. These requirements build on work that distribution maintainers already do, and the more distributions that meet these requirements by default, the fewer players will need to change their setup to play.
We are starting to reach out to leaders in the Linux community, and will continue to engage with more leaders in the coming weeks as we work towards bringing more awesome games to Linux. Later this year, we will co-host a panel discussion with Jef Spaleta (Fedora Project Leader) where we’ll talk through the path to enabling fair competitive gaming on Linux for players.
We are also planning to pilot EAC Linux v2 in Fortnite first, where we’ll test it in a live environment and refine it based on what we learn. Once we’ve validated EAC v2’s effectiveness, we’ll make it available to more game developers so they can bring their multiplayer games to Linux players too.
Join the initiative
If you maintain a Linux distribution, we want to connect with you. If you haven’t been contacted by us already, reach out ASAP to linux-gaming@epicgames.com. We’ll answer any questions you have about getting your distribution aligned with our configuration requirements to get your signing keys added to our well-known list. The list is a core part of how EAC Linux v2 verifies systems, so we’ll maintain it to start. Our goal is to make the well-known key list open source, and we welcome PRs from the community to expand it.
When launching a game using EAC Linux v2 for the first time, players will be prompted to install an anti-cheat systemd service which runs only while a protected game is running. For games that already have the existing EAC Linux support activated, developers will be able to choose whether they want to continue using the older anti-cheat implementation for maximum compatibility or switch to EAC Linux v2 for better cheat protection.
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.
Let’s go through the system requirements for EAC Linux v2 one by one. We expect to iterate on these requirements over time, and we appreciate feedback from developers and distribution maintainers to help refine them.
1. Signed Kernel & Kernel Modules
A custom kernel can easily be modified to bypass integrity checks and return false data to anti-cheat. That’s why we require that the kernel binary in use during anti-cheat protected gameplay is signed with a well-known key.
Unlike Windows, most Linux device drivers are part of the kernel source code directly (in-tree) and will be compiled and signed by your distribution alongside the kernel. 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.
2. TPM 2.0
The TPM is a hardware feature that provides security primitives like extend-only Platform Configuration Registers (PCRs) which enable a tamper-resistant boot log to be produced and verified. During boot, each piece of the boot sequence (firmware, boot manager, Linux kernel) can record metadata about the code that will run next and update the extend-only registers. This is extremely valuable, because when properly used, it enables an application like anti-cheat to know what code ran at boot without running at boot itself.
TPM 2.0 is standard on modern consumer hardware, and software support is built into the Linux kernel. We require that systems have TPM 2.0 support and that it is enabled in the BIOS.
3. Secure Boot
Secure Boot authenticates the boot chain. Firmware will only execute a boot manager that verifies against a key in its UEFI key database, and the boot manager is expected to validate the signature of the kernel it loads. This prevents EFI-based cheats or others that run during the boot chain. We require that Secure Boot is enabled in the BIOS and only well-known keys are used to boot.
4. Measured Boot
Measured boot is the process of actually recording metadata about the system configuration and code that will run next, then updating the extend-only registers accordingly. Linux boot managers like systemd-boot and GRUB typically perform these measurements automatically by default. Other boot managers may not support them at all or only perform them if a special configuration is applied. We require these measurements to be present.
5. Input-Output Memory Management Unit (IOMMU)
IOMMU is a hardware technology that controls access between DMA-capable hardware devices and physical memory. When fully activated, it prevents hardware cards designed for cheating from accessing a protected game process. For non-handheld devices, we require that IOMMU is enabled in your system's BIOS and the Linux kernel is configured with IOMMU enabled and passthrough disabled.
6. Kernel Lockdown Integrity Mode
Kernel lockdown is a built-in security feature designed to prevent root from tampering with the kernel. In integrity mode, it blocks root from performing many operations that could be abused for cheating or bypassing integrity checks, like loading unsigned kernel modules, writing to physical memory, or writing to CPU MSRs. We require that lockdown integrity mode is explicitly enabled at boot time.
7. Kexec Disabled
Kexec is a Linux kernel feature that loads a new kernel into a running system without a full reboot cycle. Because parts of the normal boot flow are skipped, measured boot outputs no longer reflect the running kernel or its configuration. This could be abused to load a modified kernel—or change kernel options—to enable cheating without leaving traces in the measured boot log. We require that kexec is explicitly disabled at boot time.
8. Linux Security Module BPF
The LSM BPF feature enables eBPF programs to use Linux Security Module hooks for granular access control and monitoring. This enables anti-cheat to restrict other processes from reading or writing protected game process memory without needing a kernel module, as well as monitor for cheats loaded in different ways. We require the BPF LSM to be loaded and active.
A custom kernel can easily be modified to bypass integrity checks and return false data to anti-cheat. That’s why we require that the kernel binary in use during anti-cheat protected gameplay is signed with a well-known key.
Unlike Windows, most Linux device drivers are part of the kernel source code directly (in-tree) and will be compiled and signed by your distribution alongside the kernel. 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.
2. TPM 2.0
The TPM is a hardware feature that provides security primitives like extend-only Platform Configuration Registers (PCRs) which enable a tamper-resistant boot log to be produced and verified. During boot, each piece of the boot sequence (firmware, boot manager, Linux kernel) can record metadata about the code that will run next and update the extend-only registers. This is extremely valuable, because when properly used, it enables an application like anti-cheat to know what code ran at boot without running at boot itself.
TPM 2.0 is standard on modern consumer hardware, and software support is built into the Linux kernel. We require that systems have TPM 2.0 support and that it is enabled in the BIOS.
3. Secure Boot
Secure Boot authenticates the boot chain. Firmware will only execute a boot manager that verifies against a key in its UEFI key database, and the boot manager is expected to validate the signature of the kernel it loads. This prevents EFI-based cheats or others that run during the boot chain. We require that Secure Boot is enabled in the BIOS and only well-known keys are used to boot.
4. Measured Boot
Measured boot is the process of actually recording metadata about the system configuration and code that will run next, then updating the extend-only registers accordingly. Linux boot managers like systemd-boot and GRUB typically perform these measurements automatically by default. Other boot managers may not support them at all or only perform them if a special configuration is applied. We require these measurements to be present.
5. Input-Output Memory Management Unit (IOMMU)
IOMMU is a hardware technology that controls access between DMA-capable hardware devices and physical memory. When fully activated, it prevents hardware cards designed for cheating from accessing a protected game process. For non-handheld devices, we require that IOMMU is enabled in your system's BIOS and the Linux kernel is configured with IOMMU enabled and passthrough disabled.
6. Kernel Lockdown Integrity Mode
Kernel lockdown is a built-in security feature designed to prevent root from tampering with the kernel. In integrity mode, it blocks root from performing many operations that could be abused for cheating or bypassing integrity checks, like loading unsigned kernel modules, writing to physical memory, or writing to CPU MSRs. We require that lockdown integrity mode is explicitly enabled at boot time.
7. Kexec Disabled
Kexec is a Linux kernel feature that loads a new kernel into a running system without a full reboot cycle. Because parts of the normal boot flow are skipped, measured boot outputs no longer reflect the running kernel or its configuration. This could be abused to load a modified kernel—or change kernel options—to enable cheating without leaving traces in the measured boot log. We require that kexec is explicitly disabled at boot time.
8. Linux Security Module BPF
The LSM BPF feature enables eBPF programs to use Linux Security Module hooks for granular access control and monitoring. This enables anti-cheat to restrict other processes from reading or writing protected game process memory without needing a kernel module, as well as monitor for cheats loaded in different ways. We require the BPF LSM to be loaded and active.
FAQ
Does EAC Linux v2 use a kernel driver?No. EAC Linux v2 does not install or load an anti-cheat kernel module. It uses security features already provided by the Linux kernel, together with an anti-cheat systemd service and eBPF programs.
Does EAC Linux v2 run in the background all the time?
No. It includes a systemd service, but the service only starts when a protected game starts and it stops when the game exits.
Do I have to keep my machine configured to meet these requirements all the time if I only play protected games sometimes?
No. EAC Linux v2 checks these requirements when you start an anti-cheat protected online game. You can maintain a separate boot entry with the required kernel and command line, and select that entry when you want to play a protected game.
What keys are considered well-known?
Here is a current list of keys that are considered well-known for use as Secure Boot signature database (db) keys and Machine Owner Keys (MOKs), which we plan to expand over time:
- Canonical Ltd. Master Certificate Authority - used by Ubuntu and derived distros like Linux Mint
- Fedora Secure Boot CA - used by Fedora and derived distros like Silverblue
- Universal Blue - used by Bazzite, Bluefin, Aurora, and derived distros
- Debian Secure Boot CA - used by Debian and derived distros
- openSUSE Secure Boot CA - used by openSUSE and derived distros
- SUSE Linux Enterprise Secure Boot CA
- Rocky Linux Secure Boot Root CA
- Microsoft UEFI CA - used to sign non-Microsoft components like the Linux bootloader shim project
Can I generate and enroll my own Secure Boot keys to use with other boot options?
Yes, EAC Linux v2’s well-known key requirement only applies to the keys used to verify the boot chain and kernel modules for the boot session where a protected game runs. This means you can easily toggle between an anti-cheat compatible boot path for playing protected games and one that you control yourself using your own keys for any other situation.
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.
What about Steam Deck?
The Steam Deck does not support the required features for our EAC v2 solution, but we are actively talking with Valve and hope to support it in the future.
Will my account be banned for cheating if I accidentally start a protected game without meeting these requirements?
No, you will just see an error message.
Do you use server data to detect cheaters?
We do. It’s a great additional layer, but it’s not sufficient alone.
If someone makes a cheat that works on EAC Linux v2, does that mean it’s not functioning as intended?
No, anti-cheat always requires regular updates to remain effective. The goal of EAC Linux v2 is to create a strong foundation that updates will build upon, and also to raise the cost of developing and maintaining cheats so that a typical player rarely encounters a cheater.