Updates on Tarides Plans with MirageOS - Request for Feedback

[Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx>]

Hello there,

Over the last year, Tarides has been engaging with partners in the space sector 
to adapt MirageOS for use in space environments. Following participation in 
Cyber@StationF and initial discussions with Thales Alenia Space in late 2022, 
we have begun the development of SpaceOS. This operating system, leveraging 
numerous MirageOS components, is designed to meet the new requirements of 
multi-mission, multi-user satellite missions (what people also call "NewSpace").

SpaceOS's development has led to Tarides joining a consortium of academic and 
commercial entities in the space industry. We have successfully obtained our 
first grant (with the [ORCHIDE project, part of the EU HORIZON 
CL4-2023-SPACE-01-11 
programme,](https://ec.europa.eu/info/funding-tenders/opportunities/portal/screen/how-to-participate/org-details/999999999/project/101135595/program/43108390/details))
 and have several others under review. The goal for SpaceOS is to remain as 
open-source as possible, aligning with the MirageOS community's approach to 
software development (with a few exceptions in scenarios involving proprietary 
hardware or software vendors).

Hence, Tarides is planning active development work on MirageOS in the coming 
years in conjunction with the early development stages of SpaceOS. We have 
ambitious plans in mind and are reaching out to the MirageOS community to 
gather input and perspectives during this phase. We welcome your thoughts on 
this matter, whether these are agreements, disagreements, or general comments. 
Please share your feedback on this mailing list (preferred) or through private 
communication.

### Tooling

Over the past five years, our efforts have focused on integrating 
Mirage-specific tooling into the OCaml Platform. We plan to continue in this 
direction. This integration is intended to benefit both Mirage developers (by 
reducing the maintenance burden on the core MirageOS team) and the broader 
OCaml user base (as they could benefit from MirageOS workflow -- especially 
cross-compilation -- in other situations).

A significant part of this effort was transitioning from custom x-compilation 
runes to using Dune workspace via `opam -monorepo`. This migration was not 
always painless (to say the least), but we learned a few things that are now 
being applied to the new "package management" feature of Dune 4. Thus, we plan 
to continue to work on migrating from `opam-monorepo` to the `dune pkg` command 
to ensure it works for MirageOS users. This new command addresses the 
limitations identified in opam-monorepo, especially for packages not built with 
Dune. An alpha version is currently available (try `dune pkg` with Dune 3.12), 
and we anticipate a complete release in Q1 2024. We really want to ensure this 
is a drop-in replacement for Mirage's use of `opam-monorepo`, so we will work 
with upstream to ensure that is the case (and so we can deprecate opam-monorepo 
in Q2 2024).

Regarding mirage/functoria, my general feeling is that while the CLI tool was 
initially valuable for gathering an ecosystem of libraries, nowadays, it is 
less clear if this is still required. Right now, most of the tool's complexity 
is handling the installation of packages needed for a specific 
target/combination of devices. This will no longer be needed if the build 
system can do this instead. Ideally, any OCaml application (following a few 
design principles) could be compiled to a unikernel simply using Dune, as 
envisioned by the [Workflow 
W12](https://ocaml.org/docs/platform-roadmap#w12-compile-to-mirageos) of the 
OCaml Roadmap. However, there is no existing design on how this should work at 
this stage. So, before starting this, is that the right direction for the 
mirage tool?

### Targets

The principal target backend for MirageOS nowadays is Solo5. This is a solid 
backend, which has been audited and optimised for security. It is also 
relatively simple to add new devices given the by-design low-complexity 
approach of its device model. However, while solo5 is today the most secure 
unikernel "runtime", I also feel it has issues hindering potential changes. For 
one, it is slow -- the device model is not meant for high-speed I/O, and there 
is no support for SMP; for most use cases, it is not an issue, but for others 
we are looking at, it can be. The other one is that the device model is very 
simple (for good reasons) and challenging to extend to new devices (see below 
for more detail). In an ideal world, this could be fixable, but there are also 
very few courageous active maintainers, so any changes - like moving to OCaml5 
- are complex to make.

Thus, we are evaluating alternate backends with the main criteria to reduce the 
maintenance cost. Despite its currently limited security features, one 
interesting possibility is shifting towards alternative backends like unikraft. 
Christiano spent a bit of time looking at this earlier this year (with a 
prototype of the OCaml 5 runtime x-compiler to Unikraft 
[here](https://github.com/haesbaert/unikraft-ocaml) and a roadmap for Unikraft 
security [here](https://github.com/orgs/unikraft/projects/32/views/1)). Same as 
above, we are interested to hear what people think and if anyone is interested 
in collaborating with us in porting MirageOS to unikraft (and contributing to 
Unikfraft' security roadmap).

### Devices and Libraries

There are three areas that we would like to focus on (or continue to focus on) 
in the next couple of years.

First, we still believe there are better abstractions for storing data than 
POSIX. Hence, we are continuing to develop and improve Irmin. We are currently 
porting `irmin-pack` to MirageOS (the backend of Irmin used by the Tezos 
blockchain to store its ledger history) via the 
[Notafs](https://github.com/tarides/notafs) project. Notafs is a pseudo 
filesystem for Mirage block devices. It can handle a small number of large 
files. While the limited number of filenames is unsatisfying for general usage, 
it can be used to run the irmin-pack backend of Irmin, which only requires a 
dozen huge files. By running Irmin, one gets for free a filesystem-on-steroid 
for MirageOS: it supports an arbitrarily large number of filenames; is 
optimised for small and large file contents; performs file deduplication; 
includes a git-like history with branching and merging, ... and it even 
provides a garbage collector to avoid running out of disk space (by deleting 
older commits). Since the Irmin filesystem is versioned by Merkle hashes, one 
can imagine deploying reproducible unikernels on reproducible filesystem states!

We are also interested in developing new network protocols for space 
applications, which could benefit from MirageOS's capabilities. We are likely 
targeting the [Space Communication 
Protocol](https://en.wikipedia.org/wiki/Space_Communications_Protocol_Specifications),
 which seems an interesting domain as there does not seem to exist any 
open-source, robust implementation of these protocols. 

Finally, the API for devices supported by MirageOS currently maps to what is 
available on virtualised infrastructure (i.e. virtual block devices and virtual 
network interface). We are interested in investigating how to extend this, for 
instance, by reviving the PCI-passthrough experimentations done a few years ago 
by Florian, or by investigating new multi-tenancy device frameworks like 
[vAccel](https://vaccel.org/) to (securely?) share GPGPUs or FPGAs between 
users. Alternatively, we could use Owl using CPU. We also welcome anyone with 
any experience in this area to discuss existing alternatives.

### OS Distribution

Finally, we are considering options for building a flexible OS distribution, 
which might include elements like 
[LinuxKit/MirageSDK](https://github.com/linuxkit/linuxkit/tree/master/projects/miragesdk).
 This concept combines a secure Linux kernel with a collection of Mirage-based 
system services and an extended version of Albatross for orchestration, all 
customisable based on specific needs. We are in the early stages of this 
discussion and welcome any input or expressions of interest in furthering these 
ideas.

Best,
Thomas