Basically you replace the system calls into the kernel with library calls. So you end up with a single binary that contains both the application as well as the operating system functionality.
This can lead to some rather spectacular performance benefits. One thing is that you remove the syscall overhead, but more importantly you can do a lot more optimizations at the compiler/linking steps.
You can remove complex code that tries to dynamically model the world with rather plain code that does just what it is supposed to. With IncludeOS (C++17 unikernel) we did make a firewall implementation that instead of using complex data structures relied on preprocessing the rule set and translate it into C++ code. The code to do this was quite simple and resulted in pretty amazing figures wrt number of rules per packet per second. Metaprogramming can sometimes deliver amazing results.
Similar things can be done in a traditional kernel as well and we've seen eBPF firewall implementations that are able to get similar numbers. On the flip side eBPF and it's firewall implementation is order of magnitude more complex. However, you can push eBPF code onto the networking card which can be a huge benefit. And ofc you could make a kernel module that implements a specific firewall ruleset and get similar performance without eBPF.
I like unikernels because I feel I can understand them better. You can reason about them and they are easier to optimize for very specific workloads.
So why aren't we using them? Likely because we know Linux so well and we've invested a lot in it. It runs everywhere and is extremely well supported. Bringing a new operating system to market is challenging, bringing a new operating system with a entirely different architecture is even harder. Even if it, on a purely technical level, could yield better results.
Another performance benefit (unsurprising in highsight) comes from removing KPTI and similar Spectre mitigations. These have really made system calls in regular kernels expensive.
On the other hand if you run only one application on your VM you can just disable them, because one you have access to the userspace application there is nothing else on the machine to steal via side channel attacks.
Absolutely. As of course you know but for the benefit of others reading this, Red Hat [we both work there] is concurrently looking at many different approaches (straight containers, Kata, restructuring QEMU, optimizing the kernel, unikernel Linux, and probably half a dozen others I've forgotten). I doubt that any single approach will be always better.
Yeah I’m kind of amazed they don’t start out with explaining this. Usually there is at least a one-line explanation.
From Wikipedia:
“A unikernel is a specialised, single address space machine image constructed by using library operating systems. A developer selects, from a modular stack, the minimal set of libraries which correspond to the OS constructs required for their application to run. These libraries are then compiled with the application and configuration code to build sealed, fixed-purpose images (unikernels) which run directly on a hypervisor or hardware without an intervening OS such as Linux or Windows.”
> There has been a resurgence of research sys-tems exploring the idea of the libraryOS, ora unikernel,a model where target application is linked with a special-ized kernel and deployed directly on hardware, virtual orphysical
Third paragraph
> The unikernel is a cloud-era handle for the classic systemstechnique of linking an application with a library of oper-ating system components (including memory management,scheduler, network stack and device drivers) into a singleflat address space, creating standalone binary image that isbootable directly on (virtual) hardware [22]. The advantageof this approach is that kernel functionality can be special-ized to fit the needs of the target application to increasethe performance of the application or to support it within ahighly restricted execution domain.
Whether it's good depends on what you're doing. UKL will[1] allow you to link a regular server application to Linux and then run that single binary on baremetal or in a hypervisor, and give you a decent performance boost over running the application on top of a normal kernel. How much of a performance boost depends a great deal on the program, almost everything will be a few percent faster, and some applications a lot more.
[1] I'm using the future tense here because although we do run real programs with it today there's still a bunch of development work to do before it works smoothly. The code is: https://github.com/unikernelLinux
As I've always understood it, it's not just performance but also security: there's a lot less code running with your code which cuts the surface area for bugs and thus security holes.
As the program and kernel run in a single address space, yes there is no separation from your application corrupting parts of the kernel.
I'm not very convinced about the security story around unikernels, but for balance the other side of the argument is that there's much less code around in a unikernel - no shell, no command line tools at all, no compilers or interpreters, just the code required to run the program and talk to the hardware (real or virtual).
The typical problem is that you end up distributing (eg) Apache 2.4.99 compiled for Unikernel on x86-64 via Red Hat Network to a million customers and they're all running the same binary. ASLR helps here ...
Tell me if I am wrong, but is it always true though? Unikernel libraries definitely are largely not as proven as Linux kernel. Then how is unikernel secure than Linux system call?
