Comment by marcyb5st

18 hours ago

Great point. As I mentioned there are other attack vectors and you can mitigate them. For mitigating what you are mentioning for instance you don't just run one eBPF program, but you run a cluster of them that watch each other:

(The following was refined by an LLM because I didn't remember the details of when I was pondering this a while back)

All your anti cheats are eBPF programs hooked to the bpf() syscall itself.

Whenever any process tries to call BPF_PROG_DETACH or BPF_LINK_DETACH, your monitors check if the target is one of the anti cheats in your cluster of anti-cheats.

If an unauthorized process (even Root) tries to detach any of your anti-cheat processes, the eBPF program uses bpf_override_return to send an EPERM (Permission Denied) error back to the cheat.

(End LLM part)

Of course, you can always circumvent this by modifying and compiling the kernel so that those syscalls when targeting a specific PID/process name/UID aren't triggered. But this raises the difficulty of cheating a lot as you can't simply download a script, but you need to install and boot a custom kernel.

So this would solve the random user cheating on an online match. Pro users that have enough motivation can and will cheat anyway, but that is true also on windows. Finally at top gaming events there is so much scrutiny as you need to play on stage on vetted PCs that this is a non-issue

It's open source. Somebody will simply publish an AUR package with a custom kernel that is one command away. You're underestimating the capability of motivated nerds to make a good UX when needed :p. This is how we ended up with SteamOS in the first place

But given Linux kernel is monolithic and you can enforce signing of kernel modules too, using TPM to make sure the Kernel isn't tampered with is honestly the way to go.