[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Updates on Tarides Plans with MirageOS - Request for Feedback
Dear Thomas,
> That’s really appreciated. We will keep you in the loop. What do you
recommend reading to learn more about your experience with Netmap?
A performance side report can be found at
https://dl.acm.org/doi/10.1145/3264560.3264561.
As for the API design, I have tried to keep the original MirageOS and Solo5
implementation.
What I have done is just replacing "the original tap-based network handling in the Solo5 hvt
binding and tender" by "another netmap-based one".
Design concept:
- Compatible APIs implemented to operate with the original(unmodified) Netif
provided by mirage-net-solo5
- Interrupt handling in the Solo5 hvt tender side (conforming the original
Solo5 hvt I/O handling)
- No device drivers for PCIe and a target NIC implemented in the Unikernel
side (in order to reduce the implementation cost)
Test code (binding) :
https://github.com/solo5-netmap/solo5/blob/netmap/kernel/ukvm/netmap.c
(tender) :
https://github.com/solo5-netmap/solo5/blob/netmap/ukvm/ukvm_module_netmap.c
Kind regards,
--
Takayuki Imada
On 2023/12/21 1:42, Thomas Gazagnaire wrote:
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
|
