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_disabledon 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!)