 So please join me in welcoming Nandor to the stage. Yeah. Yeah. Hello, everyone. I'm Nandor Kretcher from Cisco. Basically, I'm an engineering technical leader at Cisco. Whatever name it is, basically I'm a software engineer by heart. I originally entered Cisco from Banzai Cloud. Banzai Cloud was a cloud native Kubernetes-focused startup. I don't know how many of you heard about it. And Cisco acquired it. And now I am part of emerging technologies and innovation of Cisco. And we are trying to invent new things and experiment with new technologies like Wasm. OK. So there is a lot of buzz around Wasm and also EBPF because a lot of networking-related topics can be enhanced by EBPF. A lot of edge-based stuff can be enhanced by Wasm. And so EBPF and WebAssembly, whose VM reams this title says it depends. But Rust is the thing. As in the previous talk for Wasm, Rust is a really good language. So the support is the best for Wasm in Rust. OK. So EBPF. I would love to see an EBPF and Wasm comparison. EBPF is not a general-purpose computation language. It's sophisticated query language for extracting data from network packages and from tracing events inside the kernel. But it's not a general-purpose language. And what is Wasm? It's a bytecode target for general-purpose languages. OK. EBPF and Wasm, exploring the future of service mesh. EBPF and Wasm are the new kids on the block for the service mesh applications to achieve high performance. As I mentioned, both of them can be enhancing the network packet flow, one of them on the network cards, one of them on network filters. If you know Envoy, a lot of Wasm filters are running inside Envoy to enhance service mesh traffic. And that's it. And also evaluations. So there are white papers around the comparison between WebAssembly and EBPF. So basically, there is a lot of buzz around EBPF and Wasm and how they differ, how they can work together. Let's see how they can work together on the kernel level. So since we are trying to call Wasm code from EBPF, we have to be on the kernel level since EBPF runs inside the kernel. OK, let's say what is EBPF closing? How many of you employed or used EBPF before? Yeah? OK. Pretty good amount. So what is EBPF? It's an efficient virtual machine inside the kernel which can JIT compile into native machine code. It's an alternate to kernel modules. Kernel modules are hard to write, hard to maintain. You have to keep compatibility between different kernel versions. You have to do a lot of ceremony, mumbo jumbo to set up a kernel module, shut down a kernel module. You have to prepare for extreme amount of concurrent settings like, am I in an interrupt context? Am I in a normal context? Can I do this locking right now? Or if I lock something, then the whole system will freeze. Yeah, so it's hard to write kernel modules. So EBPF is an alternative method since it supports low level tracing insertion points. So you can write a small C snippet, insert it to a different system tracing event. For example, a file open event, a file close event, a file write event, a network. So everything that is a file, even a socket is a file. So it is also capable to do network packet binary. So you can parse network packets, redirect network packets, drop network packets, easily with EBPF and with XDP, which is a special part of EBPF. OK. It communicates through maps. So EBPF programs can communicate with each other through EBPF maps and also between the user space and the kernel space. So it's a safe extension mechanism since it runs inside the VM. It's very safe to write your code. There is a really small chance that you will crash your virtual machine, your Edge device, or whatever, since all the instructions that you are executing are verified by the EBPF verifier beforehand inserting the EBPF code into the kernel. How the EBPF workflow looks like. So the whole EBPF stuff is down inside the kernel level. You can attach EBPF programs to sockets and network devices. And here are the maps also down on the kernel level. And if some process in the user space are doing system calls like send message receive machines, as I mentioned previously, you can subscribe to those events and do some tracing, check what is going down, and do decisions based on those. And also, user space applications can communicate with EBPF programs through those maps. You can store data inside the maps. You can basically attach each and every CPU a map to it so you don't have concurrency issues. OK, and what is WebAssembly? How many of you have compiled something to WebAssembly? Yeah, a very large amount of people. OK, so this is a WebAssembly heavy audience. So what is WebAssembly? It's an open-start bytecode specification. It's very, very close to EBPF from this first sentence. It's a portable binary format. EBPF is also portable with the query specification. Compile once runs everywhere, but WebAssembly has pretty huge advantages compared to EBPF from the portability point of view. Supported by a huge amount of languages. So basically, not wasm that supports languages, but languages are supporting wasm. So if they have a compiler to compile to wasm, they can target wasm VMs. There are a lot of efficient user space VMs out there with different kind of execution mechanisms. So there are interpreters. Interpreters are slower, but they have their advantages. They are more portable than JIT-compiling VMs since you don't have to move around a lot of JITing code with low-level assembly and stuff like that. You write your interpreter in C or in Rust, and there you have it in every kind of target architecture and platform. There is a lot of the time compilation, so you can compile your wasm modules into binary beforehand before running the actual applications and then executing it with the app of the VM or the runtime. And also, there is JIT. When you load the wasm bytecode into the VM and just in time compile it when you run it, the methods that you need. All this is handled by the runtime, which is sandboxed, so you have all the safety features of a classic virtual machine, memory safety, isolation, stuff like that. And also, there are different kind of mechanisms out there for this. Wasm in the kernel. OK, so let's move down to the kernel level. But this is not something that we have invented or I haven't even invented. There is some already existing literature in this topic. So Ryan Hunter invented wasm JIT. It was a low-level virtual machine that could already JIT. So JIT's bytecode in the kernel space. This repo doesn't really exist anymore, but I'm giving Ryan Hunter the credit because he deleted this repo, but there are a lot of forks out there on GitHub. So if you Google it, you will find it. OK, wasm.io kernel wasm. It's also another virtual machine down in the kernel by wasm. And also, there is a different project which is really, really not a virtual machine down in the kernel, but it's a virtual machine in the user space. So it is helping wasm in Unomu in BPF, wasm in BPF. This is the project name. So it is a framework for doing BPF with the help of wasm code. So you will write your eBPF applications and insert it with the Unomu CLI. And the user space part of the eBPF applications can be written in any kind of languages since the user space part will be compiled to wasm. OK, so our project is called the wasm kernel module. So it's somewhere between a kernel module and eBPF. So as I mentioned, kernel modules are hard to write and maintain, and you have to do a lot of ceremony. eBPF can be inserted into different kind of tracing points and network packet extraction points, but it's not the general purpose. So what could we do? Let's do something that is more easier to write since we have a virtual machine down in the kernel, so you can put wasm into it. And it has more of a feeling of a general purpose language since eBPF is not a general purpose language, but if you expose some methods as a host method to this VM that we just moved down to the kernel, you can do general purpose things inside the VM in a wasm VM. So it's something like a sandbox kernel modules since the VM has the features of a general virtual machine. We are sandbox. As I mentioned, we have memory safety, isolation, and stuff like that. So we can piggyback the content like isolation of wasm. It allows us to reuse the user space code that we have in user space, the logic basically. So you can move down user space logic into the kernel space with the help of the wasm. The whole project is extremely experimental, so please don't employ it in your production virtual machines. And it only targets wasm32 unknown unknown. So there is no wasm support inside or in our project in the kernel level since wasm. What is wasm? It's basically a standard for exposing file opens, socket writes, and stuff like that. So since this is not that straightforward on the kernel level, we are not supporting wasm. How it works. How you can call wasm from eBPF code. So on the kernel level, we have the eBPF VM, which is ready to accept eBPF applications. And we have the kernel module, which has a wasm VM inside it. And we expose module method as a kfunk. kfunk is a feature of the kernel, which is something like exposing a function to eBPF. So kfunks can be exposed to eBPF. And if your function is marked as a kfunk, you have to do some C magic there, then it can be found and called by an eBPF module. OK, how is coming OPA into the picture? OPA is a standard policy language. It's written in regal. There was a previous talk here in one of the sessions about OPA. They are trying to target to the full stack for policy evaluation. So it's basically a really nice security and authority language and framework that you can employ everywhere in your software stack. What can you do with OPA in the kernel? Let's move it down. OPA can be compiled to wasm, since they have a nice CLI called OPA, and support the wasm build target. So it's possible to compile an OPA policy to WebAssembly. What we will do with this, let's move down some decision making into the kernel. It's really in the POC level, so don't expect any product or real world application here. And this will be your real world user space application running inside the kernel. So what we will do, we will write some eBPF. Here we are exposing our OPA evaluation through a K-funk. This is a K-funk, basically. And the K-funk will call back to the virtual machine inside the kernel module, which basically runs our OPA policy, which got compiled into WebAssembly. Heat here with how it goes. So I will move an XDP program into my eBPF VM. I will insert my wasm kernel module into this Linux instance that I'm running on my laptop. I will move the OPA policy that I created and load it into this virtual machine. The virtual machine automatically exposes this evaluation module as a K-funk. So eBPF can call it. And what we will do, sorry, I will show you the demo first. So what we will do, we will do XDP network packet counting if the packets are matching a certain policy that is written in rego. Here is my small rego policy. Can you see it or should I make it bigger? Yeah, it's much better now. It's a really small rego policy. What I am doing, I have a set of allowed protocols called the EPV4 and EPV6. And if the input protocol matches one of these protocols, I'm letting this packet to be counted. Here is my kernel module that is running the virtual machine. And as you can see, I have an OPA evaluation K-funk here. And this is basically the function that will be called by a small XDP application, which is counting the network packets here. So it's external, so it's trying to refer to a K-funk. And have all this protocol parse the packet, create a small input for OPA. And if the OPA evaluation goes through them, we will look up the counters in the map and increase the counters. OK, I'm using Lima. Lima is a really good virtual machine CLI for macOS. And I'm having ARM machines, so I had a lot of problems with virtual box. I can really advise you to use Lima. With Lima, I'm already entering a Linux machine. OK, I'm building my kernel module quickly. It was compiled already. You don't have to wait. I'm inserting this kernel module. It has already my Vazem virtual machine inside it. Let's see how it goes. OK, I have four CPUs in this virtual machine. And since I don't want to mess with concurrency, I'm creating a virtual machine for each and every CPU inside this virtual machine. I mean, inside this Linux instance. Sorry, there are too many virtual machines inside this story. So I'm the Linux virtual machine. OK, so that's it. OK, what should I do now? Let's build my OPA policy. OK, the small regal instance with the protocols previously have you seen. I just compiled it to policy.bosm with the OPA CLI tool. I have some quick make targets to make this happen much more easier. OK, load this OPA policy into the virtual machine. Let's check the logs again. OK, my Vazem module is dumping all the function and globals that is in the loaded module. So I have a lot of OPA built-in functions, evaluation stuff, and stuff like that. So my OPA module is already inside the kernel, inside the Vazem virtual machine. And it's ready to serve eBPF. Now let's call the eBPF insertion. Let's build my eBPF program. Ooh, sorry. I have an issue there. But I can fix. I'm much better. OK. Now my application is already compiled. It's trying to call the famous OPA evaluation method that is already waiting inside the virtual machine. Now let's load the eBPF application. And it will try to count net for packets. Everything is fine. Yeah. OK. Let's see the logs. I have a lot of logs there. Since EPV4 protocol is already folding around my machine, it's communicating with the Wi-Fi. A lot of services are already running inside the virtual machine. So as you can see, the evaluation protocol, the eBPF OPA method is running 1 million times. And with the input protocol, this is the idea of the EPV4 protocol. And the result was one. OK. Let's check the eBPF logs. It's running there. So it's classic eBPF log. As you can see, hello, very large amount of package. OK. You are allowed by OPA to enter. So OPA allowed these EPV4 packets to enter and get counted. And that's all. How is it working? So we are running the wasn't three virtual machine. It's a fast WebAssembly interpreter. It's inside the kernel module. It's an extremely portable virtual machine for wasm. As I mentioned, interpreters are very easy to move around. You don't have to mess with a lot of assembly and GIT compiler magic. We modified it to be able to run it in the kernel, since it is a user space virtual machine. And it's capable to run on the edge and stuff like that. But not on the kernel space. So we have to modify it. We maintain a fork. It's well written, easy to extend. It's written in C. It's really easy to use. It's also employed in cryptocurrency-related works. Has was in support, but we don't need it. As I mentioned, we are just targeting wasn't 32 unknown unknown. What we want in the near future? Employ a GIT capable wasn't VM, since from performance perspective, interpreters are not that good. Wasm 3 is really one of the fastest interpreters out there for wasn't, but it's not the fastest. So probably we need to extend it to have a GIT inside it or employ another runtime, which has GIT already built in. Dynamically exposed wasn't methods. So as you see, my OPA evaluation method was written hard-coded there in the C code. So we need to find out some kind of framework to be able to expose methods as wasn't methods as key funks. A lot of security and performance considerations. So this stuff needs a real review from a real Canada developer, which I am not. And probably a ton of more future enhancements. The whole stuff is open source under Cisco open wasn't getting a little check it out. You will find the wasn't the modified wasn't three there as a submodel. We have a CLI also, which loads the kernel models from user space into kernel space. And you can write any kind of issues, questions there. We are happy to receive those. So any questions? Well, Ella? Well first, let's give them a round of applause for this talk. But I certainly think it's incredibly interesting, especially just thinking how there's always a lower level to go. Even pushing this all the way down into the kernel. But yeah, are there any questions from anyone on anything that was discussed here? I certainly have a question, which is what's the easiest way for someone to get involved in the project? What's the easiest way to get in and contribute? As I mentioned, we have the GitHub repo. It was open source at least three days ago. So it's quite fresh. So jump on it, compile it. A lot of instructions are in the readme. Use lima, as I mentioned, if you have a Mac, or otherwise as well. And we also have a Slack instance called etnysysco. And we will create a wasm-related channel there. It will be part of the readme, so I will put it into there. Gotcha. And I actually have another question just as a runtime nerd. So you mentioned that you wanted to go towards Whammer potentially as a potential runtime. But you mentioned some stuff being particularly difficult when you're running in the kernel. With Whammer, was the plan to use something like their ahead of time compiler, so that way it's just kind of a done show? Or why was the reason you were looking at Whammer? Yeah, I think the ahead of time stuff would be much, much better, since it's really hard to create executable code inside the kernel and mark it as a executable memory space. So I think this has some kind of security limitations already. And Whammer is also written in C, so it can be easily moved down to the kernel level. And Whammer return has a nice quality of code, I think. So I really like Whammer. Makes a lot of sense. Any last minute questions from anyone? All right, give it up again for Nando. Thank you, Alex.