There's a fantastic episode of Signals & Threads podcast about MirageOS's roots, Xen Hypervisor and more with Anil Madhavapeddy as the guest. I found it very thought provoking: https://signalsandthreads.com/what-is-an-operating-system/
MirageOS is really interested when combined with Qubes OS. I've started looking at MirageOS, and since I use Qubes, being able to run things directly on Xen right next to my regular VM's is really neat.
There are also projects to replace sys-firewall with a MirageOS unikernel instead. That's something that seems very interesting.
This name is associated with a lot of nostalgia for me, as it is the same name as the shell launcher for Texas Instruments' TI-83/84 graphing calculators.
This project mentions it’s based on the Xen hypervisor and uses EC2 as an example for running it, but haven’t AWS now moved to their own KVM based hypervisor? Would this still work?
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.
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.
I am fascinated by Unikernels. But how do they deal with things that need to fork or run multiple processes? Aren't they restricted to single processes?
This all started because we wanted to _get away_ from the need to fork or run multiple processes, since that's so hard in a variety of hardware architectures (like mobile or embedded).
It took a little longer than I'd planned, but thanks to the hard work of so many MirageOS contributors, now's a pretty good time to glue back personal containers and self-hosted data management infrastructure again! Unikernel-based messaging has really come together in the past couple of years: https://tarides.com/blog/2022-03-08-secure-virtual-messages-...
We use asynchronous tasks in MirageOS (cooperative multitasking) using lwt http://ocsigen.org/lwt/latest/manual/manual, so you can serve multiple network connections at the same time.
Since there are no processes, there's no concept of "fork", but indeed you can run multiple tasks at the same time (using the same address space). Why again would you need multiple processes? Since the programming language OCaml has a semantics and is memory-safe, there's no strong reason for isolation at execution time (apart from the C bits, which we try to keep to a minimum and compile with runtime safety flags (red-zone for stack protection, mapping execute-only (seems to only reliably work on OpenBSD), etc.)).
What about multiprocessing? I assume that MirageOS can take advantage of multiple cores (or do you need separate instances per core?). In this case is the system still shared memory?
Also I would say there are reasons for isolation beyond memory safety.
MirageOS is - similar to the latest OCaml release - only using a single CPU core. You can run multiple unikernels, one on each core. If doing that, you can use Xen vchan (shared memory), or TCP for marshalling.
> Also I would say there are reasons for isolation beyond memory safety.
Would you mind to elaborate which reasons you are thinking of?
> MirageOS is - similar to the latest OCaml release - only using a single CPU core.
Thanks. Is that going to change now that OCaml is finally getting proper multicore support?
>> Also I would say there are reasons for isolation beyond memory safety.
>Would you mind to elaborate which reasons you are thinking of?
Memory safety in a sense protects the integrity of the 'runtime', but only partially help to protect business level integrity. A task might still tricked (by mistake or malice) to access objects it is not supposed to. I'm sure that OCaml has enough abstractions to help prevent that, but full isolation of tasks is a blunt and effective tool.
How does it go when you deploy a unikernel on EC2 (or on any IaaS where the hypervisor is managed unlike bare-metal) with multiple cores? Is there a way to start a unikernel per core on a single instance, or are you bound to use single core instance types only?
Just substitute 'microservice' with 'unikernel' and you do broadly the same things. There's a prometheus library that you link with the MirageOS unikernel and it exports using that: https://github.com/mirage/prometheus
No FAQ for this sort of thing yet, but we should start assembling one sometime soon. Questions like this very welcome on the discussion forums: https://discuss.ocaml.org/t/ann-mirageos-4-0/9598 to help us get started.
Unikernel Linux (UKL - https://github.com/unikernellinux) actually does allow you to fork. The main unikernel program runs in kernel space linked to Linux, and after a fork you get a new, regular userspace process.
