3 ms·
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 d
by anonymousiam 4y 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 4y agoRoot adding eBPF code is not worse than root being able to `insmod` a kernel module.
- egberts1 4y agoWrong, eBPF is way, way worse. At the very least, Linux kernel has signed driver modules.
- mdaverde 4y agoCan you explain why you consider it to be worse? eBPF is also working on signed programs [0] [0] https://lwn.net/Articles/853489/ https://lwn.net/Articles/853489/
- egberts1 4y agoeBPF 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).
- akira2501 4y agoIt 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 4y agoA kernel module could exfiltrate data just as easily though.
- tinus_hn 4y agoThis 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.