All right, let's get back to it. I'm going to be talking about running continuous in the next VMs.
Thanks so much.
Thanks very much for the intro. Thanks for being here.
I'm Anastasia's Nanos. I'm along with my colleague Babbi.
We're going to talk about sandboxing applications.
The overhead, the isolation boundaries and blah, blah, blah.
So about us, we're a really small company with the research.
We focus on systems software.
Of course, what we're presenting is not entirely our work.
There's a team that works on specific stuff and other stuff.
We also do hardware acceleration.
We do hypervisors.
So the the overview of this presentation is essentially we're going to talk about containers about how we sandbox applications
to execute them.
About our favorite sandbox container and time cata.
And how we try to optimize the execution of applications in the same setting as cata, but another way.
So we all know we are in the in the containers.
We all know about containers. We most probably like using them.
Apparently, it's the default application packaging and deployment framework right now.
You can do a docker build something and docker on something on your laptop.
You can deploy that in the cloud on edge devices.
So it's really, really easy.
Containers offer these these isolation mechanisms.
So we've got the process level isolation thing.
It's based on on mechanisms that the Linux kernel offers.
So we we have got namespaces.
We've got we can limit the usage of resources through C groups.
The main concern from mainly from cloud providers from from
cloud to talent execution environments.
Let's say is that what you you share the Linux kernel.
So you have you have a shared surface that you can attack.
So what cloud providers do in order to offer you service for for containers.
They sandbox these containers using another another isolation layer.
Which could be software like the device or that was that was mentioned in the previous talk.
Or using hardware assisted isolation.
We we focus on that.
And by by hardware assisted isolation.
Think by by hardware assisted isolation.
What we mean is that.
We we put a VM and inside this VM there's a mechanism that can spawn the container that the user asked.
And this this this premise is used in in the cataccontainers.
Runtime which is a sandbox container runtime meaning that you do a doctor run and net city and run whatever.
A micro VM is spawned or a VM full of let's VM is spawned inside this VM.
There's there's a management utility that the catay agent which communicates with the runtime which runs outside the VM.
And it spawns a container the container that you that that the user asked.
However, in in order to do that you need to spawn the VM.
So you have a you haven't an early a cold start overhead let's say.
You have to have a Linux kernel.
You have to have a root of phase for the VM.
There's it's it's a complicated stack.
So digging in a bit a bit more into into cata.
So in when we do a doggarun.
Using the the the the cata containers runtime.
We spawn a VM with a Linux kernel usually it's cata the the cata releases are shipped with a specialized.
With a specialized config a bit of stripped down.
There is a specialized root of phase based on various.
Distros depending on what what the user wants essentially.
So the the VM is spawned.
We establish communication between the runtime and the and the cata agent running as they need process in the VM in the micro VM.
And and the containers are spawned.
So we've got the side car containers in in the Kubernetes setting.
The whole pod is a single VM.
So we've got side car containers and we've got the user code in the in the container all within the same VM.
The isolation boundaries now are between the infrastructure between the the host system and the containers is the is the hardware assisted isolation.
And between the containers inside this pod.
We've got the the standard the content the least containers inside this micro VM.
They said the same we look scanner they say they have a C groups and namespaces and all that stuff.
Now I'm going to give the floor to babies to to talk about what we have been doing to optimize this.
So hello from my side to.
So we we thought we can do the opposite.
So as we see on your left.
We have like the typical VM and inside we have a container on time that spawns and handles and manages our containers.
And we usually have some kind of remote management of the containers that run inside the VM.
But what if we do the opposite what if we just spawn a VM inside a container.
So that's what we wanted to do but of course because we are also familiar with the cata containers.
We couldn't do that with cata but we can do that with the urnc.
urnc is a container on time.
It's a serial compatible in this specialized from managing the unit kernels as containers.
It's very extensible you can add whatever new gifts and whatever new hypervisor you want to support.
And the key differences between urnc and other kind of sandbox container on times are that first of all urnc spawns.
The application inside the VM.
But it treats the VM as the actual process.
So it's kind of like having your process running inside the VM and urnc spawns is the process through the VM and we have one VM per container.
Meaning that all kind of containers will be spawned in a different virtual buzzing all the time.
So to give a better overview of what exactly this looks like.
We have on top the urnc that is usually just a normal container running on the host with using namespace, c groups,
scalability is all this kind of goodies that Linux kernel can provide.
Then we have cata which is still the same thing but inside the VM.
So and then we have urnc which takes quite different approach.
It spawns it is a container on time that it creates the VM inside a sandbox environment inside like a typical container.
So to give a better overview of how this works in Kubernetes for example.
The difference here is that urnc will take here only of the user containers.
So for example when we have cases like in the K native we where we have one more side there container like the cube proxy or the pulse container for the pod.
This is not going to be handled from the urnc.
We don't we treat this kind of containers as our containers.
These are containers that belong to the stack to the system stack system stack.
So the cube proxy doesn't need to have any strong isolated but the code provided by the user.
This needs to be isolated and that's why we contain it inside the virtual machine.
Only the untrusted part of the whole code.
So as I said before we want to do this with we want to spawn a VM and run a container inside it.
And I will try to do that right now.
Sorry for that.
So maybe I will skip that.
Because it's not that exciting maybe next one would be more exciting.
So we'll talk a bit about yeah so this demo was about we were just getting the kernel from kata containers so we're just running on one container on top of it.
But the thing here is that in this demo we're using the default kata kernel which is configured with around 1000 options in the kernel.
It has various kind of support like device, hot plug, ACPI, X tables and all the other kind of things that some of them might be useful.
Some of them might be not useful depending on which kind of scenario which kind of use case you target.
But we know that specialization is the key for having low overhead and footprint better performance and stronger security.
So on one side we know that we have the kata Linux we have this kind of all these features that kata can provide in the Linux image.
And then on the other side we have unique kernels which go to the extreme and they only get what is extremely necessary for the applications.
But because most people don't really like unique kernels because they're difficult they're not that easy.
It's a special reporting.
People in the unique kernel community have tried to create let's say Linux clones so they're trying to be binary compatible with Linux.
And we don't believe that this is the best approach because we don't get a benefit of unique kernels.
And instead of doing that we're never going to be Linux compatible if we are not Linux.
So why not just use Linux? Linux is running everywhere.
We can just customize it as much as we want and it's compatible with everything.
So we are not the first one who got this idea of course.
There was a team from IBM that created a very nice paper called Lupin and they were trying to make Linux in looking more like a unique kernel.
They identified that there are a lot of configuration options that they could simply just remove them and they were really created very, very tiny Linux kernels.
And they also tried to play around with system codes and overhead and they were the key findings that they were able to boot as fast as unique kernels.
They were very small and they identified that the system code overhead is not that big.
So based on that we want to do the same thing.
We want to create a tool that will analyze the container will identify what is especially required for a specific container.
It will create a configuration for the kernel for this exact container and then it will analyze the.
Yeah so and then it will just build the.
The kernel so I will go here and so.
Yeah we don't really have time but this is.
A kernel a latest kernel and we have configured already as you can see we have already built it because we don't have time we're not going to build it now it's not going to take a lot of time would just take a few maybe one minute or something it's very very small actually I can so you the size.
Of this it's only around 12 around 13 megabytes so we will take this.
A kernel here we will copy it.
Inside here and then we will and we have created the tool that creates a some it's based on built it and LLB.
So what what we're going to do right now will just copy the.
The kernel inside the.
Inside the container and we use us a base the n's the next.
Alpine version and we have this huge similar line that we try it to we just say to n's and don't run on them on because we will.
So we will build this.
Container.
Single with the bigger build.
And this will take a few moments okay and now to we can run it.
Yeah so here we we have the container running inside the VM it's a next and we can even.
Get here.
Get the IP.
And we can do it here to solve that it's working it's working.
Yes it does working and we can also.
Stop it here.
Oops.
Okay.
And to to show you that we indeed run in a different kernel.
We will just say here to.
You name.
Yeah I soon do been here.
We will build it with Docker.
Okay.
And now we will just run the n's next alpine with just.
Okay so at first we will just run it on top of.
And we see that we are running in this kind of kernel here in 6.12.
We will do the same with.
You run with runc and we will do the same with urnc.
And we successfully panicked.
But why we panicked is because the application just exit.
So as you can see here somewhere.
Oh yeah it's at nom there.
Okay this binary doesn't exist.
Okay so we're not going to search it.
But it's simply runs a new name.
So if we do like if we try to do.
Here.
It was been you name.
Yeah.
It seems it's there.
Okay that's weird.
So to to wrap up.
We we also do the some very very early evaluation about this.
To measure the kernel elements that we created that I just sold you and also measure the good time that we have.
And we you can see the test with here.
So regarding the image size we had.
We target the n's next and we can see that lower is better here.
The sizes are in.
And we see that cut is extremely big.
Then we have the case of unicraft is the generic unicraft that tries to be binary compatible with Linux.
And then we can see that our Linux is even smaller than unicraft.
And then we can see that the original looping kernel was just.
And that was based on an old kernel.
So maybe that's the reason.
We have the unicraft HTTP which is a very specialized unicanol that is just a few kilo bytes.
So regarding the start time.
We see that again lower is better.
The start time is in milliseconds.
We see that runc is the fastest one.
Cut is quite slow.
And you can see can almost be it's not as good as runc but it's very close.
And so that's even with the booting of the the Linux.
I would like to mention that this project is partially funded from European projects.
And some arise we know that containers are great.
They like some kind of isolation.
Some books execution is as an alternative for providing strong isolation.
But they induce some kind of overhead.
We try to reduce it and we can do that with urnc.
And we even want to strip down the Linux kernel to make it even smaller and fast.
And you can check out the code in this kind of two links.
This is the building tool and this is the container runtime.
And you can also count more to the web assembly development.
See how we also integrate this kind of things with web assembly.
So thank you for your time.
And that's down the side.
So thank you unfortunately out of time.
So if you have any questions you can take them outside.