Comment by fa3556
19 hours ago
I feel like the only other solution to kernel-level anticheat is some kind of measured and verified system image. The whole chain has to be signed and trusted from the TPM through the kernel to userspace. This way if anyone tampers with the system the game will refuse to launch. I think something like this is already possible with systemd or is at least the long term goal IIRC from Lennart's blog.
Then cheaters will be able to just patch the game startup code so it skips the TPM check. If the game executable were encrypted to the TPM somehow, that might work then though.
IME these systems can be quite fragile in practice. All it takes is one pre-signature exploit (like U-boot parsing ext4 and devicetree before verifying signature) and your whole chain becomes useless.
And while the kernel is quite secure against hacks from userspace, the hardware interfaces are generally more trusted. This is not a problem on smartphones or embedded devices where you can obfuscate everything on a small SoC but the whole PC/x86_64 platform is much more flexible and open. I doubt there is a way to get reliable attestation on current desktop systems (many of which are assembled from independent parts) unless you get complete buy-in from all the manufacturers.
Finally, with AI systems recently increasing in power, perhaps soon the nuclear option of camera + CV + keyboard/mouse will become practical.
> All it takes is one pre-signature exploit
I'm pretty sure GRUB is infamous now for being a source of secure boot bypasses.
I don't know much about TPM APIs, but I think (barring some hardware attestation scheme) a malicious kernel could intercept any game-TPM communication.
The verified bootloader would register the signature of the kernel into the TPM, so a malicious kernel would be noticeable. You could still exploit the kernel, of course.
Even a hacked kernel won't have access to the key material stored inside of the TPM, though, so it wouldn't be able to fake the remote attestation key material used to sign any challenges.
Using TPMs this way requires secure boot which only permits non-exploited, signed kernels to load signed operating system images and signed drivers. Revocation of exploitable software and hardware must be harsh and immediate. That means most dTPMs (which have been proven vulnerable to numerous side-channel attacks) are unusable, as well as some fTPMs from CPUs running old microcode. Several graphics cards cannot be used anymore because their drivers contain unpatched vulnerabilities. Running tools with known-exploitable drivers, such as CPU-Z and some motherboard vendor software, would imply a permanent ban.
This approach can work well for remotely validating the state of devices in a highly secure government programme with strict asset management. For gaming, many hardware and software configurations wouldn't be validatable and you'd lose too much money. Unfortunately, unlike on consoles, hardware and software vendors just don't give a shit about security when there's a risk of mild user inconvenience, so their security features cannot be relied upon.
You can do what some games do and use TPMs as your system's hardware identifier, requiring cheaters to buy whole new CPUs/motherboards every time an account is banned. You can also take into account systems like these but don't rely on them entirely, combining them with kernel-level anticheat like BF6 does (which requires secure boot to be enabled and VBS to be available to launch, though there are already cheaters in that game).