Innovative HID-BPF Expected To Land In Linux 6.2

[phoronix]

Phoronix: Innovative HID-BPF Expected To Land In Linux 6.2

Adding to the growing list of changes expected to be sent in during the Linux 6.2 merge window next month is HID-BPF. This is the Red Hat led effort around using eBPF within the HID subsystem for input devices...

https://www.phoronix.com/news/Linux-6.2-HID-BPF-Expected

[tildearrow]

Typo:

mrophing a device into something else and controlling it from user-space,

[stormcrow]

Speaking of weird HID devices, does anyone have recommendations for programmable keypads (not full keyboards with macro keys) that work well with Linux and/or BSD?

[boxie]

Speaking of weird HID devices, does anyone have recommendations for programmable keypads (not full keyboards with macro keys) that work well with Linux and/or BSD?

the stack overflow ctrl+c/v 3 key keyboard is QMK based IIRC - so if you only need 3 keys that's not a bad option

[onlyLinuxLuvUBack]

Speaking of weird HID devices, does anyone have recommendations for programmable keypads (not full keyboards with macro keys) that work well with Linux and/or BSD?

what's wrong with teensy with pins ?

https://www.pjrc.com/store/teensy41_pins.html

[oiaohm]

Speaking of weird HID devices, does anyone have recommendations for programmable keypads (not full keyboards with macro keys) that work well with Linux and/or BSD?

Really https://qmk.fm/ the qmk firmware is used in a huge number of macro supporting keyboards and keypads. Yes some of them integrate joysticks and mice as well. Annoying you will be back to command line to configuration/firmware updating under Linux and BSD but once configured they are sending 100 percent normal USB-HID stuff to the OS.

And its not that hard to make custom keyboard using qmk as base. Yes it annoying that QMK does not have GUI under Linux but its not deal breaker due to the number of options you have.

HID-BPF could find interesting adding very advanced macro functionality to bog standard 10 dollar keyboard.

[JanW]

Disclaimer : I know nothing about kernel drivers or eBPF. Just reading this and wondering : what prevents an attacker from loading an eBPF keylogger to intercept HID data?

I'm sure there are measures in place to prevent this, but is it impossible by design or is it a question of the user being vigilant and knowledgeable about their system?

EDIT: Or may be a third option: If an attacker can install an eBPF program without the user knowing, they are already in a position to implement keylogging by other means, so this does not really add a new attack vector?

[NobodyXu]

Disclaimer : I know nothing about kernel drivers or eBPF. Just reading this and wondering : what prevents an attacker from loading an eBPF keylogger to intercept HID data?

Probably just requiring the process/user to be privileged (running as root) since this is essentially the same as loading a kernel module.

I'm sure there are measures in place to prevent this, but is it impossible by design or is it a question of the user being vigilant and knowledgeable about their system?

It's definitely possible for eBPF to be misused however eBPF is guaranteed to finish within finite times and cannot enter infinite loop (so no CPU hogger) and also cannot have memory related bugs.

Also it doesn't support loop for now and lots of useful kernel API is not exposed in eBPF, so it cannot intercept it and directly send it over network.
To do that, it would have to cooperate with a user space process.

[JanW]

Probably just requiring the process/user to be privileged (running as root) since this is essentially the same as loading a kernel module.

Thanks for the info, I somehow thought eBPF programs could be loaded from user space also for unprivileged users. Guess I was wrong or maybe this doesn't apply to the HID work mentioned here?

[NobodyXu]

Thanks for the info, I somehow thought eBPF programs could be loaded from user space also for unprivileged users. Guess I was wrong or maybe this doesn't apply to the HID work mentioned here?

From what I know, loading any eBPF, no matter what is the use case, requires root unless you enables unprivileged eBPF when building kernel and sysctl knob kernel.unprivileged_bpf_disabled is not set.

Even if eBPF is allowed for unprivileged users, I suppose HID-BPF would still require root as it is a replacement for having in-tree driver for every faulty HID device, so essentially the same role as driver but much smaller and easier to distribute via distro without having to recompile the whole kernel.

It makes sense for it to be restricted to privileged users, unless there's some additional catch I don't know or somehow the dev behind this is brainfucked and allow any user to load HID-BPF.