u/xmull1gan

I've pulled out some of the key charts, but the articles dives deeper into each of them and has more. TL;DR eBPF is growing really fast

https://wangcong.org/2025-02-27-ebpf-trend-analysis.html

eBPF Foundation released their investor due diligence report and there are three key parts that align with what I'm seeing in the market.

First is the idea that kernel-level programmability is the strategic control point for infrastructure software and hardware. From the report "The companies that own that kernel layer and build upward into analytics, policy management, and workflow integration are structurally positioned to displace incumbents who cannot replicate kernel-level access through any amount of engineering effort."

The second is the company evaluation matrix on page 12 where the kernel space logic and sensor depth gives a technical moat while the user space logic creates enterprise workflows. The best companies will combine deep kernel integration with workflows that solve real operational problems.

Finally, so far, there have been three waves of acquisitions from Feature & Sensor Upgrades to Platform & Community Land Grabs to AI & Runtime Security Consolidation. Each wave has brought different outcome multiples. I think the security wave is actually just beginning in the post-Mythos world

eBPF is shifting billions in software and hardware infrastructure spend. eBPF Foundation just released a report that gives a framework on how to evaluate these companies.

The kernel space logic and sensor depth gives a technical moat while the user space logic creates enterprise workflows. Looking at these two together gives you a sense of how competitive the company is in the market.

It also covers the three waves of acquisitions we have seen so far from Feature & Sensor Upgrades to Platform & Community Land Grabs to AI & Runtime Security Consolidation and the exit outcomes for each.

The eBPF Re-Platforming Thesis An Investor’s Due Diligence Guide

Kind of crazy to look at the graph in this blog. CVE drops on 04/29, they develop a patch on 4/30, and deploy it across all of their servers on 05/01. Obviously they have the engineers to write BPF-LSM patches, but I think it points to a future where they can (almost) keep up with vulnerability disclosures.

https://blog.cloudflare.com/copy-fail-linux-vulnerability-mitigation/

Kind of crazy to look at the graph in this blog. CVE drops on 04/29, they develop a patch on 4/30, and deploy it across all of their servers on 05/01. Obviously they have the engineers to write BPF-LSM patches, but I think it points to a future where they can (almost) keep up with vulnerability disclosures.

https://blog.cloudflare.com/copy-fail-linux-vulnerability-mitigation/

Growing up in Wisconsin with the Driftless Region almost out of my backdoor, I was often told it is some of the best cycling in the world. Having been lucky enough to bikepack many places around the globe, I can now confirm those childhood rumors. But trips back to visit friends and family usually left little time to explore beyond what I could get to and return from in a day.

This year the opportunity arose to finally get a multi-day bikepacking trip through the Driftless Region and explore some of the corners I had only heard about. Jumping out of the car in Eau Claire and biking down to Winona, La Crosse, Viroqua, Richland Center, and back to Madison, I finally got to experience all of what makes the area so special. Paved roads with little traffic (thank you dairy industry), churches serving homestead townships, and people that will give you their last dollar (quite literally in one community gas station).

The Driftless Region may feel like the end of the earth to some, but it’s my end of the earth. There is always more to explore, even when it has been waiting in your backyard for your whole life.

Full route is here: https://www.komoot.com/collection/4369864/-wisconsin-driftless-bikepacking

Buzzing Across Space: The Illustrated Children's Guide to eBPF now has a fanfic sequel.

Quentin and I (disclosure I wrote the book and am a maintainers of the project) took the story from Buzzing Across Space and extended it to multiple new planets and characters. Read on to find out how Obee defeats Java the Hut and how Cilium can do the same for the problems in your Kubernetes clusters.

https://isovalent.com/blog/post/children-guide-cilium/

Netbump is a new Rust tool (no AI involved) using Aya to work with EBPF.

It is intended to be used by end-user to limit a group of targets which can be a started program or an already running program, a socket or a cgroup (v2). User can add/delete/update/list his own rules.

netbump is the client, buiding request to be sent over a Unix socket to the server. netbumpd is the server handling client request and some events from internal EBPF programs and netlink connections.

Netbump EBPF programs are used to track targets and to mark network packets. Bandwidth limitation is done by the kernel itself.

The limiting factor for a BPF program is the peak memory usage because the verifier limits us to 512 bytes of stack per BPF program or 256 bytes when combining tail calls and BPF-to-BPF functions. Dylan Reimerink has some tip to reduce stage usage:

1. Removing variables. not always possible, but a 1 byte variable can take up a whole 8 byte stack slot.

2. Shorten variable lifetimes. Use inlined functions or variable scopes to limit the lifetime of a variable. Attempt to order code such that variables can have smaller lifetimes. This promotes stack slot reuse, less variables alive a the same time, smaller peak usage.

3. Utilize non-stack memory. Avoid storing variables which can be derived from the program context. Use map values instead of copying and holding onto individual field values. Use per-CPU map values or global variables to store large values (that are not used as input to branching logic).

4. Split programs into tail calls.

5. Reduce function call depth.

oh yea, and a tool to explore where usage comes from

Hello, I’m sharing a project I’ve been developing for the past few months

It’s a GPU manager that uses the kernel eBPF+LSM to block GPU access, it aims to be an alternative to tools such as the deprecated supergfxctl. These tools handle this by unbinding the pci device or unloading the driver, which typically requires a reboot or a logout, with Cardwire, rebooting is not necessary

How it works: it attaches an eBPF program to the kernel to intercept file operation on GPU node such as /dev/dri/renderD or /dev/dri/card, and returns -ENOENT, applications cannot see or use the GPU

This keeps the GPU in its D3cold power state, without touching the driver or the PCI sysfs

I made it for two main reasons:

• i didn't want to restart/logout every time i wanted to disable/enable the dGPU
• Apps such as Electron apps could wake the dGPU up on launch, which would increase the launch time as the GPU is being awakened

It's still experimental and some apps can still bypass it, feel free to open an issue on github

Here is the repo link: https://github.com/OpenGamingCollective/cardwire

Uses eBPF for secrets injection so your app never has access to them.

Basically instead of having the application itself have access to secrets, it uses a "key" to identify which secret to use (like: "kloak:<uuid>" which then eBPF magic swaps it at the transport layer. So, applications never have access, so they cannot leak what they don't know. Happens all within the kernel.

Uses eBPF for secrets injection so your app never has access to them.

Clever idea! Note: I have not tried this yet, just looks interesting and an interesting approach!

https://github.com/spinningfactory/kloak

Edit: More info so it does not get removed: Basically instead of having the application itself have access to secrets, it uses a "key" to identify which secret to use (like: "kloak:<uuid>" which then eBPF magic swaps it at the transport layer. So, applications never have access, so they cannot leak what they don't know. Happens all within the kernel.

- Dropped NAT setup latency by 100x
- Lowered Geneve tunnel latency from 150ms to 200μs and moved expensive tunnel creation moved off the hot path entirely
- Solved the kernel's RTNL lock to eliminate queuing