Okay. So, hello everyone. My name is, okay, my name is Babis. It's just simplified for
her alambos. And they will give you a sort of presentation of what we do. But before, let me
introduce about us, what we are, who we are and what we do. We are a young company. We mostly
do research, in virtualization systems. We have quite, and that's also, we'll work as a disclaimer
for today, because we like to see things from the bottom up, not from the top down. So, we
are quite closer to, let's say, the OS. We mostly work in the operating systems and the
care note, in virtualization systems and hardware acceleration. And also, lately, with cloud
and breaking the gap between cloud and IoT and AIDS devices. So, about today, we'll, of
course, we'll talk about the wasm, but they're not going to take a lot of time there, because
I'm pretty sure you mostly know more things than me and wasm. We will look a bit on the environment
from the runtime environment, some kind of security concerns that there might be, especially
for, in the context of cloud and multi-tellante environments. And then we'll see how we can
integrate unicorns with wasm and how we can easily build them and how we can deploy them.
So, I think this summarizes quite the greatness of WebAssembly. We can take almost any code written
in any language, almost. And we can run it ever, almost. If we have a WebAssembly runtime and this
is great, like it has an amazing potential to do that. Portability is not the only great thing
of WebAssembly. We also have very, very fast spon-time. We also have the sandbox execution. And
this kind of things made people in the cloud and in other kind of environments, except
of the browser that WebAssembly was initially introduced to, to be interested about WebAssembly
and going to use it. So, we will focus a bit more in the sandbox perspective of WebAssembly,
because we come from the side of operating system and virtualization and how these things
integrate will. And also one other thing, when we mean a host and guest in our, if I ever say
host and guest, I mean host as a operating system host and guest as the VM guest. So, this is a
pretty, let's say, abstract view of what exactly a runtime would look like in a well example,
what makes WebAssembly very safe. So, we have a separated memory for the interaction,
separated memory for the memory of the program, and we also have a start-based
machine. This kind of things make WebAssembly really safe, because we cannot easily,
no way, the interaction table is mutable. It means we cannot change it. We cannot only play around
with the memory, but we cannot do a lot of things in the interaction. And then we have the function
table for the main direct calls. So, the WebAssembly is a binary instruction format, and we
have to use some further compilation to run in an enema scene. And this is what the VM and the
runtime of WebAssembly does. And the thing here is that also the VM is responsible to enforce
this kind of isolation that I just mentioned. But for example, we are not allowed to write in this
kind of memory, we are not allowed to do some specific things. And on top of that, because initially
WebAssembly was supposed to be just not have any communication with the outside world. We have
the Wasi, which is the interface that the WebAssembly people are trying to create a common
interface, a standard interface, so we can communicate with the outside world. And it's getting a
very nice process to be honest. It's really well done and very well defined and very careful
implementation of how to do that. And as previously said, some people like about integration
of Wasi and stuff. So, another great thing that Wasi does and allows to be more secure with WebAssembly
is a capability-based system, which is very strong. And we have a very fine grain control of what
resources we can give to every module or component and how they integrate together, how they communicate,
and all these kind of things. These are really great, great things. However, WebAssembly is not
kind of solved all the problems out there. And especially, there have been quite a lot of
studies that so about some kind of traditional bugs or attacks that have been in WebAssembly
mostly on the binary perspective. I have a few mentions here. The first link that you see here is a
everything all this new again. It's a very popular paper regarding the binary safety of
WebAssembly modules. And think here is that because of how WebAssembly is constructed and how
we don't have the separation of memory and interaction, someone cannot really take advantage of
these bugs in the same way as they would do it in a normal let's say CPU or somewhere else. So they
can mess up with the memory, they can do a lot of things, they can look all the time around,
but they still need to do more things to get outside of the samples and that's what we care.
However, don't forget that WebAssembly runs on top of a runtime. And the runtime is a piece of software.
I have here some CVs quite strong CVs that have been found in WebAssembly. Unfortunately,
I wasn't able to find any other public CVs and in general, any other bug reports about
another kind of runtime. And there have been also some kind of, there is a lot of fuzzing that
goes on in this kind of runtime and it's great. They really try to test and make it as robust as possible.
But don't forget that it's a gain a piece of software. They will always be bugging,
imagine the Linux runs around for so many years or so many bugs, containers around so many years.
So many bugs, these kind of things are, you know, like, make us a bit uncomfortable when we're running
in a multi-tenant environment. And don't forget user misconfiguration. Like, in containers,
we can really really take a container and really, really shrink in that don't allow to
communicate a lot with the outside world, but still, for example, succumb. Like, we can make
an application with a very strict second filter, but as we go later, this second filter might
not work in another application. This creates frustration to the user and we end up adding
more and more than what we actually need. So, the thing here is that what exactly we can do to
create a, let's say, more layered, more layers of isolation. So, an idea is to use virtual
machines, the traditional way of strong isolation. And the other way is using containers that
have been around, also, with the person comes for its way. So, we take another approach, we
believe that another approach is more viable, and we can do that with the unicaryinal. Unicaryinal
is a very specialized single other space virtual machine that is usually constructed from
library operating systems. So, the idea of incalence is, imagine to have a VM with a container running
inside and of this kind of things. And then you see this kind of orange, maybe, dots. These are
only the things that the application really needs. And that's what incaryinal can do. Like,
I can take only the specific parts of every piece of software that the application needs,
and it can combine it in one binary. Of course, this creates the benefit of very fast but times,
reduced attack surface, truly isolated because of the VM isolation. And, very small foot
bring an overhead. On the drawbacks, it's very, very, very difficult to run applications in
this kind of environments. And, yeah, the integration with existing tools is not that great.
So, on one side, we have the unicaryinals that they can provide the low level setup for us,
for the VM, for us, let's say the operating system. We have the memory management,
but they can provide, we have the I-O, things that they can also provide, and this
strong isolation, and this small overhead. And then we also have a web assembly, which kind of acts
like upper layers, where we can have the process thread, whatever, we can call it the separation
and management. We have a standard application interface that higher level applications can
interact with the other parts of the kernel, and there are also no extreme dependence,
we just need the runtime. So, this sounds really good months, like, as Dan said in the beginning,
like, this could be really good months of having just a well, it was a runtime running on top of
a very, very tiny, tiny unicaryinal. And that's what we wanted to explore. Of course,
we are not the first ones who thought about this. There are quite a lot of other projects that
have already tried and the working on that. Music is a great example for that. It's really,
really, it's a really, really nice work. It's written in ZIG. It tries to be a complete web
assembly unicaryinal. I mean, I thought, I mean, without any other supports, not a generic unicaryinal.
And then we also have unicraft, which is a more generic unicaryinal, and it has
Linux binary compatibility and support for WAMER for all the various WAMER. And all these
videos that has support for WASMER, and then there was another project, a little lately,
a Hermit WASM, which was based on Rusty Hermit, and it had support for WASM. Of course, there are
more other kind of approaches there that they also focus on creating some kind of kernels mostly
for web assembly. And we cheated. So instead, we didn't really create a unicaryinal, but what we thought,
what we did, and also, in the meantime, before we do that, and what we also saw in the
container, it was definitely, that we could take the Linux kernel, and we can shrink it. We can
really, really configure it to make it very, very, very tiny, very, very small. And we can just run it
as the basis for our WASM or runtime. And this allows us to have support for any WASM or time that
exists out there. And we can have a very, very tiny Linux kernel running, just provide the essentials
for the VM set up in the I.O. And that's the one part. The other part is how we integrate
these kind of things with the existing technologies. And we know that WASM has made some kind of work
with tooling, at least that's what some people are saying. And we know that unicaryinals are very far away
from being even better on that. And we know that WASM is already able to be deployed as containers.
So, how can we do that, even adding one more, let's say, but user-friendly, not user-friendly,
stuck. So, we do that with Bunny, which allows us to build WASM unicaryinals with, like containers,
and we also deploy unicaryinals with urnc. So, at first about Bunny, so Bunny is based on
build kit. It's an LLB from the front end. And it tries to, it gives, it gives, it gives an
it would, and it tries to configure and find the perfect match for the libois and the dependencies
of the application. It aims to simplify the process of creating unicaryinals and having more,
let's say, generic way of building different kind of unicaryinals and taking care of any dependencies
that any unicaryinal framework might have. It also aims to provide the very, very close to container
like experience. I also use just a Docker build thing. It can generate various outputs, of course,
and it has a layered building process in order to have a more efficient building queue.
So, as a sort demo, I will come here and I will go to unicraft and here I will show you the
Bunny file. So, this is what we have to define. You simply say the unicraft as the platform
that you want to have the monitor that you want to execute at the top and the application that you want
to run. So, the application here is going to be this hollow world.
I can just start. I can just one more thing and then we can just build it.
Let's name it unicraft. Hello, wasm. Okay, there is no such name. Of course, it's a different name.
Okay, and this will build a unicaryinal. It will just compile. In a different step, it will compile
the hollow world does a wasm module and then it will integrate it inside the unicaryinal.
In a unicaryinal. So, if we want to do the same with the Muse, we can do that here. We will
take the hollow world example again. We will go to the Bunny file. This Bunny file.
And we will just simply define a different framework. The Muse is here and we have Rust as a
language implementation here because we can see here. This is the hollow world. We can also change it a bit.
We can simply do the same thing. I'll change that. I'll also do this one.
And now it will build a Muse unicaryinal. So, we have a different unicaryinal that we build.
But again, it's a different process. We first build a wasm module and then depending on which
unicaryinal we target. We have a different, I will do this working. It will take some time.
So, now we will talk how we can deploy this kind of unicaryinals. So, we do that with
unicaryinals. Unicaryinals. It's a serial compatible runtime written in Go. It's very
extensible. We can easily add support for more guests and more hypervisors. I'd hide the
complex of unicaryinal framework specific command line options and the key differences between
other container and times is that we use VMs. We spawn the application directly inside the VM and
we manage the application through the VM. So, we treat the VM as the actual process of the container.
To give a better overview of what exactly this looks like in some kind of isolation boundaries,
at first we have run see that it's just running a typical container in an application
that creates a container. Then we have the case of run wasse that allows us to create to run
a web assembly over the wasm runtime with containers. We can see that it simply creates a container
and spawns a wasm runtime that will run the wasm component. The uransit takes a different approach
and we create an environment for the wasm runtime inside the VM. So, that's the difference
that happens in uransit. So, to have integration with Kubernetes, we use a testing mirroring for
having access to the network from the unicaryinal from the VM and we also have, for storage, we can
have anything that the unicaryinal can support. Regarding the side components, one key difference is that
we don't treat them as part of the, let's say, of the untrusted part. Sidecare containers are the ones
that we, as people in the, that we build the whole system, the whole thing, that's what it's our code,
it's trusted code, it's not user code, we don't have any problem there. So, I can return back to the demo
here. So, we have built a few vign kernels here and I can run them. So, I don't remember how I
was a name, okay. So, this is the first one. I can simply do a Docker run and I will just use here
the, I will just define the uransit as a container runtime. I will just run it, it would be a
unicaraff and look, it also has the hello wasmphosdom thing and that was too fast, it wasn't
really easy to sew anything. We can also do the thing with, if I have time do I have time?
So, I mean, it's okay, I can try to build this server here, let's build it, oops.
Okay, and let's run it. This is an HTTP, a simple thing. Okay, this going. So, this will take, oh, oh yeah,
I have to give some more memory here. Okay, and here we have the, yeah, that was not really
clever from my side, I don't have one more cell. Let's try and do that again.
Oh, no, what was the command? Okay, so let's copy this command. Let's run here,
okay, and here we can do a Docker PS, we can get the IP of this container, and we can do a
apparel. Yeah, as you can see, it's a different port, and we have the hello word here.
So, that's how it works. I have to say that this work is partially funded from European
projects, and as a summary, we know that wasmons in emerging and promising technology.
We prefer in a multi-tenal environment to have security in depth, and we believe that unique
elements are very nice abstractions on top of, on underneath of wasmons to provide this kind of
secure environment. We created a tool by me to help people create wasmons and we also have the
UronC that is able to deploy this kind of unencarenals. So you can check out the coding kit hub,
and that's all for my side.
Yeah, so what we like, the UronC general is just running inside the VM. So what we do is that we
take the wasmontime, in the case of like five go back in slides. So we have the wasmontime with
wasmontime, or whatever runtime running on top of Linux, that is inside the VM, and then outside
it's we use containers to create this kind of like to have access to the network, to create
all this kind of who these with C groups, and all these kind of things.
No, no, because that's inside the VM.
Yeah, so that's one thing. So mues is a completely written from scratch. It wasmontime,
it's very nice. Check it out. Big shout out to the people there. The Unicraft, the one that we found
the one is quite old right now, it's around four years old, but there is a thing, Unicraft is very
very easy to use, and very like you can run whatever runtime you want at all, it has binary
compatibility. So most of updating the runtime would not be difficult. In our case,
what we sold yesterday is that we could have Linux, a very early version of Linux, 6.18 for
example, 6.8, if I remember and we can run any runtime that you want there. From once time,
wasmades, warmer, wasmere, you name it and it can run on top of it. Of course, if any runtime
needs something specific from the kernel, because we try to strip down the kernel, it doesn't have
a lot of things inside, like we don't have user management, we don't have a lot of things inside.
If a runtime needs this kind of features, then we have to add them in the Linux kernel like
it wasmere, sorry. It's up to the runtime. We don't touch anything in the runtime,
we just spawn the runtime inside the VM, but so we don't. So if the runtime has support for threads,
well, the thing is that the VM by itself, in the context that we use it, it's single threaded,
but we can have some support for, but we can see how S&P and this kind of thing will work in
the VM scenario.
Yeah, so I understand that wasmades will be very, very fast to spawn compared to this kind of
stack, but as we saw yesterday, in typical containers, you had around 600 milliseconds
a good time running a wasm thing. This can take 700 milliseconds. So if you simply deploy a wasm
a thing with just a container, like run wasmere or something like that, this is safer and it can
have almost the same good time. That's one use case. The other use case would be in a different model
that you have this kind of small units running around and waiting for wasm modules to just embed them
and then use this random. Like having, for example, instead of running them everything in the
host, you can just have a pool of units, kernels and just embed stuff there to execute.
Okay, thank you.
What are the main security advantages of running in the new period instead of running the wasmere
and timing of container? Because from what I understand you first have to escape the wasmere
samples, the wasmere and I'm saying those, then you would need to also find exports in a container
So what makes it be a better security?
Yeah.
So the thing here is that Europe in general,
Wasm has much better.
Let's advance more structure sandbox,
compared to other technologies,
like running host on the host.
But the problem in the multi-tenon environment
is that you don't want to share your kernel.
You don't want to share the,
like, if anything happens in any of these kind of case of softwares,
even in the container around time,
either in the,
the Wasm around time,
you don't want to have anyone escape that.
If you escape, you're lost in your machine, you're done.
And this is, like, in public cloud,
it's like, for example,
Azur is created the hyperlight thing,
to just run with Wasm things inside the KVM.
Just because the other public cloud,
they don't want to let anyone escape
and have any access to the host on the thing.