What is a unikernel and why it's good?
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.
Being actually different is one of the few things that gives someone a reason to look twice at the new system.
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.”
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.
And second chapter.
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
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).
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?
Instead of installing an OS and installing your app on that OS, the OS is a library you use to talk to the hardware.
It's good for two reasons.
First security, if you only use the HDD and network, you don't have to include code for display or mouse etc. which could be a security risk.
Second, it's faster, because you don't have to do syscalls, since your app IS the OS, syscalls don't need to get out of userspace.