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

[Takayuki Imada <takayuki.imada@xxxxxxxxx>]

Dear Thomas,

Thanks for sharing many updates!

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!

Kind regards,

--
Takayuki Imada


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