BPF for HID drivers [LWN.net]

BPF for HID drivers

Posted Sep 27, 2022 9:17 UTC (Tue) by leromarinvit (subscriber, #56850)
In reply to: BPF for HID drivers by tchernobog
Parent article: BPF for HID drivers

I'm pretty sure BPF programs can't arbitrarily send packets. Unlike kernel modules - which they are supposed to replace in this case. So, no more keylogging for you, I guess! ;-)

In any case, I doubt maintainers would accept either a kernel module or a BPF program containing a keylogger. And for manufacturer supplied third party stuff, possibly binary only, BPF programs seem safer than kernel modules to me.

to post comments

BPF for HID drivers

Posted Sep 30, 2022 14:29 UTC (Fri) by harisphnx (subscriber, #139363) [Link] (1 responses)

Doesn't it depend on method they decide to ship per-device fixes? If they decide to ship these standalone like firmware fixes, then dropping a file containing a keylogger to the folder where the fix should be, will only require a good delivery process.

BPF for HID drivers

Posted Sep 30, 2022 15:22 UTC (Fri) by atnot (guest, #124910) [Link]

I feel like getting an overcomplicated keylogger is on the more optimistic side of things that might happen if an attacker manages to drop arbitrary files into a system folder.

BPF for HID drivers

Posted Apr 22, 2024 15:48 UTC (Mon) by hmh (subscriber, #3838) [Link]

Hopefully eBPF-HID would be contained to not be able to access anything that is available to eBPF other than very few, if any, whitelisted functions to manipulate the descriptors and event stream. It certainly should not be able to call into any networking hooks/functions.

But that alone is already dangerous, as manipulating input device event streams can be a way to inject commands into a running system. One can also keylog to memory, and dump the log to a listener process, etc. Both are highly undesirable if done without the local sysadmin's knowledge and approval -- even if there are other ways to do the same.

So, it would be best to restrict eBPF-HID to *signed* "firmware" (eBPF programs), and by that I mean signed by whomever builds the kernel -- like modules can be. Do we have require-signed-eBPF support already?