 So Unicraft is actually an open source project that we started at NEC while we were experimenting and playing around with unicorns in the past. So I'm also from that research lab we're coming from so it's in Heidelberg based in Germany and I'm a senior researcher there and also the lead maintainer of that open source project. So you probably are aware that VMs are around for a while and they were really good in features like consolidation, migration and isolation. And then this hive of containers happened and they became much more popular. People use them now and they're actually pretty great but what you hear them from these people is they're much easier to use because I have this Docker file and I go. My containers are much smaller than your VMs. My VM usually is 10 gigabytes but my container is just 100 megabytes and they're also much faster to bring up. The VM takes minutes to boot but the container is up in a few seconds. And then we say usually wait, wait, wait, maybe all correct but actually did you hear about unicorns because you should be aware that VMs still have some advantages that not necessarily get from container environments and most importantly is strong isolation. So let's give you a really short overview of what a unicorn is. Let's take this example on the left side you see a cloud service deployed with virtual machines and each service entity is one application running in an own isolation box or in an own virtual machine. You have then a standard operating system underneath meaning most of the time it's a Linux kernel, you run on a hypervisor, it might be KVM, Zen or VM there or whatever you deploy. And yeah it's quite a heavy weight, this stack is quite big. So what do we do in unicorns? So first of all we want to keep the same service as before so we take that application, keep it still in the isolation boundary. But what we do is replacing that general purpose kernel and put a purpose built kernel towards that application underneath. So you see that service A has a different kernel underneath than application B. That whole thing is a monolithic binary that contains just a few kernel layers and the application and also only features that the application needs. You don't need isolation anymore if you have that assumption that you have anyway just one application in one virtual machine. So you don't separate between user space and kernel space anymore which gives you also the advantage that you have further freedom in further specializing the kernel towards your application. You can tweak and tune it so that it performs that task quite well. So the gains that we found with our previous research doing that mainly coming from network function virtualization space is fast instantiation, destruction and migration times in order of tens of milliseconds. A really low memory footprint of few megabytes of RAM. You could achieve extremely high density of these services. So we were able on a single hardware server x86 to run 10,000 guests and then we run out of RAM. We could achieve high performance by just using a single gas CPU. So we're easily able to cope with 10 or 40 gigabits network throughput at that time. So that number is already two, three years old but even there I demonstrated already how fast this stuff can go. And last but not least you have also reduced attack surface because you have the argument that you have much less components in a unique kernel. And next to it the strong isolation is provided by your hypervisor environment. So what I want to do is give you just a few graphs to demonstrate what we found there from our research work. So let's talk about the instantiation times. So you see on the horizontal axis the number of simultaneous running instances in the system. What we take here is because it's a baseline measurement and an application that actually does nothing just comes up and tells okay now I'm here and then it just stays in the system. And on the vertical axis you see the instantiation time of the nth guest that was created and also please aware this is a logarithmic scale. So we start with that application as a standard Linux process and we get numbers like 0.7 to 10 milliseconds of creation time if we create like 1000 on the machine. If you put that into Docker that is still good but is increasing already to 150 to 550 milliseconds. But if you take now a standard VM so let's say you just double-strapped Debian and then wait until the application is up. Especially if there are lots of VMs in the system then that time goes up to 82 seconds. And then let's take a unicolonel doing the same thing right and then also running as a VM and we are around 63 to 1.4 seconds. And I want to add here as well that this measurement didn't modify anything on the tool stack which we also did in our research. So if you're interested I can point you to some papers where we replaced the tool stack with something written from scratch which is much more lightweight than standard Zen and then we could boot even in 30 milliseconds or less that unicolonel. But so far so good. In performance to show you a purpose-built HTTP web server so it's completely purpose-built nothing ported. In terms of throughput you have here a Debian virtual machine running nginx so this is the DN you have a Debian virtual machine running light HDPD. The T means here it's Tynix which is actually a small compiled Linux kernel then just running the process directly from the InetRAM disk. They're all getting one CPU assigned and the same amount of RAM assigned I think was 512 megabytes or something. And the file system is served from RAM disk if there's any. So in terms of throughput you see here not that much often advantage as soon as we go more up to parallel connections because the bottleneck here is the actual hardware nick. Because you have so many offloading features in the meantime like segmentation offload and so forth. The interesting part is dealing with request per second. And the yellow part is our actually our unicolonel and we are six times faster with the same resources in that virtual machine environment just being extremely purpose-built to that use case. So application domains so unicorns you can actually have in a wide big area and fields and it's also that we found that the properties that unicorns give you each use case makes use of a different set let's say. So what do we have we have actually fast migration and destroy time. There we would go in something like reactive NFV so imagine web servers that just pop up when your request is coming into your server or server less or Amazon Lambda and you know this this kind of things with extremely high resource efficiency. Also good for server less if you if you consider you have high consolidation lots of serverless tasks on a machine. IoT and mobile edge computing where you go into an area where you have more resource constrained devices that host your services on the edge of the network. High performance really important for network function virtualization also mobile edge computing and then mission critical because we have a lower attack surface. Potentially we would have a cheaper verification which is then getting interesting for even industrial IoT cases or even automotive. And you may ask here now so this is all great so we have similar speed and sizes containers or even less. We have then even strong isolation security but why is not everybody actually using it so that's a bit weird. And the problem is actually the development of these unicorns so each of these highly optimized unicorns is until now a manual task. It takes really months or even longer so if you let's say have the target to create a web server with the unicorn you start you know developing here then a driver there and then you choose choose a hypervisor where you want to support it. And then you make use of there of some specialization features so that it runs quite well on that platform and then somebody else comes along cool. But now I want to run it on KVM and you're like okay I can start from the beginning because you have different drivers you have a different virtualization environment and so forth so it's a throw away in the end right. So then even imagine you come now with a different application like a database server something you start the whole process again and again and that's in fact not something you actually want in a more production environment. So this is where we come along with with Unicraft where we actually want to provide a bit like a unicolonial build framework. So the motivation that we set us is we want to support a really wide range of use cases meaning also supporting wide range of specialization techniques or whatever you want to do in your unicolonial environment. Meaning also to us probably don't know what the end users actually are the unicolonial developers actually using for optimizing his use case. So we should be open also for that and not dictate any design decisions. We want to simplify the building and optimizing process. Simplify porting of existing applications. So most applications likely use something like for instance the POSIX API so that's a good share point and then also for lots of these unicolonial projects to get rid of this throw away argument or a problem. We want to have a more common and shared code base for all these unicolonial projects that they can you know just reuse and with one compile we want to also support different type of CPU architectures. And this is actually Unicraft where we use it's a quite well known concept like where we say everything is a library. But in our case also OS functionalities are libraries and we provide multiple implementations for schedulers for instance or memory allocators. And Unicraft actually consists of two main components one is the library pool and the other thing is the build tool itself. So let's give you an overview. In the library pool we distinguish actually into three types of libraries. One is the main libraries which are kind of independent of actually any target execution environments. This could be network stacks. This could be file systems, schedule implementations, libsys, drivers and so forth and so forth. Then we have the libraries that are specialized for a hypervised execution environment like Zen or KVM or VMware or whatever you want. And then architecture libraries that is like the last piece of missing pieces for implementing CPU requirements for your Unicolonial. So when you take or you create or build your application select and configure the libraries you want to use in that case type make. And the build system is then creating you multiple Unicolonial images each fitted to or specialized to the target platform that you want to running on. Also what I need to add here is that the system is also built so that you can come and replace libraries in that pool or even add your own libraries to it as well. Let's say one might say Lightway IP is a nice network stack because it's small but it doesn't give me all the TCP features that I need for my application so I'd rather get for something big. I would like to run a ported BSD network stack so then he would select a different network stack or maybe he has an own written network stack so he would just take his library instead. An example system. Imagine you have a Python script that you want to Unicolonialize. You would just select a language environment in this case this would be here now MicroPython coming from the embedded world. Network stack, VFS and whatever you need and you get your Unicolonial just running executing your Python script. The build tool is quite close to what you're used to when you use Linux so it's kconfig based and has also lots of make file magic behind. But the workflow is actually make menu config then you see like you know different options where you can then start selecting the libraries that you need configure them. Choose your target platforms and afterwards it's just a simple make and you have your images. To give you some numbers as a baseline example so I will show you after the slides actually a bit more real world demo with a small network stack that replies to HTTP with HTTP requests, HTTP replies. To give you a baseline when we start the project we could compile a small Unicolonial that does nothing else than just come up say here I am and shuts down afterwards with 32.7 kilobytes. And also you had only to assign 208 kilobytes of RAM to get that thing running although we had to modify the tool stack because hypervisor builders thought less than four megabytes you will never have right. So even there you had to remove these hard coded limits. What is going to happen soon so we are around now since one year so I announced actually in last post them this the start of the project so we have now an upcoming release in the upcoming week. Which gets a new version tax 0.3 what you will have in there already is support for Zen KVM Linux and even a bit experimental bare metal port for various architectures. As core functionality we provide you a cooperative scheduler library although a preemptive scheduler library is in work currently. Then a binary body managed heap allocator although you could also replace that one if you don't want that. We have pretty new and that really is a networking which is where we introduced an API which is pretty close what you may know from Intel deep decay. It's still interrupt driven but it's it provides you know specialization features like you can batch number of packets and so forth. Library IP as a first TCP IP stack to the system. We have a VFS implementation where we then can move on later to add file systems underneath that we can mount in there. And then the two lip sees that we have for now is no lip see which is a. Vision one in the Unicraft ecosystem to support you know more Mila ballistic built. But most application use some more fancy POSIX functions so for that purpose we have also new lip available on the road map. We have we have they want to concentrate our effort on getting more complete arm 64 support actually it's the arm folks by themselves providing us the arm 64. Architecture and platform support for for KVM. We have started internally playing around with more libraries like muscle live UV Z leap open SSL and so forth which are more like for cloud of cloud environments more standard components that you need in your software stack. Since we have a focus on serverless we also looking in a language run times like JavaScript Python Ruby C++ and so forth. We want to come up with an OCI container target support so so that you can even build a container image that you could just launch in your container environment instead of just having a virtual machine image. File systems who come up with with first of all with an in RAM file system but then also with block drivers to support actually reading something from virtual disks or nine PFS actually. Then network drivers since we have what I owe for now only we have in the pipe Zen with net front and for the Linux target a tab driver. And then also want to support frameworks like you know no GS Pytorch for maybe machine learning tasks on in the network Intel DVD cave in which actually would like to port the whole framework to Unicraft so that you would build. Unicorn and a V boxes directly. Yeah and it's open source and actually we still need support because we have actually quite a lot of stuff to do. So as I said actually we started December 2017 and actually as an incubator project in from the Zen project so it's also covered by the Linux Foundation we get actually quite nice support for them. The community grew since then so. We started with two contributors we are now at 23. Mainly we have to mention the big contributions from Romania we got a networking scheduling support which from from professor and students from university in Bucharest. From Israel we had someone that was looking into bare metal support and was providing a VGA driver so that you could actually without any hypervisor underneath run Unicraft directly on hardware. And from China there's a lab from arm that actively works and contributes for the 64 bit support for arm which is quite nice. We actually are mailing this based our project so we have actually we hijacked the mini as develop mailing list from Zen maybe you heard about that. The idea is also maybe in longer term we are able to replace that mini as Unicernel base there so that also the Zen folks have something to build their their stop domains or something for that. Then we have an IRC channel on free note called Unicraft and yeah probably I flushed you know let's go for a bit demo time. And then you get some more references and points and we can also then do a question round. So what I want to do going to show you is actually probably you all had had a textbook that explained you how to program a socket on a Unic system. So that you need to have a socket call to set addresses bind it and this is now being a socket server that is going to listen on on on a port. And you have a simple while loop that then will just as soon there is a connection and the first byte arriving it will just send a static string which is by chance something that is H2P 1.1 compatible here and sends out a web page. So this should demonstrate you a bit. One of our targets that we want to have a Unicernel that is kind of the same way as you would run or develop your application for a standard operating system. So let's go here. You have here main.c this is the program. You have a make file that I can show you that looks like quite similar to an external Linux kernel module. So you get to get another make call invoked that then kicks in the Unicraft build system. And then you have a make file.uk which actually describes for Unicraft which modules do you have or actually which source files do you have and so forth. Which as actually just main.c to the build and registers a library which we call here now app HTTP reply. So if you type make. I did make already. Let's do clean so that I can prove you it builds. It's now building a KVM virtual machine image the network stack. And at last. Okay, some some lip sees scheduling and then you have the final KVM image. In the menu config. Oops. I broke it. Ah, yes. Yes, yes. Yeah, that's a that's a funny K config thing. So you see here you have a menu for architecture selection. So I built it now for X86 but you can choose also, you know, other architectures. Platform is like one cent KVM so forth. Although we have only networking support on KVM for now on the libraries. You see here's library IP we could go in here and select features in there. We could even build a network stack without TCP support. It's actually funny to call it then still TCP IP stack. And so forth right you see it's it's quite of libraries are in there. We have some build options. And that's it right. And if I run that now as a KVM guest. So do you see that line or maybe I move up the window of it. I load the kernel image. Apply KVM and I need to attach it because it has networking to a network bridge. Wonderful. I have mistyped here. So now it's up already. You see it was going through the virtual buyers was loading the image. This is still a chemo. And then from this point on, it was the unicolonel. It found its network device brought it up and then the DHCP server in background replied with this address. So what we can do here now we can ping that host to see the response that you believe me. I will kill now the guest. It's not responding anymore. Nothing happens. I reboot it and here it's back again. And then if you want, you can see also the web page served. I think next time I will clone the screen so I see the console here too. It's a proxy configuration. Yes. So it came, got served and it's that string that got sent. Right. So the kernel image itself or let's say the unicolonel is just 222 kilobytes in size. So quite small actually. And now to show you that it's the same program, you can just go and, you know, take GCC and build it as a Linux application. Now we have added out, right, which is of course smaller because we don't have a virtual driver in here and so forth, but it does, does the same thing, right? Right. So open for questions if you have a bit of time. I understand the like isolation guarantees and stuff. I'm wondering if just sort of operationally there are additional challenges to monitoring and operationalizing the unicolonel. So yeah, that's actually a good question because the thing is it depends what you built into your unicolonel, right? You could say I do it as minimalistic as possible. Is it actually our main target? But then you don't have like a shell or something in there anymore. So you can't SSH into it. So you're kind of forced to use the tools that the hypervisor environment provides you. But at the same time, we could still say and it's also what we have a bit in our mind on the agenda. It's not written actually is to provide a library that gives you kind of remote access maybe with the rest API or whatever so that you can even look what's going inside, what's happening inside the unicolonel. Yes. Substitute the POSIX API. Right. Yeah. Actually, probably I should repeat what he said for the recording, right? Right. So the question was or actually more confirmation that we run everything in sub-user mode. So it's kernel space in our perspective. And calling something from the POSIX API is just for us a function call and there's no system call. So more question. Yeah. So the question is how hard is the driver? How hard is it to pour the driver from the Linux kernel? Here I need to say it's pretty hard because we have a different license. We use BSD and actually to allow you also build up some unicolonels that use non-GPL software or a library that is non-GPL. So yeah, Linux is for us a no-go but actually we would look into BSD, these OSs to port something. And that kind of depends what you want to port. So for now we have just a networking sub-system with defined APIs for the drivers and we on purpose looked at DPDK because everything runs in user space. They have kind of a similar thing of a library system there. And we thought, OK, maybe can you reuse those network drivers? How this will look like for other drivers? Let's see. It depends which APIs we will come up. But on the other hand, since you're a target on virtualized environments, it's not that you need a whole bunch of tons of drivers. What you need to support is the virtual driver model of your hypervisor environment. Yeah. Yes. I'm curious about your experience with LWIP because I can see that this would be the TCP and PSTECs that you picked for first prototype of the implementation. But my experience is that if you want performance, and especially in the presence of multi-processing, and WIP being focused on embedded systems, it won't cut it likely. Yeah. What are your experiences? And do you have a roadmap or plan for the future? So the question is what are the experience with LWIP? I need to agree. It's quite limited. In that sense, if you run multiple threads or whatever, this can be quickly a bottleneck. Also, features what are missing still are supporting segmentation of loading, for instance, to make use of 64 kilobyte packets that you can send to your actually NIC driver that runs on the hypervisor host. Chopping that TCP segment into smaller packets. So for that, we actually have on the roadmap that we want to port a network stack from BSD. For which BSD? Let's see. Probably we can also do the shortcut to go through OSV. OSV is also a unicolonial project, and they ported it already. So we have maybe a bit more new environments so that the extraction from an existing kernel environment is a bit easier for us. So the question is about language support for components of the system or also applications. And this is what we are actually after that release really trying to focus on, especially languages that are really popular like JavaScript and so forth in these cloud environments. Let's say probably it's still someone looking a bit deeper in order to make even system libraries be able to be compiled with the whole system. I'm not sure yet where there are pitfalls or not, but I could still imagine, at least for C++ it's quite easy to bind that to C code so that some of the system libraries could be in C++ and then you need this extra small code that you need for exception handling and so forth with the C++ comes. But I could also imagine something like Go, which is also compiled language and is easy to link with a C code, a garbage collector we would need then, which I usually don't like, but that language requires it. Yeah, so I guess this is more... that can be answered when we have some more language environments ported and then it's trying out and see what's missing. So we just started with Python, so we actually took the MicroPython project that is down there and got a nice unicolonial running Python programs running. We also looked into V8, which is the Node.js JavaScript engine. There we're still missing some POSIX functionality to get it actually working, but I think probably this year we might be able to reach that point. And also Ruby, we have a student that is interested in porting Ruby to it, so we need developers. Yeah. Okay, thanks.