Re: Updates on Tarides Plans with MirageOS - Request for Feedback

[Thomas Gazagnaire <thomas.gazagnaire@xxxxxxxxx>]

Dear Takayuki,

Many thanks for your response.

> I'm interested in some topics below, and happy to be engaged in one or two of 
> them though I am a weekend hobbyist. :-)
> 
>  1. Solo5 improvement
>  2. Unikraft back-end
>  -> I like the Solo5 philosophy (simple, small, and secured). However ... the 
> current Solo5 implementation has some problems as you mentioned.
>     So, having an alternative back-end seems a good way.
>  3. MirageOS device APIs (mainly targeting PCIe devices?)
>  -> I have previously tried "MirageOS + Solo5 hvt + Netmap + 10GbE with 
> SR-IOV". My experience on that will be helpful to this topic!

That’s really appreciated. We will keep you in the loop. What do you recommend 
reading to learn more about your experience with Netmap?

Best,
Thomas

> On 2023/12/16 3:18, Thomas Gazagnaire wrote:
>> 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