Hacker News Reader

Comment by marcosdumay | Hacker News Reader

I still don't get it.

Yep, unikernels can get away without the security boundary between user and kernel modes... except if you want any security at all in your installation, because at kernel mode people can break out of the container.

They can also get away without process scheduling and IPC, but if you want any multiprocessing on the application, you'll need to bring it either on the kernel or the userland. Ditto for user management.

They can't really get away without device drivers. Ok, except for devices that you won't use, just like any other kernel.

What is that kernel feature that people take away? Or are they just talking about a stripped down Linux without the device drivers (that fit a floppy disk)?

The same applies to the services. What are those services that people gain so much from removing from containers, and why don't people remove them from VMs and real machines too?

View on HN

The advantage comes from unikernels being even more disposable than containers. Your kernel is built with an absolutely tiny number of options. You wouldn't even need things like the console driver, because if a unikernel crashes, you just restart it, with crash logs sent somewhere for analysis. You can remove a lot of your networking stack, because your HTTP server, that only ever speaks http, can get rid of base things like UDP support. You don't need a full-featured filesystem, because things are only written to at compile time. The number of syscalls you expose can equally be tiny. In short, you have an absolutely minuscule kernel.

From there, you can start stripping out other things. You don't need a huge init system because all you're doing is running a single application. Your libc can be made tiny, or removed completely, because you can strip it of all the calls your app doesn't need. You don't need to run an sshd, because there is no shell to get into. You can get rid of PAM because there's no accounts to access or authenticate against.

On real machines and VMs, these things are necessary so you can run tests, do cleanup, etc. Unikernels are centered entirely around the idea that those things are someone else's job, and if needed, can be shouted for across the network.

> because if a unikernel crashes, you just restart it

Because you've stripped out everything that could supply you with any other option.

Because they're just processes with a funky syscall interface that looks a little bit like hardware. Especially if you start comparing paravirtualized drivers and high performance interfaces like Netmap.

The idea is that your security boundary is at the VM. The VM hypervisor presents a virtual CPU; malicious code cannot jump out of the box.

Many common server frameworks build in multiprocessing to the language runtime: Node.js mandates an event-driven callback style, Go has goroutines, etc. So it already exists in userland. Unikernels avoid duplicating that functionality at the kernel level, so the two systems don't fight each other.

The hypervisor proxies device drivers through from the host operating system (running in Dom0) to the guest operating systems.

The idea is to run eg. Node, or Postgres, or memcached on bare metal. So instead of write() trapping into the operating system, it becomes a library function that directly talks to the underlying device driver. The only process the VM runs would be that one application, and you'd rely on the hypervisor to schedule multiple applications on one physical box.

Mildly interesting historical note -- a few years ago I was reading an old paper on operating systems from the 1960s. As I recall, it seemed to refer to a process as a "virtual machine".

(Sadly, I don't remember the title for a citation here.)

Didn't containers just create a sandbox for the code to run? If they get a full VM, what is the difference between containers and old style VMs?

Anyway, I don't have experience on Go or V8 Javascript, but C pthreads, Haskell threads and Python threads all just encapsulate the OS functionality to add some conveniences. Java does come with a complete threading implementation, and gets no lack on criticism because of that. You may get away running Node on a single task kernel, but Postgres will simply refuse to load if it can not fork some processes and talk to them by shared memory. Apache's behavior is similar.

Containers share a kernel, but unikernels run right on the hypervisor. Basically your program is the kernel, and it's the only thing running in the VM.

Oh, thanks.

So unikernels are not about containers, and I've been mixing two different approaches. It makes more sense now.

I'm gonna stretch things a lot but it reminds me of the standalone webserver versus language embedded webservers.

Before you had to rely on say apache for urlrewrite and routing. Now the data and logic has been lifted into languages.

Unikernel frameworks like Mirage either provide all those features, or in the case of drivers, are just targeting virtio/veth/etc. paravirtualized devices offered by the hypervisor. So the domU doesn't have any abstraction to worry about other than just targeting a particular Hypervisor's representation of storage and networking.

Xen provides very basic (but safe) message/event channels between VMs. Basically this becomes your IPC, and the VMs become user processes.

With a new enough CPU with the correct memory virtualization features, xen can scale to many thousands of domUs. And with each domU only taking up slightly more resources than a typical user process, this is a completely reasonable approach.

Again, your Hypervisor becomes the OS which has to worry about the baremetal, and the VMs replace user processes.

I intend to playing with MirageOS seriously myself next year.

Edit: some dependencies in an example MirageOS app: https://mirage.io/wiki/technical-background#ModularOSLibrari...

But if the hypervisor already has process separation, quota management, device drivers, etc. there's no point duplicating it all in the VM.

> They can't really get away without device drivers

I agree with you 100%, but it does make me think. Every Linux installation I've done in the last five or so years has been either under ESXi, or on AWS.

I'm sure I'm not alone in that, and that's a trend that's going to continue to grow.

How much of the kernel is drivers that are absolutely never going to useful in that scenario?

How much room is there for distributions to start supplying a kernel configuration with half of it never built?

Id point you to osv.io havent really played arounf with iy much though the concept is pretty intriguing .Being able to run the kernel directly on the hypervisor , and containing only your app and whats needed to run , thus obviatibg the need for device drivers with everything running in the kernel address space.Also check out LING for the erlangVM

Reply on news.ycombinator.com