Red Hat Eyeing Innovative eBPF Uses For Linux's HID Subsystem

[phoronix]

Phoronix: Red Hat Eyeing Innovative eBPF Uses For Linux's HID Subsystem

eBPF for sandboxed programs running in the kernel have shown to be very useful beyond the original BPF origins in the networking subsystem to also be very practical for other security, tracing, and other general use-cases for an in-kernel JIT virtual machine. Red Hat has sent out initial patches extending eBPF for making use of it within the HID subsystem for input devices...

https://www.phoronix.com/scan.php?page=news_item&px=Linux-eBPF-For-HID

[tildearrow]

I wonder whether eBPF can be used to implement drivers for gaming peripherals as well.

[V1tol]

Thanks Red Hat, now we can be hacked using USB devices.

[RahulSundaram]

Thanks Red Hat, now we can be hacked using USB devices.

Is it possible that experienced kernel developers have a solid understanding of security risks and designed eBPF with that in mind and Red Hat which has an army of kernel developers is a position to also understand this?

[Developer12]

Thanks Red Hat, now we can be hacked using USB devices.

You have no idea at all what you're talking about.

[Thunderbird]

Thanks Red Hat, now we can be hacked using USB devices.

Rather the opposite. Thanks Google for implementing and pushing for crazy new web standards like WebHID to allow Chrome to essentially directly talk to your devices using hidraw.

The new eBPF work can act as a firewall to prevent bad requests. HID is abused left and right for various purposes including firmware updates for input devices. So websites can brick your devices. Thanks Google.

[Quackdoc]

External quirk support? or external driver support? im not familiar with how eBPF works, but in either case, Both are nice, one is just... more nice.

[Danny3]

Talking about eBPF, I wish Red Hat or somebody else would wire the guy working on OpenSnitch firewall to continue to advance it as a full time job.
I can't stand port-based firewalls for their lack of ease of use.
I can't just waste a week with research for configuring a port-based firewall for the 20-50 programs and services that I need.
Application based firewalls like OpenSnitch are great for that!
But I wish that it had at least the incoming connections control.

[oiaohm]

I wonder whether eBPF can be used to implement drivers for gaming peripherals as well.

Already can be if your gaming peripherals are IR based. So the means to have eBPF make a input device has been in Linux since 2018.

https://lore.kernel.org/bpf/CAO-hwJJcepWJaU9Ytuwe_TiuZUGTq_ivKknX8x8Ws=zBFUp0SQ@mail.gmail.com/

Yes the developer notes about joystick issues and other things. So if this does develop forwards we can expect gaming peripherals to be in the mix.

Thanks Red Hat, now we can be hacked using USB devices.

https://www.bleepingcomputer.com/news/security/heres-a-list-of-29-different-types-of-usb-attacks/

No people are being hacked by USB devices now. eBPF with HID could allow updating to prevent some attacks without having to replace the kernel. So you basically have this upside down. Redhat funded developer is looking at this to reduce the attack problem by being able to get input device updates out faster.

External quirk support? or external driver support? im not familiar with how eBPF works, but in either case, Both are nice, one is just... more nice.

https://www.kernel.org/doc/html/latest/bpf/bpf_design_QA.html

That is a good read on eBPF basics. Yes the IR device thing says that eBPF could be used to make driver. eBPF is basic a bytecode that its Just and time with validation turned into native executable code that is run in the kernel space. Yes that validation highly restricts what a eBPF program can get up to. Yes this more restricted than coding normal binary driver.

[Quackdoc]

https://www.kernel.org/doc/html/latest/bpf/bpf_design_QA.html

That is a good read on eBPF basics. Yes the IR device thing says that eBPF could be used to make driver. eBPF is basic a bytecode that its Just and time with validation turned into native executable code that is run in the kernel space. Yes that validation highly restricts what a eBPF program can get up to. Yes this more restricted than coding normal binary driver.

thanks will give this a read when I can