EAC v2 doesn’t use a kernel module. When a protected game launches, it checks the boot chain, then runs a systemd service and eBPF programs for as long as the game is open. The checks are:
kernel and all loaded modules signed with a key on Epic’s “well-known” list
Secure Boot on, with only well-known keys (including every enrolled MOK)
TPM 2.0 and measured boot
IOMMU on, passthrough off
lockdown=integrity on the kernel cmdline
kexec disabled
BPF LSM active
Epic wants distros to email them so their signing keys can be added to the list.
I went through what that would mean for NixOS out of curiosity. I’m not a maintainer, though
security.protectKernelImage disables kexec, but through the kernel.kexec_load_disabled sysctl. Epic says “explicitly disabled at boot time” and I don’t know if a sysctl is enough for them.
BPF_LSM is built in. I haven’t checked whether bpf is in the default active LSM list.
I also haven’t checked what lanzaboote’s stub measures. Epic says systemd-boot and GRUB measure by default.
Also:
kmodigest gives each module its own cert, built into the kernel image, so there’s no distro module signing key in the usual sense. If the kernel image is signed with a well-known key, would Epic accept that for the modules? Probably better to ask them now than after everything’s merged.
Hydra doesn’t build unfree, so the nvidia module can’t be signed by anything official. Fedora has the same problem with akmods and MOK, so NixOS wouldn’t be worse off than them, but it’d still lock out a lot of people.
Epic says a separate boot entry only for protected games is fine. On NixOS that’s just a specialisation, so you could keep your own kernel and keys day to day and boot the signed one when you want to play.
Mostly I’m asking if anyone involved cares about this at all. “Not a goal” is a fine answer, the boot security work doesn’t need Fortnite as a reason to exist. But Epic is talking to distros right now, and if someone does want to reach out, the page lists linux-gaming@epicgames.com (the mailto link actually goes to eac-linux@epicgames.com).
TL;DR: We currently don’t have a NixOS.org-signed boot chain, so until the autopen work is done, we can’t do anything about this; there’s no point reaching out until then.
I get that without a NixOS-signed boot chain there’s nothing Epic can add to their list yet. But I don’t really see why that means we shouldn’t even start a conversation with them. I think this is going to take Epic quite a while. They want to try it on Fortnite first and only later open it up to other games, and they already say the requirements will change over time based on feedback from distros. So there’s no need to have everything ready before we talk to them.
Also, from what I understand, autopen isn’t just something that needs to be “done”. There are probably things we still need to decide as a community too. Talking to Epic now could help us understand if what’s planned in #549372 would actually meet their requirements, and if it has any implications for how we implement it (like the kernel module question in the first post). Better to know that while things are still being decided. And if we talk to them early, we get to explain how NixOS does things before everything is set in stone.
If we’re not even willing to think about starting a conversation, it’s a bit like admitting that we can’t handle this, or that we don’t really have a plan for getting past that first hurdle. From the outside, the message is basically that NixOS isn’t gaming-friendly. It’s not every day that a company this big opens up to Linux and asks distro maintainers to get in touch. Fedora, Ubuntu, Debian and a few others are already on their list, and it would be nice if NixOS was at least on their radar. I think being part of this conversation could be good for NixOS and for Linux in general. I just don’t see a reason to rule it out from the start.
Just my 2 cents, as someone who’s involved in NixOS but isn’t a maintainer.
Mod ruling: Pangram isn’t perfect, and I’m choosing to take @sidharthify at their word here. For reference: Discourse LLM Policy.
Thank you all for being polite and reinforcing our community norms; let’s end that digression here until and unless future posts change my opinion on the matter.
I’m co‐lead of the end‐to‐end NixOS boot security project and the author of autopen and kmodigest. The goal of our project is to upstream the functionality required to allow simple production‐ready deployments of NixOS systems that support Secure Boot, comply with the shim review board requirements, and can be measured up to the stage 2 system closure.
However, that still leaves a lot of infrastructural and political requirements left to deal with for these aspirations. Getting official first‐party NixOS hardware‐backed signing keys deployed, successfully going through the shim review process and Microsoft signing, and coordinating with Epic to get NixOS trusted would all individually be significant further milestones beyond the current technical work. (I would recommend anyone worried about the ability to have NixOS suitable for wide trust by the shim review board, Epic, etc. focus on NixOS GitHub infrastructure security needs improvement · Issue #246 · NixOS/org · GitHub rather than the details of Secure Boot support!)
In other words: I wouldn’t be holding your breath to play Fortnite on NixOS when EAC Linux v2 launches! That said, I don’t think there should be any technical obstacle to having NixOS trusted by Epic. The requirements seem wholly compatible with our work:
We are targeting Secure Boot with signed kernel images, and being suitable for centrally‐managed rather than per‐system signing keys is an explicit goal.
The concern about kernel module signing is a red herring. By default, the kernel build system generates a fresh ephemeral key for every single individual kernel build that it uses to sign the built‐in modules (hence “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”).
The shim review board expects the use of ephemeral keys or a comparable security mechanism. So Epic cannot feasibly maintain a fixed list of kernel module signing keys while supporting mainstream distributions, and it wouldn’t make sense for them to do so; they trust all kernel images signed by a trusted distribution’s key, and the compiled‐in certificate list used for the ephemeral key is part of the kernel image that gets signed. Auditing the built‐in certificate list wouldn’t stop a distro from signing a modified kernel image that skips module signature verification entirely, or otherwise embeds malicious code directly in the kernel rather than by trusting a key used to sign a malicious module!
The kmodigest certificates are embedded directly into the built‐in certificate list of the kernel image that gets signed, just like the standard ephemeral keys, and their security properties are strictly stronger than ephemeral keys.
Therefore, I’m quite confident that this shouldn’t be an issue at all; I believe that the wording in this requirement is instead referring to out‐of‐tree modules signed with long‐term signing keys, such as ones inherited from shim, and explicitly signalling that setups that use MOKs to sign kernel modules will not be supported. In NixOS, we will just derive deterministic kmodigest certificates for all the out‐of‐tree modules that we approve for use on Secure Boot systems, and embed those into the signed kernel images along with the certificates for built‐in modules.
Once the hash‐based module integrity work lands upstream, I expect other distros to adopt it due to the limitations of the ephemeral key approach for reproducible builds. The trust model there will be the same as kmodigest; we’re just getting ahead of the curve.
Our plans for TPM 2.0‐based Measured Boot go well beyond the basic bootloader requirements listed by Epic.
IOMMUs can be enabled on NixOS today; it may be reasonable to enable them by default for signed kernel images, or at least offer it as an option.
Kernel lockdown is a shim review board requirement, and compatibility with it is already driving much of our design requirements.
The kexec part is a bit odd; lockdown enforces that kexec will only boot signed kernels, so “abused to load a modified kernel” doesn’t seem possible to me. It is true that the interactions with Measured Boot and UKI stubs haven’t been fully worked out upstream, however. It probably makes sense for us to disable kexec on Secure Boot systems until that’s sorted, whether through sysctl.kernel.kexec_load_disabled on the kernel command line or some other route.
The BPF LSM is already available on NixOS and is being integrated further to support newer systemd functionality.
There would of course be limitations involved for systems that want to be compatible with the requirements; not being able to use MOKs would mean users choosing between full control over customizing their boot chain and Fortnite. I also can’t speak to what the userspace side of this would look like and how their systemd service would behave on NixOS; it will presumably ship as a proprietary binary with the FHS dynamic loader path, for instance, and I don’t know how it would react to PatchELF. But their boot security requirements are largely table stakes for any distribution implementing Secure Boot with a Microsoft‐signed shim, so I wouldn’t expect any issues on that front.
Hopefully that answers concerns about the effort’s ability to handle these requirements or whether there is a plan. We are currently focused on the technical work required to provide a foundation for Secure Boot support, so initiating a conversation with Epic about trusting non‐existent signing keys would certainly be premature when we haven’t yet added support for signed systems at all! There may be a discussion to have with them about NixOS support more generally, though; any issues would more be related to their software working on NixOS at all than their security requirements. (Please don’t email Epic if you’re not involved in the work, as it will only risk being spammy for both them and us!)
That work will be fantastic, thanks for your effort @emily.
In the meantime, it might make sense to package something like the Universal Blue binary kernel and Fedora’s shim. We’d of course lose some good parts of NixOS (a declarative kernel) but the FAQ says “you can easily toggle between an anti-cheat compatible boot path” which is very easy with NixOS’ specialisations - but that might require sorting out using shim with both Fedora signed kernels and unsigned/self-signed ones.
