[hannesm]

In ancient times, only Xen was supported. Nowadays, the support moved to:

  - Xen (PVH)
  - Linux KVM, FreeBSD BHyve, OpenBSD VMM
  - SPT (seccomp, no hardware virtualization)
  - virtio (GCE, ..)
  - muen (muen.sk)

Take a look at https://github.com/solo5/solo5 which is used as the low level bits to run OCaml.

[mwcampbell]

> - SPT (seccomp, no hardware virtualization)

To be clear, this means running an ordinary Linux binary, right?

I'm curious about the remaining advantages in practice of running multiple processes on a shared kernel rather than using hardware virtualization. I guess the main one is more efficient resource pooling, particularly memory and the page cache. I understand the primary advantage of virtualization is a smaller attack surface.

[hannesm]

Yes, this is an ordinary Linux binary.

The attack surface is different, you may be interested in https://archive.fosdem.org/2019/schedule/event/solo5_unikern... and/or https://archive.fosdem.org/2019/schedule/event/solo5_unikern... :)

TL;DR: hardware virtualization is pushing trust into hardware -- but can you trust the hardware implementation (to isolate memory)?

[cestith]

One of the stated advantages various places of having a unikernel build as a regular ELF binary on Linux or BSD (including the semi-BSD macOS) is that you can use it as your instrumented debug build very easily. Yes, you can instrument your app heavily. You can have console output. You can log to a mounted volume, to an object store, or to a remote log server with rsyslog or something like Elastic. But with an ELF binary on an OS you can strace, dtrace, fence it, run it under gdb or another debugger, instrument the OS under it, or whatever. Then the same source code builds essentially the same program to run right on KVM or Xen with no OS under it for security and efficiency.