Q&A with NanoVMs Founder, Ian Eyberg
Earlier this year, Gula Tech Adventures invested in NanoVMs (formerly Defer Panic) as part of our overall focus on web and application security. I caught up with the founder of NanoVMs, Ian Eyberg, and asked him a variety of questions about the emerging space of “unikernels”.
Most readers will be familiar with virtual machines, containers and serverless security, but what is a unikernel?
A unikernel is simply a single process application and the bits of the operating system it needs boiled down to a small secure light-weight virtual machine.
How resistant do they make applications from attack and if one were
inadvertently compromised, can you move laterally to other
unikernels?
Unikernels are highly resistant to remote code execution attacks, more specifically shell code exploits. The entire concept of a shell is foreign to a unikernel. They don’t exist and the system calls to call them into existence don’t exist.
What makes unikernels really shine, however, is that lateral movement after compromising a host becomes incredibly difficult. Typically an attacker will gain a foothold on one system — even a system without root and since they have “trusted” network access it makes it much easier to attack other internal
systems. Unikernels being single process systems just don’t enable these style of attacks.
For example suppose I’d like to steal a mysql database. I might, after getting a shell on a compromised system download the mysql client and then start brute-forcing logins/passwords or hopefully I popped a shell on a webserver and I can sniff the traffic with sysdig or tcpdump for the same or maybe I got lucky and found something hardcoded in a config script.
Well in the case of a unikernel— sysdig, tcpdump, and mysql-client are not installed and you can’t just “apt-get install” them either. You have to bring that with your exploit. And as we all know shellcode exploits tend to be small for a variety of reasons. Even running a tool like tcpdump typically involves a chain of piping to various other tools and pipes by definition entail other processes which unikernels simply do not support. To take it further even a simple cat /etc/hosts or grep of /var/log/nginx/access.log simply won’t work — once again they are separate processes.
How much performance improvement do you get for applications compared to containers or virtual machines?
To be honest we have spent very little time benchmarking, however there are a few key considerations. First off, some unikernels can boot fast — in 5ms. That’s slightly slower than fork itself and multiple orders of magnitude faster than docker. Second, many applications can run faster than even when provisioned on bare metal. The reason is simple — it’s a single process system and a lot of context switching goes out of the window. Think about every single packet that comes into the server.
Every single disk write that hits the server — that’s a a round-trip from kernel-land to user-land and back and that concept simply doesn’t exist in unikernels. Some people who have not used unikernels will bring up security implications because of this reason but it doesn’t matter cause that would imply that there were multiple programs running under the same kernel and that’s not the case.
Having said that — we expect a lot more performance improvements in the future as we take advantage of unikernel characteristics.
I speak with many organizations who have Windows .Net components in their web stacks and they’ve been left out of the devops movement. What about .Net applications?:
Great question — we talked to quite a few of those as well so we went back to the lab and we can now run .Net applications as unikernels — not just those but other popular proprietary software as well. We can literally shift and lift your legacy applications into rock solid infrastructure.
Where can readers go to learn more?:
