 All right. Hello. Um, good afternoon. Uh, thank you all for coming to this presentation today. Um, so today I'd like to talk about the titles beyond orchestration, the cloud native run times ecosystem for performance and security. Uh, my name is Alexander. Um, I'm from a project called Unicraft for an open source, uh, library operating system. Today I'm going to make a comparison between existing run times for the cloud, what they look like. Um, what it kind of looks like to deploy a, uh, runtime in the cloud, what it means for security and performance and how Unicraft is trying to change the status quo of what it is to have a performance and a secure application in the cloud. So the themes that I've noticed over the last few days here at KubeCon going down booth and going at lots of different, uh, talks is that there's a lot of CVE scanning package scanning. There's applications that are, you know, we look at a particular item and then we have some system to introspect it and we can do this in a number of different ways. And so there's also a number of open source projects that are doing this, but there are also a number of, you know, companies that are offering this as a service. And this is sort of the idea here is we're going to step back and kind of what's the problem here, uh, in overall, right, in the sense that we are looking at a traditional system. Um, the other one is performance and how we tackle this. And again, it's a lot of introspection. It's a lot of, you know, there's some different themes here. Like we have AI models to look at traffic detection and then we optimize that way or we look at inside and we change the libraries. We compile them to make them more specialized. Um, or we have like slimmers like this Docker slim, uh, slim AI out of this. Uh, there are a number of ways that we can reduce what we have already to make it smaller and therefore more performant. And so overall in general, what we're doing is we're introspecting and we're looking at something and we're trying to find out ways to make it more secure and ways to make it more performant. Um, when we look at how we approach, uh, the runtime of things in the cloud, um, there are a number of different sort of solutions that are lightweight. Um, if you look at some projects, K3 OS from Rancher Rancher, of course, this Linux kit and this, uh, from VMware photo, sort of a container runtime platform. Um, and these projects, they basically still rely on the traditional kernel stack. Um, and they still run on top of a hypervisor. And so what I'm trying to get at here is that both the security and the performance are reliant on a traditional fashion. That is the large kernel hypervisor kernel, the large Linux kernel, right? Um, and there's a lot of problems with this particular stack, right? And if we look at the container runtime, container D, there's new projects like live K run, one J, et cetera. Um, there's still sort of probing underneath it, the operating system. So as much as you're trying to tune this particular model, you're still reliant on a sort of flat base that is sort of homogeneous across the industry. This is the Linux kernel, right? Um, the problem I'm trying to get at ultimately is that there's lots of layers of indirection. So there's a virtualization involved here that you are so far away from your application. Your application is so far away from the metal that it's actually running on. So your pod is usually containing an application. Sometimes this, you know, it's, you can't even put two applications in it. Like if you start a bash script and it spawns multiple processes. Um, this is then separated by namespace by the operating systems container runtime. The container runtime is doing communications with the OS. And then finally it's running on top of a hypervisor, lots of indirection. And this is creating the problem here. This is the security that we have to look at now across many different layers. And there's the performance penalty of having all of those layers. Um, and of course the security part here, your cube system, things mingling with your pods. So if we try and tackle the problem sort of at the lowest level, we try and reduce Linux or the, you know, the monolithic kernel that we have, we find that it's actually very difficult. And so we did a study where we looked at the dependencies between different modules inside of the Linux kernel. We used a program called C scope. If one function was referenced in another module, then we counted that as a individual reference. And then you can see this sort of maze of graphs between major, you know, subsystems within the next. So it's very difficult actually to pull apart the Linux kernel despite there being tools to optimize it, despite there being systems to try and reduce it further. Um, this is where I get to introduce to you the concept of Unikernels. A Unikernel is a way of approaching, uh, looking at the deployment model for your application and rethinking about what we need to actually run the application truly. So if you look at the full stack application here, you have your application, of course, it's third party libraries and dependencies that you need for it to run. But then of course on top of it is the traditional stack that is the kernel. It's the operating system. This might be a distribution, for example. And then finally it's sitting on top of platform and hardware. Stepping back from the 30 years of research and development that's gone into Linux and to all other operating systems and picking apart the different parts that we need, we can sort of think about it as a library of OS kernel, OS or kernel, uh, libraries, right? And you can pick and choose. The Unikernel model is where you select the necessary libraries for it to become a kernel and then go through a process of building it and constructing it to result in what is a final Unikernel binary image. The Unikernel binary image has a number of different properties. It's something called compile time specialization where you are taking your application and you're making it during the ICD process, for example, more specialized towards its target. It is a lightweight virtual machine. So it is capable of booting by itself. If you think about compiling something with GCC or GoBuild, it's a similar process where the end results, this is a binary that can boot, right? In the same way that you have VM Linux. It has a single sealed address space so there's no longer a separation between kernel space and user space. They're all one of the same, but there are no other processes. There's no SSH. There's no system D. It is literally just your application. So what was, for example, 300 CPU cycles to make that check is now only a few CPU cycles. No syscals, right? It only does one thing. So there are no other processes that are running in a single process. There's no SSH. There's no system D. It's actually just your application. And then it is also targeted directly for a hardware platform combination. So it will, if you're talking for an architecture, but then also for the hypervisor that it will ultimately run on, whether that's KVM, for example, or Zen, VMware, Hyper-V, et cetera. So this is what Unicraft does. Unicraft is a Unicernel development kit. We started as a Zen incubator project around 2017. We're actually Linux Foundation, but we're trying to break into the cloud-native space because it makes quite a good use case, for example, for lightweight serverless functions, lambdas, et cetera. So it's a little bit about our community. So we started off as research. We have a lot of industrial partners, a lot of universities that we work with and a lot of contributors that are still with us. The complexity, so the next few slides are just a little bit about the result of building something as a Unicernel. The complexity of your final kernel image is a lot simpler. It makes it a lot easier to debug, for example. So if you remember that sort of mesh graph that we showed before for Linux, this is that same program running now only for Unicraft, and this is Nginx compiled against Unicraft. So it's now an Nginx Unicernel, and there's also just a hello world that just simply boots and prints the words hello world. We did a performance comparison against Unicraft and then a number of other technologies. Of course, Docker running on container D and then Linux bare metal, for example. We have a physical machine. We installed Linux. We ran Nginx on it. We pinned Nginx to a core and then in comparison. Here it sort of really demonstrates that the cost between jumping from the user space space, you know, if you're doing like a read or write or doing some IO path into kernel space really has a performance penalty. So there's an 82% increase in comparison compared to Docker. Memory requirements of course also go down. So Unicraft here on the far left only using a few megabytes of memory that are required to run any particular application here the different applications. We also support a number of different virtual machine monitors, platforms basically. So we can run on Firecracker and here you can see that you can boot a simple hello world application and this little is 3.1 milliseconds sort of as a virtual machine. Just for fun, we were playing around with edge devices. It makes sense given the sort of low resource capabilities. So this is on Raspberry Pi the amount of time it takes to boot actually and get something to work. So here we have Nginx for example booting it only 92 milliseconds compared to when we installed Alpine Linux and here we even customized the Linux kernel so that it had for example security mitigations turned off so that there weren't extra guards in between different process calls. A little bit of comparison for CPU cycles and how long it takes. Linux and KVM, this sort of generally this 200 CPU cycles and then Unicraft is a lot less because there's no check now between the memory and user space and kernel space. The transport is obviously now a lot smaller because you're no longer having to ship a full file system containing shared libraries with things that you might not necessarily actually use for your application so if you looked at Nginx and we pulled the same version here it contains shared libraries that are not statically linked against the Nginx binary so they're required and they contain functionality that you don't necessarily need but with Unicraft you literally compile all the necessary libraries that you need and then you can go even further you can actually do compile time specialization strategies such as link time optimization, dead code elimination etc. As a result, there's a reduced attack surface so you have no shell, there's no way to penetrate sort of externally if there's exposed ports there. We have the opportunity to specialize the memory so you can do ASLR every time you rebuild the kernel you can make it unique. You get now the lowest level of isolation that is provided by to you that is hardware the virtual machine is still the standard unit of security in the cloud you still provision containers inside of virtual machines and now you get actually this but without the overhead and then there's lots of specific CPU security features that you can enable given a certain use case so we have a lot of ARM support and we have a partner that uses it in automobile for example in automobile use case and they sort of adds additional security features based on the ARM architecture. And then actually as of today we released a new tool called craft kit and it's a command line companion tool that helps you build unicernals quickly and easily so the idea is here alongside the library operating system is that you have a tool that basically lets you grab all the libraries that you do need and also you add a simple craft file to your repository it looks a little bit like this you can then list all the libraries that you will necessarily need if you need TCP IP stack or if you need this is newlib which is a libc which provides basic functionality at your application the idea is that you then go fetch those libraries with this tool called craft kit and out pops a unicernal you can then also use the same tool to build different packages so you can make it OCR make it look like an OCR archive you can also then push it to a registry and then you can then use it in production our goal with Unicraft is to try and be the new unit of runtime so that people can leverage not only better performance but better security and to do this we want to introduce Unicraft into this ecosystem by making lots of integrations and today I'm going to go over one of those integrations and this is for running on Kubernetes so there's a lot of tools out there that already allow you to run virtual machines manage virtual machines through Kubernetes Lima is a new addition to the CNCF space there's also kubbert, there's cat and containers and they still rely however on the idea that you are running your container within a virtual machine and so if you dig deep dive into the source code it still has this requirement to SSH into that virtual machine and launch a container so it looks like a pod it shows up as a pod it has all the right sort of characteristics of feeling like it's cloud native it's big bulky Linux kernel with a container inside of it and so obviously you're still going to have the negative effects of performance and then by total implicitness because SSH is required you're now exposing an official attack factor so we investigated how best to approach making this integration and to do this one of the ways we can do this with container D and by making the unicernal look and feel like a container and then that's by wrapping it in OCI image and using the OCI runtime specification so maybe you're familiar with one we're making something called runU it's a very high level right this is showing how we sort of connect between a controller node and a physical nodes or virtual worker nodes what's important here is the interaction between the container runtime and the host and so the rest of it is just exposing the right APIs so that Kubernetes looks and sees things as pods or as services but we have to manipulate the host itself to be able to run the unicernal so we have to install additional tools and I'm going to show you what that looks like so this is sort of the only bit that needs to be changed in the whole model so the basic process goes along where we have the Kubernetes control plane which has a request to create a pod and then it goes to a cuplit creates a sandbox pod with container D and this invokes actually something called a shim program right so basically a binary it accepts TTRPC requests or it could also be GRPC requests and this binary basically invokes a run something program and then this invokes the ultimate system that's creating previously a container but in this case a unicernal and so in the previous case or in the normal cases invoking run C run C then starts a namespace it's sacrament, it does TRUT creates this file system for you it offloads everything into the file system from the OCA archive and then starts the process with a given environment but this is where we inject ourselves in the whole process we create a run Ushim the run Ushim then invokes the instantiation of a kernel using whatever virtual machine monitor tool that you would like for example KMU or Firecracker it's very simple to install you basically add one line under this prefix saying this and then it knows where to get the binary because you've also listed the binary name this is important because then you can specify that you would like to run a unicernal as opposed to a container later on in your Kubernetes manifest then all you have to do is build a binary so we build a binary called runU the interface is basically creating sub commands necessary to start an instance based in this whole life cycle and then these basically map to the instantiation of a virtual machine so to then make the unicernal feel like it's a container we use OCI which is basically a tarble and inside the tarble you put things inside of it so we put the kernel but that means that we're complicit with the rest of the space so you can put this unicernal into existing OCI registries we actually use a tool called oras they're here actually a kubecon that basically allows you to take arbitrary files and put them into the registry and so if you follow the tree you basically end up getting this is what the binary looks like it's file name and then you can also have an initRAM for example the process here is that containerD goes to the OCI registry retrieves it unpacks it and then goes through actually craftKit to then unbundle it and have the file system where the unicernals available and so the result here so I showed you previously that we had this virtual machine and inside the virtual machine was the container here we now have direct access to the hardware so this is what the model finally looks like so we're still working on this there's a lot of work to still do there's still we're having regular meetings and we're sort of building more integrations with more cloud native tools so one of the things that we found was that the OCI archive specification was very limiting it has, there's a lot of opportunity to put more metadata into the OCI archive for example if you look at the specification provided by the runtime spec the runtime spec has very limited information about what the host is capable of doing and you basically just specify for example that there's an OS and what OS its name is and that basically is a map of Linux, FreeBSD, Windows, Mac or something like this but this is very close view of what's actually capable in the hardware you could for example expose more information about what capabilities the hardware have or what drivers are available what system services are available for example whether you have a particular file system available to you or not, or how much of that file system and of course it also indicates what architecture is but it doesn't indicate for example which architecture extension it is for example for ARM so there's more information there's a lack of information we found with the OCI specification and we'd love to be able to collaborate and find opportunities to make this more rich of course with unique kernels since they're specialized services and their compile time specialization means that you can do there's opportunity to make it even more performant or even more secure if you really know what is happening at the end so unique kernels usually find a good place in the edge where hardware resources are limited but at the same time understanding what the scheduling of services might be for example if you're co-locating services you could specialize those unique kernels to be better co-located for example you could do shared memory pages by compiling a special library that then allows you to do shared memory rings so being able to tap in for example to the schedule or the scheduler for Kubernetes for example how it's going to schedule services could benefit unique kernels but there's some open challenges here you have to pre-compile it what does the deployment model look like do you put this into the OCI archive for example and then of course the same problem before about the host like there's lots of opportunities to create many permutations for a given unique kernel in the same way that you have several permutations for a normal OCI archive when you compile it against several different architectures so this kind of is the result of the talk thank you so much for listening please do join our discord or give us a star on github my name is Alexander and I'm happy to listen to any questions thank you for the talk it's great I have a question regarding debugging and just logging in general so in this case I just have very limit number of processes and if I'm a user or developer how do I debug or log in things or metrics of the ability this can so I mean with Unicroft particularly we have a built-in GDB server so if you wanted to like debug it it would feel like a normal experience with debugging a program and so this is if you're debugging compile time language such as C, Rust, Go for example you could use these features and it would feel very normal to you but at the same time you can also just debug it in a normal user space environment and then the last step would be to compile it as a Unicurnal it's really only if you wanted to debug the kernel itself and then for runtime languages such as JavaScript and Python we have pre-built Unicurnal images for those runtimes so you would just mount those files into a file system and then they would start executing in a normal way that you invoke Python and then your program name this is onto your question Is there a way like during the runtime can I be able to I guess I cannot access into the workload right so So there's a number of observability systems that we can attach to Unicroft as well such as Prometheus and then you get really fine grain access to the whole kernel and what's happening as well so for example you could look at the way the TCP IP stack is handling your load as well it really depends on what you want to see and when if you want to just try and debug it because you're getting like a program error it would be a different sort of model here maybe locally as opposed to when you're doing it in production then you would have you know these monitoring exposed and for example as a library I see okay I have another question so for the IO disk IO and network in this case do you and do you just add more like a kind of module like how do you enable for example but IO network and also the disk IO yeah so a vert IO is supported a number of different vert IO platform drivers and so if you know what your target is if you want to for example use KVM with vert IO you would then use those particular libraries you would enable them we have similar have you ever seen like make menu config you open up make menu config this is one of the configuration systems for Unicraft it's kind kconfig based and you can go in there and select the different libraries that you want the different platforms and based on the platform you have selected you can select other different configuration options that you can then set but there's a number of different file systems that we do support 9pfs for example this so this goes over the vert IO you can also run things in init ram this is the most performant is a ram file system yeah so in that case given normally you have this kernel space and user space isolation the Unicernel since you don't have the isolation is there any that actually has security implication now with all these different where our protocols potentially the application can more easily to explore if there's any bugs in these protocols so when you are now building your application as a Unicernel you trust more the code base it is only the few libraries that are necessary for it to be a virtual machine you are no longer reliant on the full Linux kernel that has its vulnerabilities or there's ways to exploit this for example but there are a number of security mechanisms that you can also enable like ubsan ksan there's also specific architectural security features like on pauth that you can enable for the Unicernel to add security increase the security of the image at the end you can also do image signing for example when you do transportation thank you what are the most popular use cases for Unicernels today so either a cloud application things that are usually high IO so web servers crashes in memory key value stores we also found that anything that runs on low resource usage low resource capable devices so closer to the edge they perform very well but you can build for example your Golang application or Rust application normally you can make it a Unicernel at the end and then you can run this we also support major cloud vendors such as AWS TCP etc so you can deploy your Unicernel as a virtual machine there and then you don't have to use as much resources as well compared to running it as a full virtual machine so you can save on costs compared to installing a traditionally bloated kernel then a container runtime and then your application or just your application hi so you said that you support major cloud providers can I take that virtual machine and throw it in a Kubernetes cluster on any of these cloud providers it's a good question so some of these cloud providers do not offer nested virtualization such as AWS but we are working on a mechanism that allows you to run for example an EC2 instance that's managed by a Kubernetes instance so this whole workflow that I showed you with this container shim layer and it's managing the virtual machine underneath one of the ways we will extend this in the future is to be able to add support for cloud vendors so it would provision as an EC2 instance and it would look like a pod still make sense thank you any other questions? pretty much good perfect thank you so much