Difference between revisions of "Unikernels"
(Boxfuse isn't a unikernel in the sense that the others are (single-address space, library OS). Hence doesn't belong on this list.)
(add cat unikernels)
|Line 43:||Line 43:|
Revision as of 11:31, 24 June 2015
Xen Project has been at the forefront of the birth of Unikernels (or Cloud Operating Systems): specialized lightweight operating systems which are only intended to be used within a Virtual Machine. These Unikernels may become the core of a new form of cloud, where a single hypervisor instance can support hundreds or even thousands of VMs.
What is a Unikernel?
Normally, a hypervisor loads a Virtual Machine with a fully functional operating system, like some flavor of Linux, Windows, or one of the BSDs. These operating systems were designed to be run on hardware, so they have all the complexity needed for a variety of hardware drivers from an assortment of vendors with different design concepts. These operating systems are also intended to be multi-user, multi-process, and multi-purpose. They are designed to be everything for everyone, so they are necessarily complex and large.
A Unikernel, on the other hand, is (generally) single-purpose. It is not designed to run on hardware, and so lacks the bloat and complexity of drivers. It is not meant to be multi-user or multi-process, so it can focus on creating a single thread of code which runs one application, and one application only. Most are not multi-purpose, as the target is to create a single payload that a particular instance will execute (OSv is an exception). Thanks to this single-minded design, the Unikernel is small, lightweight, and quick.
What do Unikernels Provide?
Unikernels normally generate a singular runtime environment meant to enable single applications built solely with that environment. Generally, this environment lacks the ability to spawn subprocesses, execute shell commands, create multiple threads, or fork processes. Instead, they provide a pure incarnation of the language runtime targetted, be it OCaml, Haskell, Java, Erlang, or some other environment.
Unikernels Versus Linux Containers
Much has been made recently of the advantages of Linux Container solutions over traditional VMs. It is said by container advocates that their lightweight memory footprint, quick boot time, and ease of packaging makes containers the future of virtualization. While these aspects of containers are certainly notable, they do not spell the end of the world of the hypervisor. In fact, Unikernels may reduce the long-term usefulness of containers.
Unikernels facilitate the very same desirable attributes described by the container proponents, with the addition of an absolutely splendid security story which few other solutions can match.
What About Security?
Unikernels offer an excellent security scenario. The attack surface for these instances are quite small, as they lack the variety of functions (and, therefore, the potential flaws to be exploited) provided by standard operating systems, as well as the tools used to exploit them (there are no shells, no utilities, and no variety of programs to be leveraged if a flaw is located). Because of the design of Unikernels, it is hard to find security flaws, and even harder to find ways to exploit them.
Furthermore, many Unikernels (OSv is an exception to this) are used to compile their payloads. Rather than having a uniform operating layer which is the same for each application stack, most unikernels actually compile into the application layer, resulting in an optimized piece of code which provides exactly what the application needs in a unique footprint. This means that the attack surface on, say, a Mirage OS webserver will not be the same as that of a Mirage OS DNS server. Each operating layer will be unique, meaning that the attack surfaces of the operating layer will be different for each. An operating layer exploit which might penetrate one may not be successful at all on the other. This increases security tremendously by design.
How do Unikernels Interact with Xen Project?
Being Open Source, Xen Project can both create its own Unikernel and leverage those developed by others. In fact, Xen Project runs the gamut, as it works on its own Unikernel (MirageOS), is the target engine for some others (like LING), and can use entirely separate efforts (like HaLVM or OSv).
In addition, Xen Project has taken a proactive position in enabling the use of Unikernels. An example of this is the "3000 Domains" experiment, in which large numbers of VMs were attempted to be loaded on a single hypervisor host. As a result, modifications were made to the hypervisor code base to enable this concept. Watch the Video.
The following Unikernels are currently of interest to the Xen Project (though the list is not exhaustive):
- MirageOS, an official incubator effort of Xen Project, employs an OCaml-based kernel. See the Presentation as well as the Mirage_architecture page. Also, see the documents from the Mirage Category.
- LING (formerly Erlang on Xen) creates an Erlang runtime environment. See the Presentation.
- HaLVM, the Haskell Lightweight Virtual Machine from Galois, allows you to run Haskell programs. See the Presentation.
- OSv from Cloudius Systems produces a Java environment. See the Presentation.
- ClickOS from NEC labs a high-performance unikernel producing network devices. See their webpage.
- Rumpkernels from the NetBSD community provide a small platform with driver support as the base for unikernel work. See their write-up on how it compares to other Unikernels.
Because of the dynamic state of this technology, this list will likely be in constant flux for the next few years.