GNU Binutils Begins Landing eBPF Support

[phoronix]

Phoronix: GNU Binutils Begins Landing eBPF Support

The GNU Binutils is finally getting wired up around the Extended BPF (eBPF) as the modern, in-kernel virtual machine that stretches the Berkeley Packet Filter beyond the networking subsystem...

http://www.phoronix.com/scan.php?pag...s-eBPF-Support

[HadrienG]

I'm feeling a bit uneasy about the concept of injecting arbitrary code in the kernel like this.

I know that the eBPF VM is supposed to only allow safe code paths to execute. But VM-based security has been attempted before, and JS / JVM / CLR implementations are still major CVE magnets to this day. Give the security community a compiler with special permissions, and suddenly compiler bugs become interesting ^^'

Then again, as long as injecting BPF is subjected to similar user permissions as loading kernel modules, I suppose it does not fundamentally change the threat model.

[pininety]

I'm feeling a bit uneasy about the concept of injecting arbitrary code in the kernel like this.

I know that the eBPF VM is supposed to only allow safe code paths to execute. But VM-based security has been attempted before, and JS / JVM / CLR implementations are still major CVE magnets to this day. Give the security community a compiler with special permissions, and suddenly compiler bugs become interesting ^^'

Then again, as long as injecting BPF is subjected to similar user permissions as loading kernel modules, I suppose it does not fundamentally change the threat model.

Is it really arbitrary thought? AFAIK it is not turing complete, only allows jumps forward, not backwards and so on. Also these checks are on the kernel side after compiling afaik. What I could see is CPU bugs showing up but compiler bugs? Not so much.

[oiaohm]

I know that the eBPF VM is supposed to only allow safe code paths to execute. But VM-based security has been attempted before, and JS / JVM / CLR implementations are still major CVE magnets to this day. Give the security community a compiler with special permissions, and suddenly compiler bugs become interesting ^^'

This is something you miss. BPF stands for https://en.wikipedia.org/wiki/Berkeley_Packet_Filter yes it first is designed 1992. Almost as old as Linux. Its one of oldest bytecode languages with just in time. With over 2 decades of JIT the CVE count is insanely low for eBPF/BPF.

As pininety said eBPF and is parent BPF are intentionally not turing complete. JS, JVM, CLR.... are turing complete.

Then again, as long as injecting BPF is subjected to similar user permissions as loading kernel modules, I suppose it does not fundamentally change the threat model.

Really there is lower security thread from loading eBPF into kernel vs loading a kernel module. Remember kernel module can do what ever. Where eBPF has to be approved by the in kernel compiler and it has rules that forbid full turing completeness.

eBPF has been used for IR remotes and other things in the Linux kernel for a while. Result has been a massive reduction in security faults due to IR device drivers. The stricter language of eBPF compare to C in fact can reduce security faults.

[HadrienG]

Thanks for these clarifications ! I agree that this all puts some extra weight behind the "BPF is secure" assertion.

[Konstantin A.]

From https://en.wikipedia.org/wiki/Berkeley_Packet_Filter :

"Spectre attack may leverage Linux kernel eBPF JIT compiler to extract data from other kernel processes and allow user-space to read it."

Source: https://googleprojectzero.blogspot.c...with-side.html

[q2dg]

I don't like GAS. Do you know if NASM will follow this path? I've haven't heard anything about this. Thanks

[oiaohm]

From https://en.wikipedia.org/wiki/Berkeley_Packet_Filter :

"Spectre attack may leverage Linux kernel eBPF JIT compiler to extract data from other kernel processes and allow user-space to read it."

Source: https://googleprojectzero.blogspot.c...with-side.html

https://lwn.net/Articles/743265/
Do note that is being addressed kernel side. Did not require changing the bytecode send to kernel. Yes 2 days after work on fixing that appeared.

Of course eBPF is not perfect. Yes this is one of the rare CVEs that happened. CPU hardware bug makes loading kernel modules trouble as well.

Nothing is a 100 percent secure. eBPF is not the worst option.

[RahulSundaram]

From https://en.wikipedia.org/wiki/Berkeley_Packet_Filter :

"Spectre attack may leverage Linux kernel eBPF JIT compiler to extract data from other kernel processes and allow user-space to read it."

Source: https://googleprojectzero.blogspot.c...with-side.html

It is not ebpf or nothing. It is ebpf or kernel modules which can do anything it wants to. Sandboxing or filtering mechanisms are never going to be fully secure but hardening it ahead of time or even fixing any issues known is far more easier than allowing full arbitrary code to run on the kernel.

[jpg44]

I'm feeling a bit uneasy about the concept of injecting arbitrary code in the kernel like this.

I know that the eBPF VM is supposed to only allow safe code paths to execute. But VM-based security has been attempted before, and JS / JVM / CLR implementations are still major CVE magnets to this day. Give the security community a compiler with special permissions, and suddenly compiler bugs become interesting ^^'

Then again, as long as injecting BPF is subjected to similar user permissions as loading kernel modules, I suppose it does not fundamentally change the threat model.

As you said, a root user can already load arbitrary code into the kernel with a kernel module. eBPF introduces no further vulnerability in this regard. Obviously you would only want eBPF code loaded by root not by other users. With that restriction, it does not add increased danger. That being said eBNF could be made to be safer than a kernel module by, a subsystem that uses it I would hope could

eBPF should be in my opinion Turing Complete and the purpose of this is to facilitate being able to implement highly customizable filter mechanisms that can be loaded into the kernel. This can replace existing VMs in the kernel and allow the same VM to be re-used by different subsystems, avoiding duplication, for instance, for use with implementing system call filters, sandboxing, packet filters, and a new backend for iptables and nftables. nftables was going to have its own VM but it does not really make sense for every kernel subsystem that wants to have loadable bytecode to have its own VM when different subsystems can use the same VM infrastructure. The subsystems can configure the VM to their needs, including restricting it to a subset.