Because your kernel could have the ability to allow a program to modify the game memory and hide the fact it's doing so?
Most Linux users are probably using a signed kernel. I don't think this is as big of a deal as you're making out.
I understand this, and my contention with this is that a signed kernel could have that too, so requiring the kernel to be signed locks us into very few ways of getting the kernel with little benefit to the AC if a key is leaked.
> Most Linux users are probably using a signed kernel. I don't think this is as big of a deal as you're making out.
I don't think this is true of most people interested in gaming on Linux in particular. Aside from that, the chain of things you need to do to prove you have a signed kernel are onerous and incompatible with many bootloaders and other tools many Linux users use regularly.
The goal here is to expand support to games that have chosen not to opt-in to user-mode anticheat, which isn't going to happen without some form of kernel protection.
With that said, I'm pleasently surprised that Epic's initial list of supported signing keys includes a number of noncommercial entities (AlmaLinux, Debian, Rocky Linux, Universal Blue) in addition to the usual commercial suspects (Canonical, Red Hat, SUSE).
The only real sticking point with popular gaming distro support appears to be Steam devices / SteamOS, which the phrase "to the maximum extent technically possible" suggests might be problematic for reasons other than including a signing key.
This seems like it could be a potential problem in getting game developers whose sole interest in supporting Linux is the Steam Deck to play along with the scheme, or alternatively a potential problem for Valve if there's enough uptake that Linux gamers start considering non-Steam devices, and by extension, storefronts, due to the fact that other devices could support a superset of games, given that neither Steam nor Proton are Steam hardware or SteamOS-specific.