1

The state of eBPF

 7 months ago
source link: https://lwn.net/Articles/960036/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

The state of eBPF

[Posted January 30, 2024 by corbet]
The eBPF Foundation has published a glossy document called The State of eBPF; it seems mostly concerned with how a small number of large companies are using and developing this technology.
No doubt, eBPF will become the new layer in the new cloud native infrastructure stack, impacting the observability, performance, reliability, networking, and security of all applications, supporters say. Platform engineers will cobble together eBPF-powered infrastructure building blocks to create platforms that developers then deploy software on, adding business logic to the mix, and replacing aging Linux kernel internals that cannot keep up with today’s digital and, increasingly, cloud native world.
(Log in to post comments)

The state of eBPF

Posted Jan 30, 2024 16:44 UTC (Tue) by koverstreet (subscriber, #4296) [Link]

Have to admire that kind of breathless prose.

Considering starting a pool on the date people realize that the easier and saner way of safely running untrusted code in the kernel is to just use Rust, and the whole eBPF tulip mania collapses in a puff of smoke...

The state of eBPF

Posted Jan 30, 2024 18:05 UTC (Tue) by dullfire (subscriber, #111432) [Link]

Are you suggesting integrating a rust compiler and assembler into the kernel?

The state of eBPF

Posted Jan 30, 2024 20:09 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

I keep suggesting using WASM instead of eBPF. Then you'll just need to add a Rust->WASM compiler!

The state of eBPF

Posted Jan 30, 2024 20:20 UTC (Tue) by koverstreet (subscriber, #4296) [Link]

No, you'd just execute it like any other usermode helper. We'd need a mode where only a whitelisted set of imports are allowed, and beyond that unsafe is disallowed; then the tricky bit would be getting the scheduler to invoke the panic handler so code can't run forever - Rust has unwinding, but unwinding from the equivalent of a signal handler probably doesn't exist.

The state of eBPF

Posted Jan 30, 2024 20:47 UTC (Tue) by dullfire (subscriber, #111432) [Link]

I don't think I understand.

If it's being relegated to a usermode helper why bother with caring which language it is? To get the same functionality all that is needed is to invent the kernel/userspace IPC mechanism.

The state of eBPF

Posted Jan 30, 2024 20:50 UTC (Tue) by koverstreet (subscriber, #4296) [Link]

The rust compiler would be executed as a usermode helper, and then you'd load the output like any other kernel module.

The state of eBPF

Posted Jan 30, 2024 21:02 UTC (Tue) by dullfire (subscriber, #111432) [Link]

An interesting idea.

Sounds like an interface that could be generalized (from the kernel's PoV) to not care about what it is other than a generic "generate me some trusted binary from this source-y thing".

Though I think any implementation would have minimal system requirements that blow well past most small and/or embedded systems. Having to invoke ld.so, and all the things it's going to want to do, to get your binary code sound like it would complicate the security/reliability arena by orders of magnitude.

The state of eBPF

Posted Jan 30, 2024 21:01 UTC (Tue) by jrtc27 (subscriber, #107748) [Link]

Even if you limit yourself to the safe subset of Rust (which would be a hard requirement in such an environment) the compiler does not check for termination. Besides, the whole point of eBPF is to be more of a bytecode than a high-level language; nothing's stopping you compiling Rust to eBPF; in fact there's even support for bpfel-unknown-none and bpfeb-unknown-none built into rustc.

The state of eBPF

Posted Jan 30, 2024 16:45 UTC (Tue) by djwong (subscriber, #23506) [Link]

"...and replacing aging Linux kernel internals that cannot keep up with today’s digital ... world."

Yeeeeep. It takes a very long time to refactor all those analog XFS functions into digital ones.

The state of eBPF

Posted Jan 30, 2024 17:12 UTC (Tue) by pawel44 (guest, #162008) [Link]

I wonder what their "digital" world runs on? I know it's Linux, but they could at least put more work into their marketing bubble.

The state of eBPF

Posted Jan 30, 2024 17:18 UTC (Tue) by djwong (subscriber, #23506) [Link]

It also turns out it's also hard to fuzz-test continuous functions, which makes writing the functional spec for the digital port a slow process. ;)

The state of eBPF

Posted Jan 30, 2024 20:20 UTC (Tue) by Sesse (subscriber, #53779) [Link]

WTB fuzz tester that can efficiently use derivatives.

The state of eBPF

Posted Jan 30, 2024 17:16 UTC (Tue) by hailfinger (subscriber, #76962) [Link]

At least they're honest about the expected quality: "platform engineers will cobble together eBPF-powered infrastructure building blocks".

The other point in the summary also has very revealing phrasing: "impacting the observability, performance, reliability, networking, and security of all applications". I'd rather have improvement than impact.

The state of eBPF

Posted Jan 30, 2024 19:30 UTC (Tue) by NightMonkey (subscriber, #23051) [Link]

For me, it is both exciting and cringey to see the ecosystem around eBPF get commoditized and SaaSy.

Cisco has been no great friend to F/OSS. And now Isovalent is Cisco. :(


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK