Nanos Unikernel and Qubes

General Discussion
1

Hello all,
I know there has been some work with MirageOS and Qubes. Has anyone seen anything with Nanos?
It works with XEN.

Already has a number of deployable packages vis OPS
Has some interesting features already:

For those wanting to know more about Unikernels in general. Here is a good write up.

Here is one on the security of Nanos.

5 Likes
2

Interesting.

3

Something else worth considering. For future directions of Qubes.
As many of you are probably aware the xz backdoor has brought back to light the difficulties in providing security on modern infrastructure(XKCD).
To quote someone on Hacker News.

devs: there’s too much complexity! security is impossible!
also devs: let’s add just one more layer on top of linux → docker → k8s
godspeed to the nanos team for trying to simplify the stack

Unikernels make a great fit for Qubes. They reduce the attack surface and stack much better than minimal monolithic images like Debian minimal. They boot up very quick and use much less RAM and CPU resources, opening Qubes up to run on more systems, with much more responsive times for starting/stopping AppVMs than currently possible with the current images.

There are a number of useful Unikernels like Nanos, unikraft and MirageOS that can be utilised today as they support XEN and are designed around using a hypervisor.

The whitehouse and the usual suspects want the future of computing to focus on memory safety. One way of doing this is to re-write software with memory safe languages. Another way is to utilise hardware that is designed to make legacy code memory safe.

Qubes could be moving forward in this direction by exploring more MireageOS solutions with Ocaml or looking at hardware solutions such as supporting Capability Hardware Enhanced RISC Instructions (CHERI) with boards such as Morello. Morello along side unikernels such as FlexOS (which exists today), could make a great match for Qubes. Obviously this would require Qubes supporting arm8 boards.
Here is a good paper showing how to use the Morello board with FlexOS on top of Unikraft unikernels to meet this memory safety goal.

4

Do they have X11/Wayland support, what about hardware driver support?

5

See

6

Does that mean it can’t run any appVMs because there isn’t any support for running a full desktop environment, and you can’t run any sys qubes that handles hardware because there is only support for virtual hardware?

Or am I missing something?

Yes, you can run sys-firewall, because it is a single service atomic micro server, but can it with currently available technology be used for anything else?

7

MirageOS has some support for writing to Qubes framebuffer.

8

And what software are you going to be able to run in an appVM that only is capable of using a frame buffer?

Am I completely missing something, or is there zero software support of any kind, and it would be practically impossible to run any traditional software without a massive effort to port everything needed to mirageOS?

9

GUI virtualization | Qubes OS ← HOW GUI is handled in Qubes.

The argument I was trying to make was MirageOS/Nanos/Unikraft Unikernel for supported apps, and apps that can be easily ported. Then for larger legacy app that won’t port looking at exOS, which can do unikernel, microkernel and monolithic VMs. For memory safety looking at CHERI with boards like Morello, which bring this safety in via hardware so that software doesn’t require huge efforts to port over.

This wasn’t a flip everything over to Unikernels now. This was a post about future directions for Qubes. Most of the listed Unikernels are becoming useful. Unikernels could be a great fit for Qubes.

10

The argument I was trying to make was MirageOS/Nanos/Unikraft Unikernel for supported apps, and apps that can be easily ported.

That seems hard for other than services VMs (firewall, nat, vpn, etc.) because not even counting the work for porting aplications, you’ll probably need a storage system, and/or something like a shell to move/copy files from/to other AppVVM.
I’m not saying that is impossible (I wrote a sshfs server unikernel some times ago, and the storage is taken from the unikernel space address, so no files at startup, no saves on shutdown) but onboarding multiple applications in the same kernel seems to me far from the definition of unikernels :slight_smile:

1 Like