[HN Gopher] BPF for HID Drivers
___________________________________________________________________
BPF for HID Drivers
Author : doener
Score : 29 points
Date : 2022-11-16 16:10 UTC (6 hours ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| rektide wrote:
| 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.
| Karliss wrote:
| 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.
| mdaverde wrote:
| 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/
| mdaverde wrote:
| 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
| mdaverde wrote:
| 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 wrote:
| 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 wrote:
| Root adding eBPF code is not worse than root being able to
| `insmod` a kernel module.
| akira2501 wrote:
| 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.
| ecnahc515 wrote:
| A kernel module could exfiltrate data just as easily
| though.
| chme wrote:
| 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...
| daniel5151 wrote:
| 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
___________________________________________________________________
(page generated 2022-11-16 23:02 UTC)