Unikernels – A viable Cloud Solution – Glue Architectures, Inc.

In our article about the AWS Firecracker MicroVM platform, we touched upon the concept of Unikernels. At a high level, a Unikernel is an absolutely minimal set of kernel libraries to boot a specific process. They promise additional security by minimizing the vectors through which a rogue actor could take control of the machine. In this article, we’ll touch upon a bit of the technology behind Unikernels, some of the latest tools being developed to implement them, and explore whether existing cloud services could be made even more secure by incorporating them into their architectures.

What IS a Unikernel?

Loosely speaking – a unikernel is a highly specialized machine image constructed using a library operating system. The developer of the image typically selects only those OS libraries absolutely necessary to run the program they’re developing the machine image for. The libraries and the program are then compiled together into a sealed construct that can be run upon bare metal or (more reasonably) a compatible Hypervisor. Unikernel images are, in this way, not typically what one would think of as a usable machine as they are even more singular in their purpose than even MicroVMs as they are custom crafted for a single application and can do literally nothing outside of the purview of that application or its dependencies.

Library Operating Systems, what are those?

Library operating systems are specialty constructs where the components that comprise the kernel one typically associates with an OS are provided as a series of importable modules available to programmers. The simultaneous advantage and disadvantage of library OSes is that they typically utilize a single shared address space for the operation of their constituent modules. This can result in some speed-ups over traditional kernel based OSes by allowing direct access to hardware, and removing the need to transfer memory between kernel space and user space for the operation of applications while simultaneously making assuring the strong isolation of multiple applications from one another during operation difficult. The advantage from operational speed up is somewhat blunted in practice due to advances in kernel based operating systems (such as zero-copy device drivers). An additional downside is that rapid changes in hardware may require the constant maintenance or addition of device driver libraries into the OS’ module-set to keep it operational on new hardware.

What are Library Operating Systems even good for?

Two advances in the relatively recent history of computation are making way for library operating systems to exit the realm of niche usefulness. For one, the general adoption of microservice architecture for delivering specific components of a system as isolated services transform the library OS’ natural inclination to run a single process into a strength. For the other, modern hypervisors allow sufficient hardware virtualization to limit the difficulties presented by rapidly changing hardware by hoisting the burden of the actual hardware communication onto the hypervisor. These two specifics dovetail together into deploying one’s microservices as unikernels – isolating the process delivering the microservice onto a virtual machine that is providing nothing more than precisely what that microservice needs to run.

What could one gain by utilizing a Unikernel Architecture?

In summary, there is the potential to make gains in size, speed, and security. Size follows logically from the nature of the unikernel building process as a unikernel contains only the code necessary to run the process. At least one study [4] working with a TLS protocol into Xen unikernels found that they were 4% the size of an equivalent Linux/OpenSSL stack.

Given the ability to achieve such codebase size reductions within many unikernels, some increases in operational speed can follow along from that. Naturally, part of the claims to speed increase arise from the simple fact that there is just that much less to boot before there’s an operational system running. Beyond that, further operations could potentially see performance gain because having such a focused and unwavering system architecture enables a sort of whole system optimization that is simply unavailable when working with a monolithic OS.

Finally, the tightly controlled application base allows additional security by enabling a reduction of attack profile that’s also unavailable when working with a monolithic OS. Fundamentally, including only those modules that are necessary to run the associated application reduces the potential attack profile of the overall system. Beyond this, by nature of their construction, unikernels can have their contents sealed by rendering their page tables immutable once the unikernel has been booted. If one is willing to recompile the unikernel with each deployment (again, not necessarily a difficulty given the small package size), one can take this a step further randomizing the address space used with each unique instance of a given unikernel.

Where to get started

If you’re interested in learning more about Unikernels, there are a few modern projects to begin exploring to learn more. OSv from Cloudius systems is a project being written to be compatible with multiple hypervisor projects, including AWS Firecracker. Their GitHub page also provides somewhat decent instructions on how to set up one’s development environment and get started building your own Unikernels. MirageOS is another project with a long history built upon OCaml to allow for the building of Unikernels that can be run on Xen or KVM based Hypervisors. These are just a couple of strong examples, the Wikipedia page linked below has a long list of other unikernel projects worth exploring, just be aware that this will be a journey into the weeds filled with intellectual challenges. Enjoy!

References

If your software solution would benefit from Unikernel design (as esoteric as they are), or anything else that you’ve observed in our MicroVM and FaaS article series – please don’t hesitate to reach out to us via contact@gluearchitectures.com. Our architecture experts are always happy to be of assistance, and would be glad to assist bringing your designs to fruition.