MirageOS 4.0 – Self-managed internet infrastructure with unikernels

Re:MirageOS 4.0 – Self-managed internet infrastructure with ... by mindwok on Tuesday March 29, 2022 @06:13AM (#30840740)

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?

[ Parent | on HN ]

Re:MirageOS 4.0 – Self-managed internet infrastructure with ... by hannesm on Tuesday March 29, 2022 @07:49AM (#30841334)

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.

[ Parent | on HN ]

Re:MirageOS 4.0 – Self-managed internet infrastructure with ... by mwcampbell on Tuesday March 29, 2022 @10:54AM (#30843355)

> - 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.

[ Parent | on HN ]

Re:MirageOS 4.0 – Self-managed internet infrastructure with ... by hannesm on Tuesday March 29, 2022 @11:06AM (#30843536)

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)?

[ Parent | on HN ]

Re:MirageOS 4.0 – Self-managed internet infrastructure with ... by cestith on Tuesday March 29, 2022 @02:48PM (#30846761)

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.

[ Parent | on HN ]

Re:MirageOS 4.0 – Self-managed internet infrastructure with ... by detaro on Tuesday March 29, 2022 @06:23AM (#30840802)

You can still choose Xen-based instances in EC2.

[ Parent | on HN ]

Re:MirageOS 4.0 – Self-managed internet infrastructure with ... by mindwok on Tuesday March 29, 2022 @06:42AM (#30840909)

Ahh ok. I imagine you would lose all the nice Nitro stuff though like enhanced networking etc which is a bummer.

[ Parent | on HN ]

Re:MirageOS 4.0 – Self-managed internet infrastructure with ... by Dunedan on Tuesday March 29, 2022 @07:40AM (#30841263)

There is Xen-on-Nitro, which AWS developed to continue to support customers using Xen to run on EC2 instances featuring Nitro: https://perspectives.mvdirona.com/2021/11/xen-on-nitro-aws-n...

[ Parent | on HN ]

Re:MirageOS 4.0 – Self-managed internet infrastructure with ... by mindwok on Tuesday March 29, 2022 @05:57PM (#30848906)

That’s great to know, thank you

[ Parent | on HN ]

Re:MirageOS 4.0 – Self-managed internet infrastructure with ... by wmf on Tuesday March 29, 2022 @02:22PM (#30846464)

This isn't good advice. People should probably use the hvt backend on AWS.

[ Parent | on HN ]