alt Hacker NewsI always wondered. Isn't exactly what eBPF would allow you to do?
Assuming that cheats work by reading (and modifying) the memory of the game process you can you can attach a kprobe to the sys_ptrace system call. Every time any process uses it, your eBPF program triggers. You can then capture the PID and UID of the requester and compare it against a whitelist (eg only the game engine can mess with the memory of that process). If the requester is unauthorized, the eBPF program can even override the return value to deny access before the kernel finishes the request.
Of course there are other attack vectors (like spoofing PID/process name), but eBPF covers them also.
All of this to say that Linux already has sane primitives to allow that, but that, as long as devs don't prioritize Linux, we won't see this happening.
> your eBPF program triggers
but how does the anti-cheat know that the kernel is not modified such that it disables certain eBPF programs (or misreports cheats/spoofs data etc)?
This is the problem with anti-cheat in general (and the same exists with DRM) - the machine is (supposedly) under the user's total control and therefore, unless your anti-cheat is running at the lowest level, outside of the control of the user's tampering, it is not trustworthy. This leads to TPM requirements and other anti-user measures that are dressed as pro-user in windows.
There's no such thing in linux, which makes it inoperable as one of these anti-cheat platforms imho.