Unikernels: The Next Stage of Linux’s Dominance (2019)

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.

The makers of top-performing NICs have been quite good at providing direct user-space access to their hardware, typically by exposing a ring buffer in shared memory, and maybe mapping device registers too, so that the process on the isolated core never does another system call until shutdown weeks later.

It is some hassle to get customers to add boot flags (isolcpus=, nohz_full, rcu_nocbs=, rcu_nocb_poll, hugepages=, etc.), and to put any mapped files in /dev/shm or /dev/hugepages so the kernel won't invent excuses to block the procees, and to direct irqs to other cores; but unikernel setup is probably not simpler.

So, I'm not sure what a unikernel would get me. Portability, or independence from proprietary drivers?

• Added a new kernel configuration option to allow theuser to select if he/she wants to compile the Linux kernel as UKL.

• Added a call to an undefined symbol (protected by an #ifdef) that can be used to invoke application code rather than creating the first userspace process.

• Created a small UKL library which has stubs for syscalls. These stubs hide the details of invoking the required kernel functionality now that the regular interface (i.e.,the syscall instruction) is no longer used.

• Changed glibc so that instead of making syscalls into the kernel, it makes function calls into UKL library.

• Changed the kernel linker script to define new segments such as thread local storage (TLS) segments which are present in application ELF binaries.

• Added a small amount of initialization code before invoking the application to replace initialization normally done by user level code, e.g., for network inter-face initialization.

• Modified the kernel linking stage to include the application code, glibc and UKL library to create a single binary.

Basically, I think the idea is you get all the linux syscalls (+ filesystems... + network stack... + hardware support... + everything) for 'free'. Sure you'll have a pretty large binary, but you won't have to write anything.

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?