4 ms·

I'm ambivalent about unikernels. On the one hand, I applaud the effort to simplify the software stack and promote the use of a safe language all the way down.

I'm ambivalent about unikernels. On the one hand, I applaud the effort to simplify the software stack and promote the use of a safe language all the way down. On the other hand, I wonder if running lots of small OS kernels on a hypervisor is the best way to do this. Might it be better to simply run each application as a process on a conventional OS kernel, perhaps with containers for isolation? This post from Brendan Gregg argues pretty convincingly that virtualization imposes a substantial performance penalty: http://dtrace.org/blogs/brendan/2013/01/11/virtualization-performance-zones-kvm-xen/ http://dtrace.org/blogs/brendan/2013/01/11/virtualization-pe... I understand that a key premise of the unikernel approach is that the millions of lines of C code in a conventional OS kernel like Linux are a problem. But in any real Xen deployment I'm aware of, Linux is running in dom0 anyway. So why not take Xen out of the picture and run each application as a process in a container on Linux, using raw sockets so you can still implement the TCP/IP stack in OCaml? For deployments on Amazon, I guess the unikernel approach has the advantage that you're running on top of Xen anyway, so you're eliminating a layer. But for running on one's own servers or an ARM-based device like the Cubieboard2, it seems to me that Xen is just complicating things. I guess one benefit of Mirage's use of the OCaml module system is that we can experiment with multiple deployment approaches and use whichever one works best in practice. So there's nothing stopping me from running a Mirage application on Linux with raw sockets rather than as a Xen unikernel.

avsm 12y ago
> I guess one benefit of Mirage's use of the OCaml module system is that we can experiment with multiple deployment approaches and use whichever one works best in practice. So there's nothing stopping me from running a Mirage application on Linux with raw sockets rather than as a Xen unikernel. That insight is spot on. The reason we're spending so much time on the clean-slate MirageOS stack is that it's a codebase that will last the test of time. It makes it possible to build code that's more future proof against changes in deployment environments. It's Xen/KVM/vSphere today, JavaScript and Docker tomorrow, and probably Unix sockets forever, all from the same codebase. Our use of OCaml + functional programming also had a good trajectory with practical formal verification, so the future of the stack is exciting.
justincormack 12y ago
If you run a unikernel under an OS you can do very aggressive sandboxing (eg seccomp type 2 under Linux), as it does not really use any of the OS facilities, eg just read and write a raw socket file descriptor. So you end up with a pretty decent userspace security model, and small statically linked elf files as your container format. I am currently working on this, should be usefully usable soon.
amirmc 12y ago
> "But in any real Xen deployment I'm aware of, Linux is running in dom0 anyway." It's still separated from the the domUs via the hypervisor. So an exploit in one place isn't easy to escalate into a breach of the whole system. This is a security benefit. From the rest of your comment, I get the impression that you care more for speed/convenience (even the post you link to is about speed). That's a perfectly reasonable position and the examples you provide are perfectly valid for different threat models (i.e. running your own trusted code on your own trusted server). Deployments to the cloud (or large scale teams) do need to consider different threat models. As avsm points out in a sibling comment, you can target numerous back-ends with MirageOS -- meaning that you can compose a system that suits your particular needs.

avsm 12y ago

> I guess one benefit of Mirage's use of the OCaml module system is that we can experiment with multiple deployment approaches and use whichever one works best in practice. So there's nothing stopping me from running a Mirage application on Linux with raw sockets rather than as a Xen unikernel. That insight is spot on. The reason we're spending so much time on the clean-slate MirageOS stack is that it's a codebase that will last the test of time. It makes it possible to build code that's more future proof against changes in deployment environments. It's Xen/KVM/vSphere today, JavaScript and Docker tomorrow, and probably Unix sockets forever, all from the same codebase. Our use of OCaml + functional programming also had a good trajectory with practical formal verification, so the future of the stack is exciting.

justincormack 12y ago

If you run a unikernel under an OS you can do very aggressive sandboxing (eg seccomp type 2 under Linux), as it does not really use any of the OS facilities, eg just read and write a raw socket file descriptor. So you end up with a pretty decent userspace security model, and small statically linked elf files as your container format. I am currently working on this, should be usefully usable soon.

amirmc 12y ago

> "But in any real Xen deployment I'm aware of, Linux is running in dom0 anyway." It's still separated from the the domUs via the hypervisor. So an exploit in one place isn't easy to escalate into a breach of the whole system. This is a security benefit. From the rest of your comment, I get the impression that you care more for speed/convenience (even the post you link to is about speed). That's a perfectly reasonable position and the examples you provide are perfectly valid for different threat models (i.e. running your own trusted code on your own trusted server). Deployments to the cloud (or large scale teams) do need to consider different threat models. As avsm points out in a sibling comment, you can target numerous back-ends with MirageOS -- meaning that you can compose a system that suits your particular needs.