Speaker 1: Imagine for a moment, being able to fundamentally alter how
Speaker 1: the very core of your operating system functions, not just
Speaker 1: patching it, but dynamically changing its behavior, you know, without
Speaker 1: rebooting or even recompiling a single line of code.
Speaker 2: Yeah, that sounds pretty wild.
Speaker 1: That almost sounds like a superpower, right, the ability to
Speaker 1: peer into and even reshape your Linux kernel on the fly.
Speaker 1: How is that even possible?
Speaker 2: It's certainly a profound change in how we interact with
Speaker 2: the kernel. And that transformative technology is called eBPF EBPFKA.
Speaker 2: This isn't just some minor upgrade. It's really a revolutionary platform.
Speaker 2: It's fundamentally changing how we build high performance, security, observability
Speaker 2: and networking tools.
Speaker 1: And that revolutionary aspect is what we're here to unpack today.
Speaker 1: Good plan for this deep dive, our mission is to
Speaker 1: explore the power behind eBPF. We'll uncover what it is,
Speaker 1: why it's become so incredibly important, especially you know, in
Speaker 1: recent years with cloud native stuff, and how it actually
Speaker 1: delivers on this promise of un paralleled insight and control.
Speaker 1: All our insights today, by the way, are drawn from
Speaker 1: the excellent book Learning EVPF by Liz.
Speaker 2: Rice A great resource. And you know, even if you
Speaker 2: listening aren't planning to write eBPF code yourself, just understanding
Speaker 2: the fundamentals that gives you a significant advantage. How so, well,
Speaker 2: you're likely to come across eBPF based tooling more and more.
Speaker 2: It's rapidly becoming standard in software infrastructure roles, right, and
Speaker 2: knowing how it works underneath will help you use those
Speaker 2: tools much more effectively. It gives you a real edge.
Speaker 1: Okay, so let's unpack this. To really get eBPF, we
Speaker 1: probably need to start with the Linux kernel itself. How
Speaker 1: would you describe its role for someone maybe not deep
Speaker 1: in OS internals.
Speaker 2: Sure, think of the kernel as the essential software layer,
Speaker 2: sitting directly between your applications and the physical hardware.
Speaker 1: The mediator exactly.
Speaker 2: It's the traffic cop for all interactions. Immediates every request
Speaker 2: from userspace apps through things called system calls or ciscalls,
Speaker 2: like reading files, network stuff files, sending network traffic, even
Speaker 2: just accessing memory. The kernel handles it all. Everything ultimately
Speaker 2: goes through the kernel.
Speaker 1: And because applications rely so heavily on the kernel for
Speaker 1: well everything, being able to observe those interactions must give
Speaker 1: you incredible visibility into what an app is doing.
Speaker 2: That's the key.
Speaker 1: But where did this idea of hooking into the kernel start.
Speaker 1: It had pretty humble origins, didn't they. Oh?
Speaker 2: Absolutely. The BPF and EDPF originally stood for Berkeley Packet Filter,
Speaker 2: started way back.
Speaker 1: In nineteen ninety two, ninety two, Okay.
Speaker 2: Yeah, simply as a way to efficiently filter network packets.
Speaker 2: We're talking in general purpose thirty two bit instructions looked
Speaker 2: a lot like assembly.
Speaker 1: Language, so like for TCP dump or something.
Speaker 2: Precisely, a tiny piece of BPF code could say filter
Speaker 2: out non ippaydance from an Ethernet stream, letting GZP dump
Speaker 2: capture only what was relevant. That efficiency was groundbreaking for
Speaker 2: network analysis back then.
Speaker 1: So the original BPF came into Lenux in ninety seven
Speaker 1: kernel two point one one seventy five for that purpose.
Speaker 1: But I guess the packet filter part of the name
Speaker 1: started to make less sense over time. It did.
Speaker 2: It became much more than just packets.
Speaker 1: What was the turning point? When did it become more versatile?
Speaker 2: Well, the first step beyond just network packets was probably
Speaker 2: SUCCUMBPF and twenty twelve Kernel three point.
Speaker 1: Five sacked and TTF right for ciscall filter exactly.
Speaker 2: It let BPS programs decide whether to allow or deny
Speaker 2: user space apps from making specific system calls, so you
Speaker 2: could restrict what an application could do at the kernel level.
Speaker 1: A security thing.
Speaker 2: Yeah, foundational for containers security later on. But the real
Speaker 2: extended revolution, the birth of eBPF as we know it,
Speaker 2: began in kernel three point one eight. That was twenty fourteen.
Speaker 1: Okay, twenty fourteen. And what changed then? It sounds like
Speaker 1: it was more than just an incremental update.
Speaker 2: Oh, it was a complete overhaul. The instruction set became
Speaker 2: sixty four bit, the interpreter was rewritten, Crucial new features
Speaker 2: were added. That's just This is where we got eBPF
Speaker 2: maps for sharing data between programs and user space.
Speaker 1: Ah okay, that sounds.
Speaker 2: Important, hugely important. Also the VPF system call for userspace interaction,
Speaker 2: and maybe most critically for safety, the eBPF FAIRI fire
Speaker 2: was introduced. We'll definitely need to talk more about that.
Speaker 1: Absolutely. So if adding new kernel features is traditionally you know,
Speaker 1: a massive undertaking months, maybe years to get changes upstream,
Speaker 1: how does eBPF change that? What makes it such a
Speaker 1: game changer today?
Speaker 2: That's the core of its appeal. Really Yeah, eBPF fundamentally
Speaker 2: changes how we can extend the kernel. It allows for
Speaker 2: dynamic kernel functionality, dynamic meaning meaning eBPF programs can be
Speaker 2: loaded and unloaded on demand. This dramatically speeds up adding
Speaker 2: new kernel features. We're talking maybe months, not the years
Speaker 2: it usually takes for upstream kernel changes.
Speaker 1: Wow.
Speaker 2: So you can create and deploy custom kernel functionality incredibly
Speaker 2: quickly without needing you know, the entire Linux world to
Speaker 2: agree and merge it into the main kernel.
Speaker 1: And it's not just about speed of deployment, is it.
Speaker 1: Performance is key.
Speaker 2: Too, absolutely crucial. Once an eBPF program is loaded and
Speaker 2: JIT compiled, I'm compiled right, it runs as native machine
Speaker 2: instructions directly on the CPU. This avoids those costly back
Speaker 2: and forth transitions between kernel space and user space for
Speaker 2: every single event.
Speaker 1: Which makes it incredibly efficient.
Speaker 2: Remarkably efficient. It sounds almost counterintuitive for something running inside
Speaker 2: the kernel, but yeah, it allows EVPF tools to operate
Speaker 2: with minimal overhead.
Speaker 1: That efficiency sounds like a massive win, especially in cloud
Speaker 1: native environments. We often see that sidecar model in kubernettes
Speaker 1: for injecting things like logging tracing.
Speaker 2: Security yep, the sidecar pattern.
Speaker 1: How does EVPF compare. Is it a better alternative?
Speaker 2: In many ways? Yes, The sidecar approach, while useful, often
Speaker 2: means modifying application yamo files, restarting.
Speaker 1: Pods, right operational friction.
Speaker 2: Exactly, and if something goes wrong, the sidecar might not
Speaker 2: even get injected, leaving you blind. Plus, sidecars can potentially
Speaker 2: be bypassed by bad actors. How so well, imagine an
Speaker 2: attacker deploys an uninstrumented app like a crypto minor sidecar
Speaker 2: based security tool which relies on injection, might not even
Speaker 2: see it connecting out to its mining pool.
Speaker 1: Ah I see, and eBPF avoids that Precisely.
Speaker 2: eBPF based tools run on the host and can police
Speaker 2: all traffic, all processes on that machine, including everything inside containers.
Speaker 2: They're much harder to.
Speaker 1: Side steps, so instant complete visibility.
Speaker 2: Pretty much without needing app modifications or restarts. That's a
Speaker 2: game changer for infrastructure teams wanting comprehensive coverage.
Speaker 1: Okay, but these programs are running directly inside the kernel.
Speaker 1: That immediately raises safety concerns. What stops a buggy eBPF
Speaker 1: program from crashing the whole system or reading memory. It shouldn't.
Speaker 2: That's the million dollar question, and the answer is the
Speaker 2: eBPF verifier.
Speaker 1: The kernel's unseen guardian you called it.
Speaker 2: That's a good way to put it. Before an eBPF
Speaker 2: program is ever loaded, the verifier performs an exhaustive static analysis.
Speaker 2: It checks every single possible execution path, every path, every
Speaker 2: path to ensure its safe and won't harm the kernel.
Speaker 2: It's like a super strict bouncer at the kernel's door. Honestly,
Speaker 2: it's a marvel of engineering that makes this whole thing
Speaker 2: possible safely.
Speaker 1: So what kinds of checks does this bouncer perform? It
Speaker 1: must be incredibly rigorous, it really is.
Speaker 2: It tracks the state of each register their types, value
Speaker 2: ranges to prevent invalid operations. It enforces trick memory access,
Speaker 2: making sure programs only touch memory they're allowed to.
Speaker 1: No arbitrary reads are writes none.
Speaker 2: It mandates checks for null pointers before they're reference, preventing
Speaker 2: common crashes. Very importantly, it guarantees programs run to completion.
Speaker 1: How does it do that?
Speaker 2: It rejects programs with loops that it can't prove will terminate.
Speaker 2: There's also a maximum instruction limit, currently a million instructions
Speaker 2: for privileged users a million.
Speaker 1: Okay, that's quite a lot.
Speaker 2: Actually, it gives you scope for complex logic. The verifier
Speaker 2: also checks that helper functions called by the eBPF program
Speaker 2: are allowed for that specific program type, and it even
Speaker 2: checks for GPL compatible licenses if the program uses certain
Speaker 2: restricted helpers.
Speaker 1: That's incredibly thorough. It really builds confidence.
Speaker 2: It has to be. The kernel stability is.
Speaker 1: Paramount, Okay, beyond safety. You mentioned eBPF maps earlier as
Speaker 1: a key differentiator from the original BPF. How did maps
Speaker 1: change the game?
Speaker 2: Maps was a fundamental breakthrough. They are essentially key value stores,
Speaker 2: data structures that act as a bridge, a bridge between
Speaker 2: between the kernel and user space, or even between different
Speaker 2: eBPF programs running in the kernel. They allow communication and state.
Speaker 1: Sharing, which wasn't possible before.
Speaker 2: Right. Classic BPF was stateless, just processing individual packets. Maps
Speaker 2: allow eBPF programs to store state across multiple events or invocations,
Speaker 2: so you can use.
Speaker 1: Them for things like counters sending metrics from the kernel
Speaker 1: up to a userspace monitoring tool exactly.
Speaker 2: That's a common use case, or storing configuration data pushed
Speaker 2: down from user space, or maintaining state across multiple program
Speaker 2: executions like global variables.
Speaker 1: And you mentioned tail calls too. What are those?
Speaker 2: Tail calls allow one eBPF program to effectively jump to
Speaker 2: another eBPF program, replacing itself. It's a way to chain
Speaker 2: programs together.
Speaker 1: Ah okay, so you can build more complex logic flows.
Speaker 2: Precisely, you can chain up to thirty three tail calls currently,
Speaker 2: combined with that million instruction limit per program, it gives
Speaker 2: you a lot of flexibility for sophisticated in kernel logic.
Speaker 1: So maps and tail calls really elevated eBPF from just
Speaker 1: a filter to a proper programmable platform.
Speaker 2: Absolutely, they are key to building that sophisticated eBPF based
Speaker 2: applications we see today.
Speaker 1: Now, if you're thinking about building with eBPF, what are
Speaker 1: the language choices for the kernel side code itself? I
Speaker 1: assume it's pretty low level.
Speaker 2: Yes, For the code running in the kernel. Most eBPF
Speaker 2: programs are written in C or Rust. Why those Because
Speaker 2: they are compilers like Clang LLVM for C can directly
Speaker 2: target the EDPF bytecode instruction set. They give you that
Speaker 2: necessary low level control.
Speaker 1: Makes sense? And what about the user space side? The
Speaker 1: applications that load and manage these kernel programs.
Speaker 2: There you have much more flexibility. User space applications can
Speaker 2: be written in various languages using specific libraries to interact
Speaker 2: with the kernel's eBPF capabilities.
Speaker 1: When eBPF was first taking off, I remember BCC being
Speaker 1: very popular.
Speaker 2: Yes, BCC, the BPF compiler collection. It supports Python, Lua,
Speaker 2: C plus plus C. It was fantastic for learning and experimentation.
Speaker 1: Why was it good for learning?
Speaker 2: It abstracted away a lot of the low level complexity,
Speaker 2: making EDPF accessible to people who weren't necessarily deep kernel hackers.
Speaker 2: You could write Python scripts to load and interact with
Speaker 2: CEBPF code.
Speaker 1: But it had drawbacks for production it did.
Speaker 2: Its main issue was a compile the EDPFC code at
Speaker 2: runtime on the target machine.
Speaker 1: Oh right, so you needed the compiler toolchain LVM CLIANG
Speaker 1: kernel headers on every single server exactly.
Speaker 2: That meant bigger dependencies, potential installation headaches, and noticeable startup
Speaker 2: delays while the code compiled plus higher resource consumption not
Speaker 2: ideal for large scale production deployments.
Speaker 1: So there wasn't need something more robust, more portable for
Speaker 1: enterprise use. That leads us to KEOII, right, compile once,
Speaker 1: run everywhere.
Speaker 2: Yes. Keyoor is the modern approach and a huge leap forward.
Speaker 2: It's really what made eBPF practical for widespread production use.
Speaker 1: How does it achieve that run everywhere magic? It sounds tricky,
Speaker 1: with different kernel versions having slightly different data structures, It
Speaker 1: is clever.
Speaker 2: The key is BTF BPF type format. During compilation, detailed
Speaker 2: type information about the kernel structures the eBPF program uses
Speaker 2: is embedded into the compiled object file itself. Okay, Then
Speaker 2: when you load that program on a target machine, a
Speaker 2: userspace library uses that BTF data to understand the specific
Speaker 2: kernel version running there. It can then automatically adjust memory
Speaker 2: offsets and structure accesses on the fly, so it.
Speaker 1: Adapts the pre compiled code at load time.
Speaker 2: Essentially, yes, it relocates the memory accesses based on the
Speaker 2: actual kernel's layout. This means you can compile your EVPF
Speaker 2: program once on your rig machine and then deploy that
Speaker 2: same binary across a whole fleet running different kernel versions
Speaker 2: within limits.
Speaker 1: Of course, that's a massive operational win. No more compiling
Speaker 1: on every node huge.
Speaker 2: It makes deployment much much simpler.
Speaker 1: And the core c library that enables score is LIBPF.
Speaker 2: That's right. Lip APF is maintained alongside the kernel source tree,
Speaker 2: and it's the reference implementation. It uses auto generated BPF
Speaker 2: skeletons c headers that make loading and managing the eBPF
Speaker 2: programs and maps much cleaner from user space.
Speaker 1: And the benefits over BCC are.
Speaker 2: Lower memory footprint, no runtime compilation dependency, no startup delay,
Speaker 2: and that crucial keore portability. If you're building a serious
Speaker 2: eBPF application today, especially in C, LIBPF is the way
Speaker 2: to go.
Speaker 1: But it's not just C anymore, is it. The ecosystem
Speaker 1: seems to be growing definitely.
Speaker 2: The community has built excellent libraries for other popular languages.
Speaker 2: For Go developers, there's silly MEPF and also libbed PFG,
Speaker 2: which provides Go bindings for lipef.
Speaker 1: And for Rust. Rust seems like a natural for systems programming.
Speaker 2: It does, and there are several options there too, like
Speaker 2: libpfrs red, BPF, and AYA. Each has slightly different approaches
Speaker 2: and trade offs, but they all bring eBPF development to
Speaker 2: Rust programmers, leveraging Rust safety features.
Speaker 1: So lots of options depending on your team's preferred language exactly.
Speaker 2: It's much more accessible now than it was just a
Speaker 2: few years ago.
Speaker 1: Okay, so we have this powerful, safe portable technology, how
Speaker 1: is it actually being used? Let's talk real world applications.
Speaker 1: Observability seems like a prime candidate.
Speaker 2: Absolutely because eBPF programs can attach to so many points ciscolls,
Speaker 2: kernel trace points, kernel functions, eight K probes, even user
Speaker 2: space functions uprobes. They provide incredibly powerful tracing capabilities.
Speaker 1: Deeper than traditional monitoring, much.
Speaker 2: Deeper and often with less overhead. You get unparalleled insight
Speaker 2: into system behavior, network disc io function calls within applications,
Speaker 2: all without modifying or restarting the application itself. It's like
Speaker 2: having x ray vision into your running systems.
Speaker 1: And in networking. You mentioned BPF's origins there, but eBPF
Speaker 1: takes it much further, especially with XDP.
Speaker 2: Yes XDP the express data path. This is really powerful.
Speaker 2: XDP allows eBPF programs to run at the earliest possible
Speaker 2: point in the network stack, right in the driver, even
Speaker 2: before the kernel allocates memory for the packet BSKB.
Speaker 1: So super fast packet process extremely fast.
Speaker 2: This lets you do things like high performance firewalling, dropping
Speaker 2: malicious packets for dedas mitigation, or implementing custom load balancing
Speaker 2: all at line rate in many cases.
Speaker 1: Before the packet even really hits the main kernel networking exactly.
Speaker 2: You can make decisions and potentially drop packets with minimal overhead.
Speaker 2: Some network cards even support offloading XDP programs directly onto
Speaker 2: the NIC hardware itself.
Speaker 1: Wow, hardware offload. That's serious performance it is.
Speaker 2: It allows you to handle enormous amounts of traffic. Think
Speaker 2: about mitigating those packet of death vulnerabilities. XDP can drop
Speaker 2: the malicious packet before it can even cause harm in
Speaker 2: the network stack.
Speaker 1: And this has big implications for Kubernetes networking too, doesn't
Speaker 1: it replacing things like.
Speaker 2: Iptables fundamentally changing it. Yes. Traditional Kubernetes networking often relies
Speaker 2: heavily on iptables for implementing network policies and services and
Speaker 2: contract for connection.
Speaker 1: Tracking, and those have scaling issues, right they do.
Speaker 2: Iptable's rules are processed linearly, so performance degrades is the
Speaker 2: number of rules or services grows. That's o n complexity.
Speaker 2: Contract can also become a bottleneck.
Speaker 1: How does eBPF help.
Speaker 2: eBPF based networking solutions like Cilium replace Iptable's rules and
Speaker 2: contract with EVPF programs and maps they use efficient hash
Speaker 2: maps for lookups.
Speaker 1: Hash maps the lookups are faster.
Speaker 2: Much faster oh one or constant time lookups for network policies,
Speaker 2: service load balancing, and connection tracking regardless of the number
Speaker 2: of rules or connections. This is critical for performance and
Speaker 2: scalability in large Kubernetes clusters.
Speaker 1: That's a significant architectural shift. Now here's a capability that
Speaker 1: sounds almost like magic transparent ryption insight. How can eBPF
Speaker 1: see inside encrypted traffic without keys?
Speaker 2: It's a clever trick. It doesn't actually break the encryption itself. Instead,
Speaker 2: eBPF uses uprobes to hook into userspace SSLTLS libraries like
Speaker 2: open ssl ortls.
Speaker 1: So it attaches to the applications encryption functions precisely.
Speaker 2: It attaches to functions like SSL read and SSL write.
Speaker 2: It can then intercept the data after the library has
Speaker 2: decrypted it for SSL rate or before the library encrypts
Speaker 2: it for SSL right.
Speaker 1: Ah. So it catches the plaintext data inside the application's
Speaker 1: memory just before encryption or just after decryption exactly.
Speaker 2: You get visibility into the clear text data flow without
Speaker 2: needing access to the private keys or certificates. It's incredibly
Speaker 2: powerful for security monitoring, troubleshooting, and even compliance without disrupting
Speaker 2: the encryption itself.
Speaker 1: That's fascinating. Okay, let's shift fully to security. eBPF seems
Speaker 1: poised to move security from just detection to actual prevention.
Speaker 2: That's a key trend for years. Second PPF provided a
Speaker 2: basic layer by filtering ciscoles, which is used heavily in
Speaker 2: Docker and Kubernetes.
Speaker 1: Right limiting what a container can do.
Speaker 2: Yes, and some eBPF tools like inspector gadget can even
Speaker 2: help generate those secom profiles by observing what ciscoles an
Speaker 2: application legitimately uses.
Speaker 1: But generating perfect profiles is hard right capturing all error
Speaker 1: pads and edge cases.
Speaker 2: It's very challenging, and traditional detection often suffers from that
Speaker 2: Tatau problem time of check to time of use the
Speaker 2: race condition. Exactly by the time a separate security agent
Speaker 2: detects a malicious ciscle or file access and decides to act,
Speaker 2: the damage might already be done. The malicious operation might
Speaker 2: have completed.
Speaker 1: So how does eBPF enable prevention closing that time gap?
Speaker 2: This is where a specific eBPF program type comes in
Speaker 2: bpfpot typos. These programs attached to hooks within the Linux
Speaker 2: Security Module Framework.
Speaker 1: LSM, like a Parmer or Cylenux.
Speaker 2: Use exactly the same framework. These eBPF LSM programs can
Speaker 2: perform he checks directly inside the kernel before a sensitive
Speaker 2: operation happens, and crucially, they can return.
Speaker 1: An air code and that error code.
Speaker 2: It prevents the operation from proceeding. The kernel respects the
Speaker 2: error code returned by the LSM hook, stopping the action
Speaker 2: before it even starts. It happens synchronously within the context
Speaker 2: of the original operation.
Speaker 1: So it's in kernel enforcement, not just after the fact detection.
Speaker 2: Precisely, it's a fundamental shift from reactive detection to proactive
Speaker 2: synchronous prevention.
Speaker 1: And tools like Cilium Tetragon build on this.
Speaker 2: They do. Tetragen uses EVPF attaching to k probes and
Speaker 2: trace points, not just LSM hooks, to get rich context
Speaker 2: about security events. It can filter these events efficiently in
Speaker 2: the kernel, reducing overhead, and.
Speaker 1: Can it actively stop threats Yes.
Speaker 2: Based on his policies, it can use helpers like bpfen
Speaker 2: signal to for example, send a sig kill signal to
Speaker 2: terminate a malicious process immediately synchronously when a violation is detected.
Speaker 1: So detect and terminate right there in the kernel context exactly.
Speaker 2: It moves security beyond just observing and alerting to actively
Speaker 2: enforcing policy and preventing harm in real time.
Speaker 1: So to kind of wrap this deep dive up, eBPF
Speaker 1: has really come a long way from just filtering packets.
Speaker 2: An incredible journey.
Speaker 1: It's evolved into this powerful, versatile platform that's genuinely transforming observability, networking,
Speaker 1: and security, giving us unprecedented control and insight right at
Speaker 1: the kernel level.
Speaker 2: It really feels like we're still just scratching the surface
Speaker 2: of what's possible with it. The innovation is happening incredibly fast, and.
Speaker 1: The future looks bright. What's next?
Speaker 2: Well, The eBPF Foundation, which includes major players like Google, Meta, Microsoft, Netflix, isovalent.
Speaker 2: They're working on standardizing.
Speaker 1: eBPF standardization is always good, yeah.
Speaker 2: And even exploring its adoption for Windows, which could potentially
Speaker 2: allow eBPF programs written for Linux to run on Windows too.
Speaker 1: Wow. Cross platform eBPF.
Speaker 2: That's the long term vision for some. It's a rapidly
Speaker 2: evolving field. New kernel features are landing all the time,
Speaker 2: though it's worth remembering there's always a lag before the
Speaker 2: very latest features make it into stable Linux distributions.
Speaker 1: You might be running sure the usual adoption cycle.
Speaker 2: Right, but the pace of development is really impressive.
Speaker 1: It certainly seems like it's going to shape how many
Speaker 1: of our tools work now and in the future. So
Speaker 1: maybe a final thought for our listeners, EDPF seems to
Speaker 1: be shifting from this cutting edge niche thing to a
Speaker 1: fundamental platform for infrastructure tooling.
Speaker 2: Seems that way so well.
Speaker 1: Understanding how this magic works become as essential for developers
Speaker 1: and operators today as say, understanding networking protocols or distributed systems.
Speaker 2: That's a really interesting question to ponder. The tools built
Speaker 2: on EEDPF are definitely becoming ubiquitous, things like Cilium, Falco, Pixie, Tetric.
Speaker 1: Carey'll encounter them more and more.
Speaker 2: You will, and having even that foundational understanding of what's
Speaker 2: happening under the hood how eBPF enables them, it definitely
Speaker 2: gives you a significant advantage in using them effectively, troubleshooting them,
Speaker 2: and just understanding your systems better.
Speaker 1: Well. Hopefully this deep dive gave you a good starting point.
Speaker 1: We encourage you to think about how these eBPF based
Speaker 1: tools might shape your work and maybe explore some of
Speaker 1: the projects or Liz Rice's book if you want to
Speaker 1: go deeper.
Speaker 2: It's a fascinating space to watch.
Speaker 1: Absolutely thanks for joining us for this deep dive.