TBH, Epic Games EACv2 looks decently well designed, and robust:
Requirements:
Signed Kernel & Kernel Modules
TPM 2.0
Secure Boot
Measured Boot
Input-Output Memory Management Unit (IOMMU)
Kernel Lockdown Integrity Mode
Kexec Disabled
Linux Security Module BPF
systemd service (with hopefully introspectable code) which all it does is checks the above and gives a verified bool (also locks memory regions for Epic games)
Generally it is a good system of locking down any potential paths for code that can work on other processes’ memory.
Signed boot kernel is big problem for most distros (though most people don’t modify their ramdisk, or cmdline, so… probably fine?). Kernel modules would be iffy too, I guess, but presumable even for Arch it would mean .ko from only the official repos. The others are just annoyances.
Would not be a huge amount of pain to set this up for distros. Definitely political momentum is not there and I think will never be. Linux is just a different beast and won’t bend to their corporational “Lock it down!” mentality, better find other ways to combat cheating.
I have yet to see a machine that doesn’t have a tainted kernel (meaning the kernel wasn’t signed, a module wasn’t signed, or both) in the wild. Not even with Ubuntu.
At the same time, requiring TPM 2.0 is the same anti consumer thing Win11 did.
Secure boot is a pain to set up on Linux because it was never meant to be for Linux. It’s a Microsoft invention that Microsoft holds the keys for.
Kexec is useful on a lot of machines for faster reboot times, and disabling it can make them significantly longer.
LSM BPF is scary and sketchy, especially if you’re giving a proprietary blackbox access to it. You should not have random software accessing that.
Actually, I setup secure boot, it isnt that much of a pain. If the docs were more clear, it’s like a nice 4-7 commands, with some reboots (clarity missing in arch wiki)
TBH, Epic Games EACv2 looks decently well designed, and robust:
Requirements:
Generally it is a good system of locking down any potential paths for code that can work on other processes’ memory.
Signed boot kernel is big problem for most distros (though most people don’t modify their ramdisk, or cmdline, so… probably fine?). Kernel modules would be iffy too, I guess, but presumable even for Arch it would mean .ko from only the official repos. The others are just annoyances.
Would not be a huge amount of pain to set this up for distros. Definitely political momentum is not there and I think will never be. Linux is just a different beast and won’t bend to their corporational “Lock it down!” mentality, better find other ways to combat cheating.
I have yet to see a machine that doesn’t have a tainted kernel (meaning the kernel wasn’t signed, a module wasn’t signed, or both) in the wild. Not even with Ubuntu.
At the same time, requiring TPM 2.0 is the same anti consumer thing Win11 did.
Secure boot is a pain to set up on Linux because it was never meant to be for Linux. It’s a Microsoft invention that Microsoft holds the keys for.
Kexec is useful on a lot of machines for faster reboot times, and disabling it can make them significantly longer.
LSM BPF is scary and sketchy, especially if you’re giving a proprietary blackbox access to it. You should not have random software accessing that.
Actually, I setup secure boot, it isnt that much of a pain. If the docs were more clear, it’s like a nice 4-7 commands, with some reboots (clarity missing in arch wiki)