BPF for HID Drivers | Hacker News Reader

BPF for HID Drivers

lwn.net

41 pointsdoener19 comments

Is there a risk that companies could start having closed source code external to the kernel, to support devices, via this?

The monolithic GPL kernel has been a good legal defense, that strongly encourages good behavior. I love these capabilities, but the shift across the continuum towards a somewhat more microkernel-y behavior feels like it has risks.

In the same way out-of-tree kernel modules are enforced to license themselves as GPL if they intend to use a lot (if not most) of the available functionality, eBPF programs fall under the same restrictions.

bpftool[0] allows you to see which programs are currently running in your system, their bpf asm instructions and whether they are GPL-compliant through `bpftool prog show`.

Of course, we still need companies to actually release the source code of their eBPF programs somewhere for the promise to be fulfilled.

[0] https://github.com/libbpf/bpftool

Isn't BPF execution constraints intentionally very tight, 4096 instruction, 512 bytes of stack, limited control flow? I don't think it's currently usable to implement general purpose drivers. Only reason it could work for HID drivers is because a lot of them are doing nothing more than very simple byte substitution either in device descriptor or the actual data reports. So I am not too worried about closed source driver.

eBPF has changed several of these constraints [0]

- Verifier can explore up to 1million insns now instead of 4096

- 512 bytes of stack but with tail chaining you have up to 8k

- Bounded loops have been added. Unbounded loops are prevented by design to not stall the kernel

[0] https://docs.cilium.io/en/v1.12/bpf/

Looks like eBPF support for HID devices will be available in the next kernel release (v6.2)

Source: https://twitter.com/kernellogger/status/1592786651968839683

Linux Plumbers Conf talk: https://www.youtube.com/watch?v=w708RnBEdvE

I would really like to see this implemented for a steam deck or steam controller, where you can change it from keyboard&mouse to game controller, or change button bindings on the fly from user-space while loading different games or applications.

Currently steam is required to change the controller configuration...

Oh hey, that bit about turning a Surface Dial into a mouse is pretty neat! I wonder if I can use eBPF to simplify my user mode surface dial driver...

https://github.com/daniel5151/surface-dial-linux

Doesn't this "solution" just move the problem? I suppose if it's easier to write/update/maintain a set of eBPF rules for quirky HIDs than it is to update the drivers/modules, then this is an improvement.

I wonder how Linus feels about this? Does it introduce a new attack surface for malware injection?

Root adding eBPF code is not worse than root being able to `insmod` a kernel module.

It adds a layer where complex attacks can hide. I'm not so much worried about the 'insmod' as I am about long term data exfiltration being used against me. This certainly does seem to make that a little easier.

A kernel module could exfiltrate data just as easily though.

Wrong, eBPF is way, way worse.

At the very least, Linux kernel has signed driver modules.

Can you explain why you consider it to be worse?

eBPF is also working on signed programs [0]

[0] https://lwn.net/Articles/853489/

eBPF has a way to go before it is secured enough.

One should not use eBPF in production machines (along with many other things that uses the mixed write-execute memory regions such as web browsers with JavaScript enabled).

This solution is like using Javascript instead of C. You can’t write a buffer overflow in Javascript, and you can even sandbox it. That way you can allow code to run that has had less review.

I want HID crypto standard letting me crypto pair with keyboard and ignore other inputs.

You can lock down to the physical path (where it's plugged in) relatively easily already.

Are there ways of software disabling build-in USB hub ports? or do you mean hot glue gun? :)

You can, instead of auto-activating arbitrary-connected keyboards as keyboard-input-devices to applications, only do that when they have a specific physical path. On Linux for example that'd be possible via tuned/changed udev rules.

Reply on news.ycombinator.com