Comment by avsm | Hacker News Reader

Comment by avsm | Hacker News Reader

Parent Full thread

Unikernels are a little different from Ethos. What unikernels need is a library interface to any underlying operating system, as opposed to a conventional syscall style interface that dynamically calls into a different privilege level. This lets the developer supply an appropriate set of "OS libraries" that fill in the functionality needed by the application, and no more, and for this to be resolved at application build time instead of execution time.

This implies that unikernels still need to have an underlying OS to drive their logic. The specific choice is wonderfully flexible though: right now we have numerous Xen-based unikernels, and via the Rump Kernel project MirageOS now also boots on KVM and bare metal targets as well.

Ethos has an interesting capability and crypto model that unikernels could map their distributed communication primitives too as well. In this world, the name resolution libraries used by unikernels could use CurveCP (or whatever equivalent version Ethos provides), and provide a multi-tenant, fine-grained capability-based, runtime for dust clouds of unikernels.

> "This implies that unikernels still need to have an underlying OS to drive their logic."

From the Ethos homepage...

> "The solution to both of these problems is Virtual Machines (VMs). Since VMs allow multiple OS to run on a computer, it is no longer necessary to choose one OS; multiple OSs can be used simultaneously. Hence, one significant application can justify running an OS. Second, the VM provides an abstract hardware architecture which is far simpler then the vast variety of computers extant. The drivers for the real hardware are provided by the VM. We are using Xen as our VM because we believe it is a good security architecture on which to build an OS."

So the plan is to run on baremetal hypervisors like Xen, just like MirageOS and the rest.

> "Ethos has an interesting capability and crypto model that unikernels could map their distributed communication primitives too as well."

If that's the main aim, then I don't see why they don't build their capability/crypto model into one of the unikernel OSes, specifically one of those that has the strong type safety and process isolation they are also aiming for. I don't see what they gain from having a custom OS requirement when a lot of the groundwork has already been done for them.

> If that's the main aim, then I don't see why they don't build their capability/crypto model into one of the unikernel OSes, specifically one of those that has the strong type safety and process isolation they are also aiming for.

They seem to be doing just fine with their current efforts, from which really interesting things like the MinimalT protocol has emerged. If I have one frustration, it's that they haven't released a reference implementation of it. I had a f2f conversation with DJB at Real World Crypto a few months ago and the explanation was completely reasonable: they are still working on cleaning it up and making it suitable for external consumption. I still want it today though :-)

David Sheets did some work on rebuilding portions of the protocol in MirageOS: https://github.com/dsheets/ocaml-dnscurve . This level of interproject coupling is just fine by me -- the whole point of library OSs is that we can pick'n'mix these things much more easily over the years, and that's working out fine.

> "David Sheets did some work on rebuilding portions of the protocol in MirageOS: https://github.com/dsheets/ocaml-dnscurve . This level of interproject coupling is just fine by me -- the whole point of library OSs is that we can pick'n'mix these things much more easily over the years, and that's working out fine."

Yes, collaborating in that way seems like a good approach.

Reply on news.ycombinator.com