Introduction
I've been following the unikernel area for years and I really liked the idea, but I was unconvinced about the possibility of the wide-scale adoption of the technology.
The cost was just too high. It required you to forget everything you knew, to drop all the existing code on the floor, to rewrite all your applcations and tools and start anew. (I am exaggerating, but not by much.) If microkernels never made it, the unikernels are not going to either.
Whatever the benefits, the cost was prohibitive.
Unikernels as processes
Recent "Unikernels as Processes" paper by Koller, Lucina, Prakash and Williams (free download) turns the situation on its head. It proposes to run unikernels as good old boring OS processes. The idea is that most of the stack that's currently in the kernel will be in libraries linked directly to the application. Only few calls would cross the user/kernel boundary.
One-click security
Assuming that libraries implementing POSIX APIs are available (and they are; see e.g. rumpkernel) it should be possible to take your existing application and just recompile it as a unikernel. The application would work as it did before, but it would use only a few system calls.
So, on one hand, any vulnerability in the kernel outside of those few functions won't affect your application.
On the other hand, any vulnerability in, say, TCP or filesystem implementation would compromise your application — but the problem would be at the same time kept at bay by separation between OS processes (different address spaces etc.) It wouldn't result in compromising other applications running on the same machine.
Now think about that from economic point of view.
Vendors are finally forced to take security seriously. But all the options they face are rather unpalatable.
They can keep the status quo and pray that nobody bothers to hack them.
Or they have to fix security flaws which, likely, means security audit of the entire stack and then rewriting most of the legacy code. That's prohibitively expensive. Only few, if any, companies are able to afford that.
Unikernels-as-processes model is no panacea, it won't fix a SQL-injection vulnerability for you, but it addresses a broad class of highly dangerous security flaws (for estimates, see, for example, this paper).
More importantly though, it's a once-click solution! It does improve security at close to zero cost.
That, in turn, gives business people an easy way out from this uncomfortable dead-end situation.
Based on the above, my guess is that the technology, once it is truly provides a one-click experience, will face a quick and widespread adoption.
Portability
Compared to the one-click security, portability is just a minor selling point, but still:
As the moment, it's not trivial to port applications even between POSIX-compliant OSes, but porting to Windows is a pain in the ass, plain and simple.
Unikernels-as-processes model has an interface between the OS and the application consisting of a single digit number of functions. Once those few functions are available and work the same on all mainstream OSes an application written on one OS would just run on a different OS. (And I am not even mentioning the possibility of running it directly under the hypervisor or on bare metal.)
Keep your tools
One of the things that hindered the adoption of unikernels was that they broke the existing tools and processes.
Typical question: If I am going to run my application as unikernel, how the hell am I going to debug it?
And while the debugger is the tool that comes to mind first the same problem applies for any tool that assumes that the application is a standard executable and that it runs as an standard OS process. That will likely break most build and deployment toolchains. It can break control interfaces, monitoring and who knows what.
With unikernels-as-processes it is no longer a problem. The application IS a standard executable. And it DOES run as a standard OS process. Only minor changes to tools and processes are needed.
In fact, the switch can even improve the tools. Consider debugging an application. Currently, you stop at the kernel boundary. There's no way to step into the implementation of, say, TCP protocol. If, on the other hand, TCP implementation is just a library linked into your application, then sure, step into it, place breakpoints inside it, do whatever you want.
Next productivity boom
When open source infrastructure became widely adopted we have experienced a productivity boom. Instead of waiting for years until the commercial vendor implemented the feature you wanted, you could suddenly choose a free solution that aligned with your needs. And you could fix any broken or missing stuff yourself.
However, we've seen only a dampened-down version of this revolution in the operating systems space.
Sure, you can fork Linux kernel and implement the feature you need. But then you are faced with the dilemma of either maintaining the fork yourself or upstreaming the change to the mainline kernel.
In the former case, you are doomed to maintain the fork forever. That's annoying and costly. Moreover, you have to ask the users of your application to run your fork of the operating system. That's not going to make them happy. They'll imagine you going bankrupt next year and them having to maintain a custom fork of the kernel for the next decade. They will politely back down.
If, on the other hand, you choose to upstream the change, you'll have to fight Linus Torvalds to get your patch in. If he doesn't like it, you are out of luck and back to the previous option. Even if you manage to get the patch in, it'll take years till everyone updates their OS to include your feature. Do you have a customer running RHEL 5 with kernel from 2007? Oops! Not going to work! You will end up with time-to-market of 10 years and that's guaranteed to kill almost any business plan.
With unikernels-as-processes model, the problem disappears.
You want to tweak IP protocol implementation? Yeah, sure. Find an existing IP library on GitHub, patch it as needed and link it to your application. Done. Anyone can run it on their off-the-shelf OS.
October 23th, 2018
"Giving every process complete access to the disk block device"
Nothing could possibly go wrong here
via: https://www.reddit.com/r/programming/comments/9qo57y/unikernels_no_longer_an_academic_exercise/
which has other criticism in stock as well
I am not an unikernel expert. I was just reporting on stuff that I think is cool.
That being said, my understanding it that "the block device" is really just an API ("read block", "write block"). What's actually behind it, whether its a real physical disk or some kind of virtualized thing, depends on what you are running on top of (i.e. who implements that API).
Very much the same applies to the network interfaces. In that case the API is "send L2 packet", "receive L2 packet".
You don't need to give raw disk access to the entire block device. You can give it access to a disk image. That's no different from any other VM in that regard.
Worth noting there's also a set of ready-made packages for rumprun for the lazy https://github.com/rumpkernel/rumprun-packages
the Exokernel presented an interface for sharing block access safely to userspace 20+ years ago.
The exokernel's "library OS" approach to having each process be its own OS was an explicit inspiration for unikernels. Unikernels as Processes is the Exokernel come full circle again.
honestly a bit shocking this got published without at least citing such foundational related work. the better critique is what have they done that goes beyond it, if anything.
GENODE OS FRAMEWORK http://genode.org is a system in development for over a decade now that is quite compatible with unikernel applications. the biggest challenge to adapting existing system design to a unikernel with hyper visor approach is that the user environment requires rich, deeply integrated interaction on multiple levels to make user environment paradigms useful, and emulating/implementing this in a secure setup where everything has been abstracted to interfaces is somewhat difficult and requires a lot of work. just a thiufht
This supports JVM and golang among other languages, with huge performance gains demonstrated
http://www.vorteil.io/#downloads
You hooked me up on unikernels a while ago with a tweet of yours on the subject.
Now, I am looking at using the Agda programming language to write mirage unikernels, in order to use Temporal Logic of Actions and prove temporal properties of distributed systems of unikernels.
Are you still working on nanomsg? What's nanomsg's final goal?
No, nanomsg is now developed by Garrett D'Amore.
Is a docker container not very much like a unikernel on a more coarse grained level?
Thanks for sharing informative article , i recently completed my course in RPA Training in Marathahalli. I got selected in reputed company .Am glad to share this happy moment with all ,thank you.
https://rpaminds.in/rpa-training-in-marathahalli.php
Post preview:
Close preview