Enable unprecedented levels of automation and agility with cloud computing solutions.
What is a unikernel, and why does it matter?
Virtual machines rule, and containers are enormously popular among DevOps. In contrast, unikernels, which are another way to maximize productivity from server hardware, have yet to catch fire. But unikernel supporters encourage other IT shops to embrace this novel approach to make the most from server hardware and cloud computing.
New to the subject? You aren’t alone. Let's take a closer look at unikernels, along with their strengths and weaknesses.
The goal of unikernels is to restructure entire VMs—including all kernel and userspace code—into more modular components that are flexible, secure, and reusable, in the style of a library operating system, according to Anil Madhavapeddy and David J. Scott, who describe them in a Communications of the ACM article. A library operating system is an absolutely bare-bones operating system. It has the minimal number of libraries needed to run a specific application. Library operating systems date back to the mid-1990s, when they were used in academic operating systems such as MIT Exokernel and Nemesis.
Unikernels are often spoken of as if they are operating systems. More to the point, unikernels actually are specialized, single-address-space machine images made from library operating systems. Unikernels are built from high-level languages that are compiled into application machine images.
Within the image's userspace, a developer places the software the application needs to run and nothing else. Drivers, I/O routines, support library functions—everything you expect in an operating system—either are eliminated or incorporated into the unikernel executable. By shrinking down the operating system to essential functions and libraries, unikernels take up minimal resources.
Fast and secure—what’s not to like?
Unikernel proponents argue that operations that pass over that boundary are faster with a unikernel because the system avoids a context switch across the user/operating system kernel boundary. That means the unikernel runs in the microprocessor’s privileged mode as much as possible. On an x86 processor, software runs in ring zero instead of ring three, where user applications typically run.
One benefit: Unikernels have tiny attack surfaces compared with VMs and containers. Most of the usual attack surfaces are absent, including unused drivers, unnecessary I/O routines, and unneeded support libraries.
Because they load only the libraries the application requires, unikernels boot quickly. In addition, with their minimal overhead and memory requirements, they can challenge containers for making the most from available system resources. What paravirtualization brings to the table for unikernels are virtualized disk and network drivers; interrupts and timers; emulated motherboard and legacy boot; and privileged instructions and page tables. This means unikernels need not bother with the code for these functions.
Unikernels can run either on bare metal or a hypervisor. They tend to work well on hypervisors, which use paravirtualization, such as VMware Virtual Machine Interface and Oracle VirtualBox. However, Xen has worked (arguably) hardest to bring unikernels from the lab to business.
Not a panacea
That's the good news. The bad news is many tech experts believe unikernels are too much trouble.
At the recent Open Source Summit in Los Angeles, Joshua Woods, head of documentation for CoreOS, a container and Kubernetes company, spent some time criticizing unikernels. Woods said, "The concept [of unikernels] hasn't learned some of the lessons of bare-metal virtualization or containers. Unikernel asks people to build their own or use a slow paravirtualization network service.”
For example, said Woods, the well-tested Linux stack can run on any hardware. With unikernels, you must do a great deal of low-level programming instead of relying on well-known and proven operating system mechanisms. Woods added, "With unikernels, I'd return to square zero in building my applications. I want to solve my users’ applications problems, not worry about low-level problems."
Bryan Cantrill, chief technology officer at virtualization and cloud company Joyent, took it further. He declared, "Unikernels are unfit for production." Cantrill, a well-known systems software programmer, said, "Unikernels very much rely on hardware virtualization," thus resulting in an inexorable performance tax. “By having the system that can actually see the hardware (namely, the hypervisor) isolated from the system that can actually see the application (the guest operating system), efficiencies are lost with respect to hardware utilization (e.g., DRAM, NICs, CPUs, I/O) that no amount of willpower and brute force can make up." In other words, for Cantrill, the speed advantages that unikernels gain from running in ring zero are lost due to the paravirtualization costs.
Cantrill also doesn't buy the argument that unikernels are more secure. “Yes, unikernels often run less software (and thus may have less attack surface),” he said. “But there is nothing about unikernels in principle that leads to less software. And yes, unikernels often run new or different software (and are therefore not vulnerable to the OpenSSL vulnerability of the week), but this security-through-obscurity argument could be made for running any new, abstruse system.
"The security arguments also seem to whistle past the protection boundary that unikernels very much depend on: the protection boundary between guest operating systems afforded by the underlying hypervisor,” Cantrill continued. “Hypervisor vulnerabilities emphatically exist; one cannot play up Linux kernel vulnerabilities as a silent menace while simultaneously dismissing hypervisor vulnerabilities as imaginary. To the contrary, by depriving application developers of the tools of a user protection boundary, the principle of least privilege is violated. Any vulnerability in an application tautologically roots the unikernel. In the world of container-based deployment, this takes a thorny problem—secret management—and makes it much nastier (and with much higher stakes). At best, unikernels amount to security theater, and at worst, a security nightmare.”
On the other hand…
Unikernel expert and Docker programmer Amir Chaudhry disagrees. At the Open Source Summit, Chaudhry responded to Cantrill’s and Wood’s criticism, saying, "Unikernels and containers sit on the same continuum. Containers help you package up your application and share a kernel across the containers. And that makes it easy for me to develop essentially a great application and deploy it. But you can think about the progression from that, from a full traditional operating system to containerized applications and what comes next, what is further along on that spectrum of specialization. And that's where unikernels sit. It makes sense for unikernel and Docker to work together."
"There are two broad approaches to creating library operating systems,” Chaudhry said: legacy and clean slate. “The legacy approach is to say, ‘Let's take existing code, for example, Rump Kernels, which uses NetBSD.’ So you break up NetBSD, and make some of its components available as userspace libraries.” For example, you can use a NetBSD TCP stack as code to produce a unikernel. This addresses Woods' concern about forever rebuilding the system library wheel in unikernels.
"The other category is clean slate," said Chaudhry. Building things from scratch is a little bit scary, “but there are lots of benefits to doing so, because you start to benefit from language-specific features." One of those is OCaml, which is used for MirageOS. “There's also Haskell for HaLVM, Erlang, and LING,” he added. You rewrite those operating system components in that language from the ground up. “This process can take a while, and your application code then also has to be in the same language,” Chaudhry acknowledged. But it brings several benefits from optimizations throughout that whole stack. “You can also do away with things like POSIX compliance because you then just present developers with a clean API to use and that's much more pleasant for them to work with," Chaudhry added. He believes unikernels are perfect for software appliances that usually do not require rewriting, such as load balancers and firewalls.
Docker is using these ideas. The Docker client for Mac, for example, runs on a MirageOS unikernel. Although Docker doesn't say Docker's LinuxKit, a set of tools for building a Linux subsystem inside a container, is as a unikernel building kit, its description suggests it: "LinuxKit includes the tooling to allow building custom Linux subsystems that only include exactly the components the runtime platform requires. All system services are containers that can be replaced, and everything that is not required can be removed." That certainly sounds like a unikernel.
Chaudhry also pointed out that one specialized unikernel, Galois' CyberChaff, has become a financial success in its own right. The DARPA-funded CyberChaff creates hundreds or thousands of fake, lightweight network nodes. When a would-be hacker scans the network, the fake nodes are indistinguishable from target nodes. Thus, the hacker is likely to touch a CyberChaff node rather than a real one, slowing down the attack and triggering a sysadmin security alert that an attack is underway.
Woods conceded, "As a platform for trying new things, it's good. If I had a radical new networking idea for a software switch or router, I'd consider a unikernel."
So, while unikernels are very unpopular in some circles, this approach also has its passionate supporters and some useful, real-world implementations. Will they work for you? Look closely at your technology needs before you make a decision.
Unikernels: Lessons for leaders
- Unikernels restructure entire VMs to be specialized, single-address-space machine images made from library operating systems.
- There is considerable controversy over the usefulness of unikernels in real-world deployments.
- Unikernels appear to have a niche in creating specialized software appliances.
This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.