**Session Date/Time:** 23 Jul 2026 10:45

[00:00:06] **Moderator**: And do you wanna run more cycling on the Yeah. Second. Okay. What I'll do is, like, I'll give you the

[00:00:11] **Alexei Starovoitov**: cycling role. Yep.

[00:00:12] **Moderator**: And then you can then publish from there. And you can

[00:00:25] **Chairperson**: Hello, everyone. It's 12:45, so we might as well get started. It's my pleasure to welcome Bill Mulligan, and he is a community builder and maintains Cilium and ebpf.io. He's done a lot of these talks, podcasts, and thought leadership over the years. And he's appeared on a wide range of topics mainly around infrastructure software. While at CNCF, he started the Kubernetes community day program. He currently works for Isovalent at Cisco, growing Cilium and EBPF communities, and serves as the chair of the eBPF Foundation governing board. While he's away from the ski board, he does bikepacking, which is a whole different conversation itself. And I don't know how, but next year, he's gonna travel the world bikepacking. And then please help me welcome, Bill. And also one request is if you can have the questions to the end, that would be great. So thank you. And, Bill, off to you.

[00:01:37] **Bill Mulligan**: Cool. Thanks for having me today. So one thing that wasn't mentioned in my bio is that I actually don't have a coding background. I actually did my undergrad in biochemistry. And as I was making the transition from biochemistry into tech, I was learning about all these different acronyms like IETF. And I said, you know, what is that? And eventually find out kind of it's it's working group that's defining how the Internet works, how technology really connects with one another. And so what I'm gonna talk to you today is about another acronym. It's eBPF. And how many people in this room have heard of eBPF? Okay. That's a lot better than than I was making my transition into TAC, and I had no clue what IETF was, but here we are. So, hopefully, I can tell you a little bit about what the technology is and actually where the community is and where it's gonna go in the next decade. So with that, yeah, I guess everybody was raising their hand because, obviously, eBPF is an RFC with IETF. This is the standardization while the implement or the main implementation is within the Linux kernel. And I think one of the reasons why so many people have heard about eBPF, I'll kinda tie this to another logo that people might recognize. When people see this, you can probably hear the jingle in your head. Right? And as technologists, you know, we actually know the difference between the different architectures. But this was actually consumer branding. Right? This was a sticker that people would have on their laptops, and that's why you would choose the laptop because it had Intel inside. And how many people that bought those laptops with the sticker actually knew the difference between all the different CPU architectures? Probably none of them, but they wanted the laptop with Intel inside. And what I'm gonna kinda argue today and what I hope you'll take away from this presentation is that in the coming decade of technology, what you're gonna want is eBPF inside inside the products, the projects, and the technology that you consume. And as technologists, we'll actually know what that means, and I hope that's what you take away from the presentation today. But on the consumer side, the end users of technology are also gonna want eBPF inside, not just because it's a cool brand, but because it provides actual better outcomes for people today. And so before I kinda dive into what is eBPF, I want you to actually hear from the creators of the technology a little bit about how the technology came about. So, on the tech team, if you can roll the video, that would be great.

[00:04:58] **Thomas Graf**: 2011 was exciting. We were all trying to solve this same problem, which is how do you move packets around in a data center.

[00:05:05] **Chairperson**: SDN, by then, had already become quite mature in terms of standard virtualization.

[00:05:10] **Thomas Graf**: However, there was not really this flexibility of programmability.

[00:05:15] **Alexei Starovoitov**: And at that point, like, something clicked. I figured, well, I will just invent my own instruction set.

[00:05:21] **Thomas Graf**: What Alexei did, it's this crazy idea. We're gonna put a virtual machine in the kernel. He was trying to kill, like, a thousand birds with one stone. It turns out that that concept is much more general than just networking. It actually creates this ability to truly extend the kernel in ways that researchers have been trying to figure out forever. All of a sudden, you can have an idea and you can get that into the hand of an end user running in the kernel within days. This means we can rebuild everything better. What should we rebuild first?

[00:06:00] **Alexei Starovoitov**: For Facebook, we showed BPF running in a data center with a line rate speed, processing 15,000,000 packet per second, where BPF program spends literally, like, fifteen nanosecond to process a packet. Then people realize that, yes, BPF is truly fast.

[00:06:16] **Thomas Graf**: At that point, we could see that it was exploding.

[00:06:20] **Moderator**: It's grown from a big project to a really big project.

[00:06:24] **Thomas Graf**: It's not an evolution. It's a revolution. This is gonna not only change what we were working on right now, but it will also change the industry forever.

[00:06:41] **Bill Mulligan**: So that's the creators of the technology. A little bit about why they created eBPF a little over a decade ago. But what actually is eBPF? I mean, everybody in this room already knows it, so maybe I could skip this part, but I'll just walk through it again. So the trailer to the documentary hinted about this a little bit. Like, the real problem that eBPF was invented to solve is this kernel space user space paradox. And in the kernel, we have kind of, like, full system visibility, but the Linux kernel is a thirty five year old technology now. It's deployed on billions of devices worldwide, and it doesn't move the fastest. If you want to bring something into the kernel and have it actually be deployed to your end user, it might be a five year life cycle. There's not this flexibility of really being able to change things fast. In user space, we have complete programmability. We're able to change things really quickly. That's why most applications are written in user space. But the problem is it doesn't have kind of, like, that access to all of the, like, system resources. There's not the same kind of visibility into the system. And before there were ways to modify the kernel through, like, kernel modules, but they're, you know, kind of difficult, unsafe, not stable. This is kind of what brought about the CrowdStrike incident that brought down a lot of the global IT network. So it's maybe not the best way to evolve the kernel. And so the question that eBPF kinda brought about is, can we bring this programmability, this flexibility into the kernel? And, also, how can we use that to benefit, you know, this new evolution of technology? I come from, like, the cloud native world, so we're talking about, like, you know, these really ephemeral environments where things are very changing very quickly. And I think if we're looking at this space of pace of technology right now with the explosion of AI, it's only accelerating. So we need to be able to bring this flexibility and programmability and speed of evolution into the kernel, and that's what eBPF does. What it does is make the kernel programmable. And it's not only that because, obviously, the kernel is a critical part of our system. It's doing it in a way that's both secure and efficient. Kinda like one of the examples that people like to do is what JavaScript is to the browser. EBPF is a Linux kernel. So if you think of before JavaScript, how things are working, you'd have these static web pages. You could read information, but there was no way to kind of, like, interact with them. And once JavaScript came along, you were able to have interactive elements. You could click a button, something would change, you could draw new information, it responded to user input. And this is what eBPF is doing in the kernel. It's able to take user input and modify the behavior that's happening. It's a programmable system then. And in the words of Linus Torvalds, eBPF is actually really useful, and the real power of it is how it allows people to do specialized code that isn't enabled until it's asked for. This flexibility, this programmability, exactly when you need it. And the way that eBPF does that is it's programs that run on specific events. So you have your little eBPF program. You're gonna insert it into the kernel, and it's gonna run based on event, a user input. Right? So it's not someone clicking on a button on a website, but it's a k system call, a k func, a network input. So all these things are what make eBPF programs run. And there's a couple of key parts that make eBPF different than just, you know, inserting random programs into the kernel. The first thing is since the kernel is a critical system, you crash your kernel. You know? System's kinda done. The key kind of, I would say, idea behind eBPF is the safety. How do we safely modify a running system? And the way that we do that is with the eBPF verifier. And what the verifier does is it checks things like the program will run to completion. It's not gonna crash or otherwise harm the system. It's not gonna access memory out of bounds. Essentially, it guarantees that when you put a program into the kernel, it won't crash the kernel. And so that's the safety component that previous ways to modify the kernel didn't have. Then the next part is really around the performance. Right? You could do all this in user space, but besides the programmability, user space is slower than running things in the kernel. And so what eBPF does is once those programs are verified, it will run it through a JIT compiler and basically run an eBPF program as its as fast as natively compiled kernel code. So you have this safety and performance and flexibility that you didn't have. And then the last part is being able to share information across the user space kernel space boundary. And so you have this really performant memory management between the two things. And so kind of those that is what make eBPF kind of this whole revolution in terms of how we program the Linux kernel. It's the flexibility, it's the performance, and it's the safety. And I think one of the interesting things is it's actually an old technology too, or I guess kind of all the maybe this room has a different definition of of old technology, but eBPF is over 12 years old. And I I think this is important to talk about because as I was saying before, you know, something gets into the kernel, but to get to an LTS release that somebody's actually running in production can take five, six years. And so what makes eBPF specifically interesting in 2026 is that most of the or many of the kernels that you're running now in production are gonna be support some type of eBPFs. You can start to do interesting things with the technology. You know, if we rewind back, let's say, even ten years ago, you know, it was just the bleeding edge kernels that had support for eBPF, and it was only the people running those that could benefit from it. But now since it's been in the kernel for so long, eBPF is deployed on billions of systems worldwide. I mean, I think one of my favorite facts about eBPF is, like, every single Android phone is running it to collect the network statistics. And this is goes back to my original point. You know, was saying eBPF inside. Everyone that has an Android phone in this room is benefiting from eBPF, and they don't even have to realize it. I think that's quite cool. And so I come from the cloud native world. I'm a maintainer of the Cilium project, which does networking in Kubernetes. And this is why I originally kind of transitioned from just Kubernetes to someone that was really excited about eBPF and what it could bring to the cloud native world. If we think about, like, cloud native, we have a bunch of containers running around, and usually there's a container orchestrator like Kubernetes doing that. And the interesting thing is, like, you have all these different containers doing different things, and there's you can either try to instrument all of them or you kind of have a patchwork of visibility and ability to control your system. But the one thing that is interesting is that all of these containers are still running on a kernel. So when those containers wanna do something, like wanna process, make a network call, or read a file, they still need to access the kernel. And so the kernel is aware the kernel is aware of everything that's happening on the host, and so it can see everything that those containers are trying to do. And that means that the eBPF programs can see everything that those containers are trying to do. So even as containers are spinning up and down and because they're very ephemeral, eBPF sees each of the things that they're trying to do without having to do any changes to the code or configuration of your applications. And so even as the space of technology increases, like in the cloud native world or north now towards AI, we're still able to instrument everything that's happening because it's all on the shared kernel that eBPF is instrumenting. So as we think about, like, what's the next evolution, like, everything is still running on a kernel. And eBPF gives us that programmability, that safety, and that performance even as the technology above it changes. So where does that leave us in 2026? I think probably everybody in this room knows that I think the number one topic right now is security incidents, especially with the advent of, like, AI models. I think this is a really great graph from the security@kernel.org mailing list. You can see the number of reports that they have received has increased exponentially. In fact, Linus just changed the policy, he said, you know, there's there's no more embargo. We we can't keep up with the pace of it anymore. Everything is just a bug, and you can assume that if somebody's found it, everyone's found it. Right? And so the big challenge right now in technology is security. And I know, like, I work for Cisco, big networking company, but, actually, I surveillance the company that that you know, the startup that I was working for, actually got acquired not into the data center group, but actually into the security business group. And the reason why the SPG acquired Isovalent is because Cisco saw that eBPF would be so critical to the future of security. And so, you know, one suggestion to in the face of this that came up on the Linux kernel mailing list was, yeah, why don't we just, like, implement a kill switch for everything in the kernel? And so if something bad happens, you can just go turn it off. Right? That's, I would say, the poor man's solution. Right? We should just instrument every single code, all of our applications that we can just turn off turn it all off when bad things are happening. Right? At that point, like, we just shouldn't run any code. We should just say technology is over. The best solution is no code. For all of our careers, obviously, this is not a good solution. And so let me take you to the alternative approach. And this is actually oops. This is actually oh, there's a slide missing in here.

[00:18:26] **Moderator**: Yeah. It's just good. Let's see.

[00:18:28] **Bill Mulligan**: Okay. This is actually something that Cloudflare is doing in production right now. And so the the graph that isn't in here is they were able to go from public disclosure of the coop_fail vulnerability on the April 29 to having a 100% of their servers cached on the May 1. So from zero day until all their servers patched was two days. And when I talk about this with some of our customers, they say, that sounds like sci fi to me, you know, being able to move at this speed. And this is exactly how Cisco is looking at eBPF for security. How can we make things move at the speed of agents? Right? AI is coming in. It's finding zero days. There was just the thing from Hugging Face that they were testing one of the new frontier models. It found a zero date, and it escaped from the testing harness, hacked into Hugging Face, stole all the test results so that it could beat the the this the system. Right? And so if that's what we're faced with, how do we keep up with that? Because it's gonna find things and exploit them before we even know about it. So as people who run critical infrastructure, we need to keep up with the speed of agents if we want to have any hope of securing our infrastructure. And I think the I other idea that we have right now is eBPF is part of the kernel. How do we make it part of the trusted compute platform so it's not just security bolted on afterwards? It's something that we can provide as a baseline in the system. So as your system is deployed, you can know that it's secured. And as new vulnerabilities come out, you can patch those in real time. So you can go from zero day mitigation, hopefully not even in two days, can do them at the same time.

[00:20:36] **Moderator**: So that side is gonna come out now.

[00:20:38] **Bill Mulligan**: Okay. Yeah. So the Go. Go.

[00:20:46] **Moderator**: Go forward. I think it's like a

[00:20:49] **Bill Mulligan**: yeah. Oh, yeah. Okay. So this is the this is the slide from Cloudflare. Right? So they go from public disclosure on the twenty ninth to all their servers patched on the first. Right? That's two days. This is what we want to be able to bring to all of our customers and to the the world in general. Right? Being able to keep up with the speed of security that we need. So how are we actually doing this? So Cisco is coming up with something called LiveProtect, and what we are doing is we're able to deploy mitigations to vulnerabilities until you have the time to patch them. Right? This is kind of like a stop gap measure because we know it's not always the perfect time to update systems. The great thing about eBPF is that it can be deployed atomically into a running system without having to reboot or restart the system. So we don't have to turn it off and turn it back on again. Right? We can deploy these mitigations in real time. So what a workflow could look like is a new zero day is announced, and we're able to design a shield, as we call them, to mitigate it. We can test them, and we can release them. And once they're available, we can monitor what they'd actually do on the system to see if they would, you know, stop something that we actually really want going. And once we are happy with that, we can deploy the patch, and it's auto mitigated until you're able to, you know, kind of upgrade to the next kind of version. And so what this allows you to do is to have, like, these compensating controls that give you more time to defend against the attackers and allows you to keep up with the the pace of AI attacks. And so what we're able to do is reduce the the the the window from when things are announced to when you're protected against them. So that's on the security side. Another interesting thing on the eBPF side is actually decoding. So eBPF was the first subsystem in the Linux kernel that used AI for patch reviews. And so now every single patch submitted to the eBPF subsystem is now reviewed by an AI. And what this helps do is reduce the maintainer workload. The the smallest bandwidth in most open source projects is actually being able to review things. And so if you can have, you know, kind of all of the required, like, style and already as a part of the patch, then it actually speeds up the process of getting things into the kernel. The other main problem that a lot of people have with eBPF is being able to pass the verifier. You know, this is the safety mechanism that makes eBPF so powerful, and it provides a way to make sure we don't crash the system. But it's also then kind of like the guardian or the barrier to be able to get your code into the system. With eBPF, we're able to provide that tight feedback loop for agents that are writing code because we're able to write code. If it gets rejected, we're able to take that and use e v use AI to fix the code so that it's able to actually run on the system. So it also enables us to this is actually how we deploy some of the shields too. Right? You can auto create the patches, make sure that they are able to get past the verifier, and then be deployed into production. So it allows us to go from that vulnerable to patch state a lot faster. And then the the last part is about, like, the verifier is very difficult. And so the verifier logs are, you know, kind of very verbose. And so with with AI, we're able to sort through through all of these and provide better logging to help code. And what Alexei, if you saw him in the video at the beginning, he's kinda one of the two cofounders of eBPF said is with AI now, you won't be fighting the verifier anymore, which if you talk to anybody that's writing eBPF code, that's their biggest struggle. And then the last part around eBPF for AI is around the sandboxing. So it's not just defending against attacks, it's actually helping keep things contained too. So this is a recent academic research paper from Roblox. And what they're doing is, right, eBPF can see anything that's happening on the kernel, on the system, and we're using that to sandbox these systems that can learn and process and act on their own. And what's special about eBPF is it's already on your system. So you can use these Linux primitives without having to change the code or configuration of your application or the sandbox that you have to have a way to really scope what the agents are able to do. So I think all of those are exciting use cases for eBPF in the AI area. And I think what's exciting about eBPF is it helps make keep make the Linux kernel relevant. Right? It's a 35 year old technology. And with eBPF, it's exciting again. You know? It's this programmability, and we're able to make it exciting for people. And it's not only what eBPF can do today, but it's also what it's expanding into tomorrow. So if you're familiar with the Linux kernel, it has the completely completely fair scheduler, and that is the main way to schedule systems. But if you think about a Linux powered device, it's, you know, running on billions of devices. You have everything from real time systems to phones to to data center switches and hardware, and they're all running the same scheduler. Now with eBPF and sched_ext, we're actually able to implement our own schedulers. And so you can customize write a custom scheduler tailored to the actual workload that you're running. So as a joke, somebody wrote a scheduler controlled by sound. So this being Vienna, it was actually controlled by the sound of music, and that's how they scheduled things. I also saw one based on cosmology. So based on your star sign, you could actually schedule things onto the CPU. Obviously, that's not what you wanna run-in production, but it gives you an idea of what's possible. Right? A gaming workload has very different scheduling requirements than a website. Right? And with eBPF, you're able to actually write your own scheduler now. On top of that, there's very, like, heterogeneous workloads. A big use case for eBPF in the beginning was actually at Netflix and being able to do profiling of applications. Right? A very intensive, like, through throughput workload. And as we go into the AI AI area, it's also how do we profile the GPUs to make sure we don't have to spend as much with NVIDIA. You know, it's it's still gonna be a lot. And so with eBPF, you're actually able to instrument the GPUs and figuring out what's actually slowing down your application. Right? EBPF, you can go into the system and pull out information that you couldn't get before. And then since I I do work for Cisco, we do have to talk about networking a little bit. I know I haven't touched on it at all in this presentation yet, but I think this one is actually very exciting for me. So if we think about, like, cloud native containers, we have, let's say, like a virtualization overhead. So you have a bare metal system, but then you add a hypervisor on top, you add a container on top. How can we actually speed things up? And so what one of my colleagues developed with eBPF is actually NetKit. And what NetKit enables you to do is to actually eliminate the overhead of containerization, and you're able to have latency and throughput as high as a bare metal host system. And so, yes, you can have the benefits of virtualization and containerization, but you don't take the performance hit either. Right? I think that's really exciting because you're able to have both the advances of technology. You know? Like, being able to containerize something makes it easier and more repeatable to deploy things, but you don't have to have the ben the the negative sides of the hits to performance and latency. And so I think that's what gets me excited about eBPF. Right? We're able to look at our system, see where the impacts are happening, and we're able to rewrite everything better. Right? And that that's what's really cool for me about eBPF, not just for today, but also for tomorrow across scheduling, GPU profiling, even networking. We're able to rewrite everything better. And then a couple updates from the community. If we're looking at, like, what's kind of coming next, then what's exciting for me? I've talked through some of the use cases, but on the actual technology side that people maybe aren't aware about, but are, like, coming soon. The first one that's really exciting for me is BPF tokens. And what this allows you to do is to do more granular permissions for eBPF programs. And right now, first, eBPF required CAPSYS admin, which is obviously maybe not what you wanna do if we're looking at the principle of least privilege. And then there is CAPPF. BPF tokens take the takes this even further by scoping permissions from a program to exactly what it's gonna need. On the security side, we're also bringing in signing of eBPF programs. So if you're running a system, you don't wanna have a attacker come in, set up their own eBPF programs that are running in the host and be able to hide those from things in user space, for instance. So what you can do is if you think of BPF as part of the trusted QQ platform is you can only run trusted programs. And this is actually something that we're doing with LiveProtect too. So basically, only BPF programs that are coming from, for instance, like your vendor, like Cisco, are able to run on the system. So you know what's running on your system is trusted by you. And then the last part is on the technology side, is kind of the implementation of BPF arenas, and this gives you zero copy memory. So the user space shares the same memory pages as eBPF programs. You're having really fast memory exchanges between kernel space and user space. What's exciting about eBPF two is that it's always advancing. I've talked about these use cases. We're twelve years into the technology, and there's always more too. Part of what I do is I'm the chair of the eBPF Foundation governing board, and something that we're actually evaluating right now is we fund academic research grants to advance the use cases of BPF. So I know I was talking about, like, how you can, with sched_ext, write a new custom scheduler for eBPF, but there's also two new things like being able to write rewrite caching in the in the kernel. And that's a lot of things coming out of the academic research or being able to formally verify the verifier. So not only is it the upstream community in Linux kernel, but we're actually seeing this explosion of interest in the academic community too. And part of that is driven by the eBPF Foundation. So that's kind of on the technology side, but the question is is like, is this actually used? You know? Right? I gave you the example of the Android phone. That's a pretty simple one, but a lot of companies see, you know, the this patching stuff is like sci fi. So where are we actually in implementing eBPF into companies? So if you saw in the video at the beginning, one of the earlier adopters of BPF was Meta. They originally did it for networking. That was their original use case. But now 50% of the servers at Meta run over a 180 BPF programs. And this is everything from networking to profiling. They were able to actually profile one of their applications, make a single character change, and it saved them, like, a whole data center worth of server capacity by profiling their applications with ePF. There's a case study about it on the ePF Foundation website. It's things like security. MITRE uses eBPF a lot for security too. Right? So there's a lot of different use cases for eBPF. I think that's what's exciting. It's you can rewrite so many different parts of the kernel. And at a more normal at a more normal scale, this is also from Seznam. I think this is actually one of my favorite stories about BPF. This is some graphs from their production load balancer, and they were switching from an IPVS based load balancer into one actually, Cilium, like the project I'm a maintainer of. It's layer four XDP base load balancer. And when they switched over the traffic from from IPVS to XDP, they actually thought they broke their production systems because as you can see, the the graph went down so much. So they were able to they were able to have twice as much throughput using 36 times less CPU. Right? So that's how much more efficient it is. It's that's the performance that I was talking about at the beginning. Running into the kernel, have much higher performance too. If you wanna learn more about kind of like how eBPF is changing infrastructure software companies like this, I recommend check checking out this white paper from the eBPF Foundation. You can find it on our website. If you wanna learn more about the companies that are actually like deploying eBPF into production. We recently launched a company landscape so that you can see all of the different companies that are leveraging eBPF in their products or services, and you can also see who's contributing to it. As an open source maintainer, I think one of the most important things for me is, like, how are people actually contributing to the ecosystem? And so what we're doing on this company landscape is highlighting people that are either contributing engineering time or money. So you can see who's actually driving the ecosystem forwards. I think this is really good because it helps you understand who are the people, you know, creating the ecosystem. And I think this is my favorite graph from the company landscape is you can see right here what I was talking about earlier. I think the biggest use case for eBPF is not networking, unfortunately, as much as we like that. It's actually insecurity. Like, the things that you're able to do with BPF, the visibility in the system, the ability to modify or block processes as you find out whether they're malicious or not is a really powerful thing that I think no other technology offers on the same level at this time. EBPF is also like a big space too. This is a list of some of the eBPF acquisitions that you can see so far. And what I think is interesting about this is I kinda see, like, three different waves and how eBPF based companies have been acquired. So the first one wave that we are seeing is kinda like the feature and sensor upgrades. So these were, like, really the observability companies. You know, eBPF was able to provide to pull better metrics from the kernel and provide you better observability into your system. So it's kinda traditional observability vendors trying to upgrade what they were able to see. The second one was really around the com like, the platform and community. So companies that were able to, you know, own a piece of the eBPF landscape and integrate into a larger platform from, like, traditional, like, platform vendors. And the last one that I think we're actually in right now is around kind of, like, this runtime security, AI security. I think this is gonna continue for the next couple years because of how important eBPF will be for security. So if all of this got you at least a little bit excited about eBPF, I'm also gonna give you some resources on where to go next. So the first one, obviously, we have a website. So ebpf.io, there's lots of great resources on where you can go to learn more. We also have it in a bunch of different languages. And if you wanna add a translation, come talk to me afterwards. There's also a bunch of eBPF based labs. These are hands on coding environments. You're like, wow, this looks really fun. How do I write, you know, hello world in eBPF? Go check out some of the labs on ebpf.io. I also have the illustrated children's guide to eBPF. So if your small child that you're going home to at the end of this conference would like to learn about eBPF, I have the resource for you. You can also find a copy of this on the website. And then the last one, if you like the trailer that we saw at the beginning of this talk, there is a full length documentary. I didn't wanna play the whole thing because everybody can go watch it on their own time. It's on YouTube. You can see it. It's probably one of my favorite projects that I have worked on. So with that, the last thing I wanna leave you with today. Hopefully, this talk got you excited about all the possibilities for eBPF in networking, security, profiling, observability. EBPF has so much potential to change what's possible in the Linux kernel and beyond because of the flexibility, the programmability, the safety, and the performance that it offers. And so as you go away, I think what you need to think about is in the future, you're gonna want the projects, the products, and the services that have eBPF inside. And not just because there's a cool jingle, but because of what eBPF enables. It enables us to do what wasn't possible before and create a better world for infrastructure, a safer world for infrastructure, and one that we can program to needs that we have. So thank you. Time for questions.

[00:41:20] **Moderator**: If you have questions, you can get on the Meetecho on-site tool and queue up. Thank you. Jinsha, go ahead.

[00:41:39] **Jinsha**: Hi. I'm Jinsha. Sure. I want I'm I'm seeing both eBPF and the web assemblies. They are both bytecode technology. So I wonder why the kernel chose eBPF and why not just the two locations use the same so it's easier to learn.

[00:41:55] **Moderator**: Did you get the question, or do you want me to repeat it? Can you repeat it? Yeah. So if a paraphrase is, WebAssembly is also in a similar space. Like, why didn't they just use eBPF, and why did they come up with something slightly different?

[00:42:09] **Bill Mulligan**: Yeah. I think this is like a common misconception that, like, WebAssembly and eBPF are doing the same thing. I would actually think of them as, like, quite different. EBPF is, like, something that's running in the kernel where WebAssembly is something that's running in user space. They have different use cases. Right? WebAssembly isn't going to hook into k probes and u probes in the kernel. In fact, there's actually ways for eBPF and WebAssembly to work together. Like, one of the projects that in the in the CNCF is Inspector Gadget and actually use WebAssembly modules to package up and, like, format and ship eBPF programs. So I actually see them working together, but they have different use cases. I wouldn't see that them as one versus the other.

[00:43:00] **Moderator**: Thank you. Julius, go ahead.

[00:43:02] **Julius**: Yeah. Julius, I have a question regarding the XTP Rust bindings. So, like, roughly one year ago, I was programming, like, XCP problems in Rust, and I was really surprised how bad the bindings were. Is it like that almost everything is written in c and everything is relying on the on the the checker that is, like, really cryptic, as you said, with the with the error messages?

[00:43:35] **Bill Mulligan**: Yeah. So different languages have different levels of support. Obviously, like, c has the best because it's, you know, what the kernel's mainly written in. At Cilium, we actually write a lot of our stuff in Go, and we have, like, the e b p f go library that we maintain. I think Rust and, like, Cilium is also, I think, like, ten years old now, and we've been working on the library for that long. So that probably has, like, the second best support. Rust is a little bit newer, especially to eBPF, but there's a library, Aya.

[00:44:09] **Julius**: Yeah. Yeah. Yeah. Was using Aya. Yeah. Mhmm.

[00:44:11] **Bill Mulligan**: Yeah. The the main developers in Berlin and I just had a meetup last month that he was talking about some of the developments are coming. I think the big difference is probably the number of users of different languages. Right? So, like, Meta is putting a lot of improvements into c because that's what they write a lot their stuff in. We're putting a lot of stuff into Go because that's what Cilium is. That's what Tetragon is. That's what a lot of our products are. I would say so far there isn't kind of like a big project or product that's Rust based. So that I think that's why the language is a little bit further behind. I do see this changing in the future though because like Alexei, for instance, is like a super big fan of Rust. I know the folks at Google are also very interested in Rust for the kind of their ability to be able to cut out the eBPF verifier is, like, something that they're looking at. So I I think it has a lot of promise. It's just, like, a little bit further behind just because of, like, historical reasons. But

[00:45:14] **Julius**: Yeah. That was something I expected too, like, that the Rust type system catches a lot of errors before they even go to the verifier, and then I was, like, a little bit stunned. But it's yeah. Okay.

[00:45:25] **Bill Mulligan**: Yeah. So I would I would definitely watch the space. And, like, I was just on the board meeting, like, last week, and I know it's something that, like, Google's looking into because, yeah, one of the big problems is the eBPF verifier. And if we can mitigate some of that with, like, the guarantees that Rust provides, then hopefully, can code faster. Yeah. Paul?

[00:45:48] **Paul**: Yeah. First of all, thanks for all the work that you guys have been doing because it's amazing. I think you have helped us to get to a next level of flexibility. The question that I have was when you add the program to a hook, let's say you have Isovalent, but you have another project

[00:46:07] **Moderator**: Mhmm. That

[00:46:07] **Paul**: basically has its eBPF program to the same hook. Right? So how do you deal with all the conflicts that could arise from that? Is there a has the technology evolved to actually help with that, or or what is the the current state is what I'm asking?

[00:46:24] **Bill Mulligan**: Yeah. That's a very good question. My advice would be don't have two tools to do the same job. That's the easiest way to do it. I mean, if you look at Meta, right, they're running a 180 programs, let's say, on average, and those are probably all hooking into different points because eBPF has so many different use cases. Like, because I think of, like, how the ecosystem developed, like, it was mainly driven by, like, hyperscalers and, like, Isovalent. And for the longest time, we kind of we're lucky where we're like, we're the only eBPF based program. It's either you control the infrastructure or at the time, like, Cilium was, like, the the big projects, and so we didn't have to have to think about this as much. I I think it's, like, becoming a bigger thing in the community because, like, this is definitely, like, something that you wanna do. At this time, there is not really a way to, like, order programs so that you can get into some, like, weird race conditions. But, yeah, I think the easiest thing is, like, don't have two tools doing the same thing. Like, we even have this in Cilium right now because, like so Cilium's providing, like, the networking in a Kubernetes cluster, but people want to be able to insert different types of programs into the data path. And then it's like, does it hook in before Cilium or afterwards? And so it's something that we're dealing with as a project right now too. It's like, how do you do it? And then it's like, if you're modifying the packet, how do you get it back into the Cilium data path too? Think it's like a complicated project that the ecosystem is working to evolve on right now. Yeah.

[00:48:01] **Paul**: Thank you. Yeah.

[00:48:10] **Moderator**: Thanks, Paul. I don't think there's anybody else left in the queue. So if you have questions, please come up and ask. Going once, going twice, going thrice. So thank you both, and thank you very much for coming around and talking to us. And in case you didn't know, there's also an ITF working group for this. So if you actually wanna change the language itself, please come and contribute on the mailing list. And we have this awesome dual program where we do stuff in the ITF and the kernel at the same time. So just come down and talk to us. Thank you. Thanks, Will. That was awesome. Yep.

[00:49:03] **Bill Mulligan**: That was fun.