First, there was the virtual machine. Then came the container. Now, welcome to the unikernel, the latest initiative for atomising computing.
As everyone know, splitting the atom is a difficult job, so the ultimate computing atom ought to be safe from attacks. Is the unikernel that computing atom?
If you haven’t yet met the unikernel, here’s a super quick definition. It’s a package of what you need and only what you need to run a given application.
It contains the app itself, any middleware, libraries and kernel, including requisite device drivers. It differs from a virtual machine, which bundles up everything in terms of the operating system, etc., whether you need it or not. It also differs from a container, which bundles up the things you need, but minus the operating system.
This handy VM-container-unikernel graphic is well worth a thousand words. The accompanying article also tells you what the unikernel’s single address space is about, in simple terms too (sigh of relief!).
So, why should this be good news for IT security? Proponents of unikernels point to the sealed infrastructure of the unikernel with accompanying prevention of data loss and zero-day threats, not to mention avoidance of ransomware and bot infections.
“No forking, no users, no shells, only one process” is the magic formula for nipping most current security attacks in the bud.
That said, a vigorous debate is also raging about the relevance of unikernels in general computing terms. Supporters say that few or no system calls, direct hardware access and very fast boot times make unikernels the strategic direction of choice.
Others state that the supposed advantages of small size, raw performance, and restricted attack surface are negated or non-existent.
Yet others suggest that unikernels might have a role to play in the domain of specialised software appliances. Will IT security alone swing things in favour of the unikernel? Wait and see!