BPF for HID Drivers

https://lwn.net/Articles/909109/

by doener • 4 years ago

41 19 4 years ago

lwn.net

mdaverde4• 4 years ago

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

anonymousiam• 4 years ago

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?

tenebrisalietum• 4 years ago

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

akira2501• 4 years ago

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.

egberts12• 4 years ago

Wrong, eBPF is way, way worse.

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

tinus_hn• 4 years ago

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.

rektide• 4 years ago

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.

mdaverde4• 4 years ago

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

Karliss• 4 years ago

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.

mdaverde4• 4 years ago

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/

daniel5151• 4 years ago

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

chme• 4 years ago

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...

rasz2• 4 years ago

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

namibj2• 4 years ago

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

rasz2• 4 years ago

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

BPF for HID Drivers

Related Stories