WEBVTT 00:00.000 --> 00:14.000 Okay. So, hello everyone. My name is, okay, my name is Babis. It's just simplified for 00:14.000 --> 00:20.920 her alambos. And they will give you a sort of presentation of what we do. But before, let me 00:20.920 --> 00:27.560 introduce about us, what we are, who we are and what we do. We are a young company. We mostly 00:27.560 --> 00:34.360 do research, in virtualization systems. We have quite, and that's also, we'll work as a disclaimer 00:34.360 --> 00:39.240 for today, because we like to see things from the bottom up, not from the top down. So, we 00:39.240 --> 00:44.240 are quite closer to, let's say, the OS. We mostly work in the operating systems and the 00:44.240 --> 00:53.800 care note, in virtualization systems and hardware acceleration. And also, lately, with cloud 00:53.800 --> 01:03.160 and breaking the gap between cloud and IoT and AIDS devices. So, about today, we'll, of 01:03.160 --> 01:06.760 course, we'll talk about the wasm, but they're not going to take a lot of time there, because 01:06.760 --> 01:13.720 I'm pretty sure you mostly know more things than me and wasm. We will look a bit on the environment 01:13.720 --> 01:18.760 from the runtime environment, some kind of security concerns that there might be, especially 01:18.760 --> 01:25.560 for, in the context of cloud and multi-tellante environments. And then we'll see how we can 01:25.560 --> 01:31.640 integrate unicorns with wasm and how we can easily build them and how we can deploy them. 01:31.640 --> 01:40.840 So, I think this summarizes quite the greatness of WebAssembly. We can take almost any code written 01:40.920 --> 01:49.320 in any language, almost. And we can run it ever, almost. If we have a WebAssembly runtime and this 01:49.320 --> 01:58.360 is great, like it has an amazing potential to do that. Portability is not the only great thing 01:58.360 --> 02:07.160 of WebAssembly. We also have very, very fast spon-time. We also have the sandbox execution. And 02:07.240 --> 02:11.880 this kind of things made people in the cloud and in other kind of environments, except 02:11.880 --> 02:17.880 of the browser that WebAssembly was initially introduced to, to be interested about WebAssembly 02:17.880 --> 02:24.600 and going to use it. So, we will focus a bit more in the sandbox perspective of WebAssembly, 02:24.600 --> 02:31.160 because we come from the side of operating system and virtualization and how these things 02:31.560 --> 02:39.240 integrate will. And also one other thing, when we mean a host and guest in our, if I ever say 02:39.240 --> 02:47.880 host and guest, I mean host as a operating system host and guest as the VM guest. So, this is a 02:47.880 --> 02:53.800 pretty, let's say, abstract view of what exactly a runtime would look like in a well example, 02:53.800 --> 03:01.080 what makes WebAssembly very safe. So, we have a separated memory for the interaction, 03:01.080 --> 03:05.080 separated memory for the memory of the program, and we also have a start-based 03:05.080 --> 03:10.440 machine. This kind of things make WebAssembly really safe, because we cannot easily, 03:10.440 --> 03:16.520 no way, the interaction table is mutable. It means we cannot change it. We cannot only play around 03:16.520 --> 03:20.680 with the memory, but we cannot do a lot of things in the interaction. And then we have the function 03:20.680 --> 03:27.960 table for the main direct calls. So, the WebAssembly is a binary instruction format, and we 03:28.600 --> 03:35.160 have to use some further compilation to run in an enema scene. And this is what the VM and the 03:35.160 --> 03:42.840 runtime of WebAssembly does. And the thing here is that also the VM is responsible to enforce 03:42.840 --> 03:46.680 this kind of isolation that I just mentioned. But for example, we are not allowed to write in this 03:46.680 --> 03:54.200 kind of memory, we are not allowed to do some specific things. And on top of that, because initially 03:54.280 --> 03:59.080 WebAssembly was supposed to be just not have any communication with the outside world. We have 03:59.080 --> 04:07.560 the Wasi, which is the interface that the WebAssembly people are trying to create a common 04:07.560 --> 04:12.920 interface, a standard interface, so we can communicate with the outside world. And it's getting a 04:12.920 --> 04:18.600 very nice process to be honest. It's really well done and very well defined and very careful 04:18.760 --> 04:25.320 implementation of how to do that. And as previously said, some people like about integration 04:25.320 --> 04:33.560 of Wasi and stuff. So, another great thing that Wasi does and allows to be more secure with WebAssembly 04:33.560 --> 04:38.600 is a capability-based system, which is very strong. And we have a very fine grain control of what 04:38.600 --> 04:44.280 resources we can give to every module or component and how they integrate together, how they communicate, 04:44.360 --> 04:51.240 and all these kind of things. These are really great, great things. However, WebAssembly is not 04:52.040 --> 04:56.920 kind of solved all the problems out there. And especially, there have been quite a lot of 04:56.920 --> 05:04.760 studies that so about some kind of traditional bugs or attacks that have been in WebAssembly 05:05.400 --> 05:13.000 mostly on the binary perspective. I have a few mentions here. The first link that you see here is a 05:13.960 --> 05:20.200 everything all this new again. It's a very popular paper regarding the binary safety of 05:20.200 --> 05:27.560 WebAssembly modules. And think here is that because of how WebAssembly is constructed and how 05:28.600 --> 05:33.880 we don't have the separation of memory and interaction, someone cannot really take advantage of 05:33.880 --> 05:41.880 these bugs in the same way as they would do it in a normal let's say CPU or somewhere else. So they 05:41.960 --> 05:45.640 can mess up with the memory, they can do a lot of things, they can look all the time around, 05:45.640 --> 05:50.360 but they still need to do more things to get outside of the samples and that's what we care. 05:51.080 --> 05:57.800 However, don't forget that WebAssembly runs on top of a runtime. And the runtime is a piece of software. 05:58.440 --> 06:04.680 I have here some CVs quite strong CVs that have been found in WebAssembly. Unfortunately, 06:04.680 --> 06:13.560 I wasn't able to find any other public CVs and in general, any other bug reports about 06:14.280 --> 06:21.640 another kind of runtime. And there have been also some kind of, there is a lot of fuzzing that 06:21.640 --> 06:27.480 goes on in this kind of runtime and it's great. They really try to test and make it as robust as possible. 06:28.600 --> 06:32.920 But don't forget that it's a gain a piece of software. They will always be bugging, 06:32.920 --> 06:38.120 imagine the Linux runs around for so many years or so many bugs, containers around so many years. 06:38.120 --> 06:43.800 So many bugs, these kind of things are, you know, like, make us a bit uncomfortable when we're running 06:43.800 --> 06:49.640 in a multi-tenant environment. And don't forget user misconfiguration. Like, in containers, 06:49.640 --> 06:54.520 we can really really take a container and really, really shrink in that don't allow to 06:54.520 --> 07:00.200 communicate a lot with the outside world, but still, for example, succumb. Like, we can make 07:00.200 --> 07:07.160 an application with a very strict second filter, but as we go later, this second filter might 07:07.160 --> 07:11.480 not work in another application. This creates frustration to the user and we end up adding 07:11.480 --> 07:18.520 more and more than what we actually need. So, the thing here is that what exactly we can do to 07:18.520 --> 07:25.480 create a, let's say, more layered, more layers of isolation. So, an idea is to use virtual 07:25.480 --> 07:30.360 machines, the traditional way of strong isolation. And the other way is using containers that 07:30.360 --> 07:39.240 have been around, also, with the person comes for its way. So, we take another approach, we 07:39.240 --> 07:44.440 believe that another approach is more viable, and we can do that with the unicaryinal. Unicaryinal 07:44.440 --> 07:51.880 is a very specialized single other space virtual machine that is usually constructed from 07:51.960 --> 07:56.280 library operating systems. So, the idea of incalence is, imagine to have a VM with a container running 07:56.280 --> 08:02.600 inside and of this kind of things. And then you see this kind of orange, maybe, dots. These are 08:02.600 --> 08:06.440 only the things that the application really needs. And that's what incaryinal can do. Like, 08:06.440 --> 08:11.400 I can take only the specific parts of every piece of software that the application needs, 08:11.400 --> 08:17.480 and it can combine it in one binary. Of course, this creates the benefit of very fast but times, 08:17.560 --> 08:24.520 reduced attack surface, truly isolated because of the VM isolation. And, very small foot 08:24.520 --> 08:29.080 bring an overhead. On the drawbacks, it's very, very, very difficult to run applications in 08:29.080 --> 08:34.920 this kind of environments. And, yeah, the integration with existing tools is not that great. 08:36.680 --> 08:43.560 So, on one side, we have the unicaryinals that they can provide the low level setup for us, 08:43.640 --> 08:49.240 for the VM, for us, let's say the operating system. We have the memory management, 08:49.240 --> 08:54.440 but they can provide, we have the I-O, things that they can also provide, and this 08:54.440 --> 09:02.280 strong isolation, and this small overhead. And then we also have a web assembly, which kind of acts 09:03.160 --> 09:09.880 like upper layers, where we can have the process thread, whatever, we can call it the separation 09:09.880 --> 09:15.160 and management. We have a standard application interface that higher level applications can 09:15.160 --> 09:23.880 interact with the other parts of the kernel, and there are also no extreme dependence, 09:23.880 --> 09:30.440 we just need the runtime. So, this sounds really good months, like, as Dan said in the beginning, 09:30.440 --> 09:36.920 like, this could be really good months of having just a well, it was a runtime running on top of 09:37.000 --> 09:43.400 a very, very tiny, tiny unicaryinal. And that's what we wanted to explore. Of course, 09:43.400 --> 09:47.640 we are not the first ones who thought about this. There are quite a lot of other projects that 09:47.640 --> 09:54.840 have already tried and the working on that. Music is a great example for that. It's really, 09:54.840 --> 10:04.360 really, it's a really, really nice work. It's written in ZIG. It tries to be a complete web 10:04.520 --> 10:10.520 assembly unicaryinal. I mean, I thought, I mean, without any other supports, not a generic unicaryinal. 10:11.320 --> 10:17.560 And then we also have unicraft, which is a more generic unicaryinal, and it has 10:19.080 --> 10:25.560 Linux binary compatibility and support for WAMER for all the various WAMER. And all these 10:25.560 --> 10:31.240 videos that has support for WASMER, and then there was another project, a little lately, 10:31.240 --> 10:38.040 a Hermit WASM, which was based on Rusty Hermit, and it had support for WASM. Of course, there are 10:38.040 --> 10:44.360 more other kind of approaches there that they also focus on creating some kind of kernels mostly 10:44.360 --> 10:53.080 for web assembly. And we cheated. So instead, we didn't really create a unicaryinal, but what we thought, 10:53.080 --> 10:58.200 what we did, and also, in the meantime, before we do that, and what we also saw in the 10:58.200 --> 11:03.480 container, it was definitely, that we could take the Linux kernel, and we can shrink it. We can 11:03.480 --> 11:09.240 really, really configure it to make it very, very, very tiny, very, very small. And we can just run it 11:09.240 --> 11:16.520 as the basis for our WASM or runtime. And this allows us to have support for any WASM or time that 11:16.520 --> 11:23.080 exists out there. And we can have a very, very tiny Linux kernel running, just provide the essentials 11:23.080 --> 11:30.760 for the VM set up in the I.O. And that's the one part. The other part is how we integrate 11:30.760 --> 11:36.520 these kind of things with the existing technologies. And we know that WASM has made some kind of work 11:36.520 --> 11:42.120 with tooling, at least that's what some people are saying. And we know that unicaryinals are very far away 11:42.120 --> 11:49.400 from being even better on that. And we know that WASM is already able to be deployed as containers. 11:50.280 --> 11:58.680 So, how can we do that, even adding one more, let's say, but user-friendly, not user-friendly, 11:59.640 --> 12:06.520 stuck. So, we do that with Bunny, which allows us to build WASM unicaryinals with, like containers, 12:07.480 --> 12:18.360 and we also deploy unicaryinals with urnc. So, at first about Bunny, so Bunny is based on 12:18.520 --> 12:24.920 build kit. It's an LLB from the front end. And it tries to, it gives, it gives, it gives an 12:24.920 --> 12:31.800 it would, and it tries to configure and find the perfect match for the libois and the dependencies 12:31.800 --> 12:37.960 of the application. It aims to simplify the process of creating unicaryinals and having more, 12:37.960 --> 12:43.000 let's say, generic way of building different kind of unicaryinals and taking care of any dependencies 12:43.080 --> 12:50.280 that any unicaryinal framework might have. It also aims to provide the very, very close to container 12:50.280 --> 12:56.600 like experience. I also use just a Docker build thing. It can generate various outputs, of course, 12:56.600 --> 13:02.840 and it has a layered building process in order to have a more efficient building queue. 13:03.080 --> 13:16.360 So, as a sort demo, I will come here and I will go to unicraft and here I will show you the 13:16.360 --> 13:22.840 Bunny file. So, this is what we have to define. You simply say the unicraft as the platform 13:22.840 --> 13:28.280 that you want to have the monitor that you want to execute at the top and the application that you want 13:29.240 --> 13:36.360 to run. So, the application here is going to be this hollow world. 13:40.600 --> 13:48.760 I can just start. I can just one more thing and then we can just build it. 13:48.760 --> 14:07.960 Let's name it unicraft. Hello, wasm. Okay, there is no such name. Of course, it's a different name. 14:11.560 --> 14:17.160 Okay, and this will build a unicaryinal. It will just compile. In a different step, it will compile 14:19.000 --> 14:24.840 the hollow world does a wasm module and then it will integrate it inside the unicaryinal. 14:24.840 --> 14:30.680 In a unicaryinal. So, if we want to do the same with the Muse, we can do that here. We will 14:30.680 --> 14:38.520 take the hollow world example again. We will go to the Bunny file. This Bunny file. 14:39.320 --> 14:46.200 And we will just simply define a different framework. The Muse is here and we have Rust as a 14:46.280 --> 14:54.360 language implementation here because we can see here. This is the hollow world. We can also change it a bit. 14:58.520 --> 15:05.000 We can simply do the same thing. I'll change that. I'll also do this one. 15:06.920 --> 15:13.160 And now it will build a Muse unicaryinal. So, we have a different unicaryinal that we build. 15:13.160 --> 15:17.800 But again, it's a different process. We first build a wasm module and then depending on which 15:17.800 --> 15:23.560 unicaryinal we target. We have a different, I will do this working. It will take some time. 15:24.680 --> 15:31.080 So, now we will talk how we can deploy this kind of unicaryinals. So, we do that with 15:31.080 --> 15:37.320 unicaryinals. Unicaryinals. It's a serial compatible runtime written in Go. It's very 15:37.320 --> 15:42.440 extensible. We can easily add support for more guests and more hypervisors. I'd hide the 15:42.440 --> 15:49.080 complex of unicaryinal framework specific command line options and the key differences between 15:49.080 --> 15:54.200 other container and times is that we use VMs. We spawn the application directly inside the VM and 15:54.200 --> 15:59.320 we manage the application through the VM. So, we treat the VM as the actual process of the container. 16:00.520 --> 16:05.720 To give a better overview of what exactly this looks like in some kind of isolation boundaries, 16:05.720 --> 16:09.640 at first we have run see that it's just running a typical container in an application 16:09.720 --> 16:15.880 that creates a container. Then we have the case of run wasse that allows us to create to run 16:16.520 --> 16:23.640 a web assembly over the wasm runtime with containers. We can see that it simply creates a container 16:23.640 --> 16:32.200 and spawns a wasm runtime that will run the wasm component. The uransit takes a different approach 16:32.200 --> 16:39.480 and we create an environment for the wasm runtime inside the VM. So, that's the difference 16:39.480 --> 16:48.360 that happens in uransit. So, to have integration with Kubernetes, we use a testing mirroring for 16:49.240 --> 16:56.760 having access to the network from the unicaryinal from the VM and we also have, for storage, we can 16:56.760 --> 17:02.840 have anything that the unicaryinal can support. Regarding the side components, one key difference is that 17:02.840 --> 17:09.880 we don't treat them as part of the, let's say, of the untrusted part. Sidecare containers are the ones 17:09.880 --> 17:18.360 that we, as people in the, that we build the whole system, the whole thing, that's what it's our code, 17:18.360 --> 17:27.160 it's trusted code, it's not user code, we don't have any problem there. So, I can return back to the demo 17:28.040 --> 17:36.520 here. So, we have built a few vign kernels here and I can run them. So, I don't remember how I 17:36.600 --> 17:53.560 was a name, okay. So, this is the first one. I can simply do a Docker run and I will just use here 17:53.560 --> 18:01.480 the, I will just define the uransit as a container runtime. I will just run it, it would be a 18:01.480 --> 18:09.000 unicaraff and look, it also has the hello wasmphosdom thing and that was too fast, it wasn't 18:09.000 --> 18:16.520 really easy to sew anything. We can also do the thing with, if I have time do I have time? 18:17.480 --> 18:31.480 So, I mean, it's okay, I can try to build this server here, let's build it, oops. 18:31.560 --> 18:59.080 Okay, and let's run it. This is an HTTP, a simple thing. Okay, this going. So, this will take, oh, oh yeah, 18:59.080 --> 19:12.360 I have to give some more memory here. Okay, and here we have the, yeah, that was not really 19:12.360 --> 19:17.480 clever from my side, I don't have one more cell. Let's try and do that again. 19:17.480 --> 19:43.800 Oh, no, what was the command? Okay, so let's copy this command. Let's run here, 19:43.800 --> 19:58.840 okay, and here we can do a Docker PS, we can get the IP of this container, and we can do a 19:58.840 --> 20:12.520 apparel. Yeah, as you can see, it's a different port, and we have the hello word here. 20:13.960 --> 20:20.840 So, that's how it works. I have to say that this work is partially funded from European 20:21.800 --> 20:27.640 projects, and as a summary, we know that wasmons in emerging and promising technology. 20:28.840 --> 20:34.920 We prefer in a multi-tenal environment to have security in depth, and we believe that unique 20:34.920 --> 20:40.920 elements are very nice abstractions on top of, on underneath of wasmons to provide this kind of 20:41.960 --> 20:49.560 secure environment. We created a tool by me to help people create wasmons and we also have the 20:49.560 --> 20:56.040 UronC that is able to deploy this kind of unencarenals. So you can check out the coding kit hub, 20:56.040 --> 21:00.040 and that's all for my side. 21:19.560 --> 21:31.160 Yeah, so what we like, the UronC general is just running inside the VM. So what we do is that we 21:31.160 --> 21:42.520 take the wasmontime, in the case of like five go back in slides. So we have the wasmontime with 21:42.520 --> 21:48.680 wasmontime, or whatever runtime running on top of Linux, that is inside the VM, and then outside 21:49.640 --> 21:54.600 it's we use containers to create this kind of like to have access to the network, to create 21:54.600 --> 21:57.400 all this kind of who these with C groups, and all these kind of things. 22:05.400 --> 22:10.120 No, no, because that's inside the VM. 22:20.520 --> 22:28.360 Yeah, so that's one thing. So mues is a completely written from scratch. It wasmontime, 22:28.360 --> 22:36.600 it's very nice. Check it out. Big shout out to the people there. The Unicraft, the one that we found 22:36.600 --> 22:43.480 the one is quite old right now, it's around four years old, but there is a thing, Unicraft is very 22:44.440 --> 22:50.520 very easy to use, and very like you can run whatever runtime you want at all, it has binary 22:50.520 --> 22:57.720 compatibility. So most of updating the runtime would not be difficult. In our case, 22:58.440 --> 23:06.600 what we sold yesterday is that we could have Linux, a very early version of Linux, 6.18 for 23:06.600 --> 23:12.600 example, 6.8, if I remember and we can run any runtime that you want there. From once time, 23:12.680 --> 23:20.680 wasmades, warmer, wasmere, you name it and it can run on top of it. Of course, if any runtime 23:20.680 --> 23:25.400 needs something specific from the kernel, because we try to strip down the kernel, it doesn't have 23:25.400 --> 23:29.480 a lot of things inside, like we don't have user management, we don't have a lot of things inside. 23:29.480 --> 23:36.600 If a runtime needs this kind of features, then we have to add them in the Linux kernel like 23:42.680 --> 23:53.080 it wasmere, sorry. It's up to the runtime. We don't touch anything in the runtime, 23:53.080 --> 23:57.880 we just spawn the runtime inside the VM, but so we don't. So if the runtime has support for threads, 23:59.160 --> 24:04.520 well, the thing is that the VM by itself, in the context that we use it, it's single threaded, 24:05.480 --> 24:13.320 but we can have some support for, but we can see how S&P and this kind of thing will work in 24:13.320 --> 24:16.600 the VM scenario. 24:23.400 --> 24:29.640 Yeah, so I understand that wasmades will be very, very fast to spawn compared to this kind of 24:29.640 --> 24:37.480 stack, but as we saw yesterday, in typical containers, you had around 600 milliseconds 24:37.480 --> 24:46.200 a good time running a wasm thing. This can take 700 milliseconds. So if you simply deploy a wasm 24:46.200 --> 24:51.560 a thing with just a container, like run wasmere or something like that, this is safer and it can 24:51.560 --> 24:57.400 have almost the same good time. That's one use case. The other use case would be in a different model 24:57.480 --> 25:04.360 that you have this kind of small units running around and waiting for wasm modules to just embed them 25:04.360 --> 25:09.080 and then use this random. Like having, for example, instead of running them everything in the 25:09.080 --> 25:14.680 host, you can just have a pool of units, kernels and just embed stuff there to execute. 25:14.840 --> 25:17.880 Okay, thank you. 25:22.120 --> 25:28.040 What are the main security advantages of running in the new period instead of running the wasmere 25:28.040 --> 25:33.160 and timing of container? Because from what I understand you first have to escape the wasmere 25:33.160 --> 25:38.920 samples, the wasmere and I'm saying those, then you would need to also find exports in a container 25:38.920 --> 25:42.920 So what makes it be a better security? 25:42.920 --> 25:43.920 Yeah. 25:43.920 --> 25:46.920 So the thing here is that Europe in general, 25:46.920 --> 25:50.920 Wasm has much better. 25:50.920 --> 25:52.920 Let's advance more structure sandbox, 25:52.920 --> 25:54.920 compared to other technologies, 25:54.920 --> 25:57.920 like running host on the host. 25:57.920 --> 26:01.920 But the problem in the multi-tenon environment 26:01.920 --> 26:03.920 is that you don't want to share your kernel. 26:03.920 --> 26:05.920 You don't want to share the, 26:05.920 --> 26:09.920 like, if anything happens in any of these kind of case of softwares, 26:09.920 --> 26:12.920 even in the container around time, 26:12.920 --> 26:14.920 either in the, 26:14.920 --> 26:16.920 the Wasm around time, 26:16.920 --> 26:19.920 you don't want to have anyone escape that. 26:19.920 --> 26:22.920 If you escape, you're lost in your machine, you're done. 26:22.920 --> 26:25.920 And this is, like, in public cloud, 26:25.920 --> 26:26.920 it's like, for example, 26:26.920 --> 26:30.920 Azur is created the hyperlight thing, 26:30.920 --> 26:34.920 to just run with Wasm things inside the KVM. 26:35.920 --> 26:37.920 Just because the other public cloud, 26:37.920 --> 26:41.920 they don't want to let anyone escape 26:41.920 --> 26:44.920 and have any access to the host on the thing.