MirageOS 4

What is MirageOS?

MirageOS is a library operating system that can build standalone unikernels on various platforms. More precisely, the architecture can be divided into:

1. operating system libraries that implement kernel and protocol functionality, ranging from low-level network card drivers to a full reimplementation of the TLS protocol, through to a reimplementation of the Git protocol to store versioned data.

2. A set of typed signatures to make sure these libraries are consistent and can interoperate. As all the library are almost all pure OCaml code, we have defined a set of OCaml module types that encode these conventions in a statically enforcable way. We make no compatibility guarantees at the C level, but compile those on a best-effort basis.

3. Finally, MirageOS is also a metaprogramming compiler that generates OCaml code. It takes as input: the OCaml source code of a program and all of its dependencies, the full description of
   the deployment target, including configuration values (like the HTTP port to listen too, or the private key or the service being deployed). The mirageCLI tool uses all of these to generate a executable unikernel: a specialised binary artefact containing only the code what is needed to run on the given deployment platform and no more.

It is possible to write high-level MirageOS applications, such as HTTPS, email or CalDAV servers which can be deployed on very heterogenous and embedded platforms by changing only a few compilation parameters. The supported platforms range from ESP32 micro-controllers, minimal virtual machines running on a cloud providers, or processes running inside a Docker container configured with a tight security profile. In general, these platform do not have a full POSIX environment; MirageOS does not try to emulate POSIX and focuses on providing a small, well-defined, typed interface with the system components. The nearest equivalent to the MirageOS approach is the WASI (wasi.dev) set of interfaces for WebAssembly.

1. and 2. are relatively well-defined in MirageOS 3. MirageOS 4 is focusing on 3.

Is everything really written in OCaml

While most of the code is written in OCaml, a typed, high-level language with many good safety properties, there are pieces of MirageOS which are still written in unsafe C. These bits can be
separated in three categories:

1. The OCaml runtime is written in C. It needs to be ported to the platform that MirageOS is trying to target, which do not support POSIX. Hence, the first component to port to a new platform is the OCaml runtime.

2. The low-level device drivers (network, console, clock, etc) also need some C bits.

3. The base usual C bindings; some libraries are widely used and (unfortunately) very hard (but not impossible) to replace them completely without taking a big performance hit or having to trust code without much real-world usages. This is the case for low-level bit handling for crypto code (even if we try to make sure allocation is alway handled by the OCaml runtime) as well as arbitrary precision numeric computation (e.g. gmp). Ideally we could image rewriting all of these libraries in OCaml if we had an infinite amount of time in our hands.

MirageOS as a cross-compilator

The MirageOS compiler is basically a cross-compiler, where the host and target toolchain are identical, but with different flags for the C bindings: for instance, it is necessary to pass -freestanding to all C bindings to not use POSIX headers. The MirageOS compiler also uses a custom linker: eg. not only it needs a custom OCaml's runtime libasmrun.a, but it also needs to run a different linker to generate specialised executable images.

Historically, the OCaml ecosystem always had partial support for cross-compilation: for instance, the ocaml-cross way of doing it is to duplicate all existing opam pacakges by adding a -windows suffix to their names and dependencies; this allows normal packages and windows packages can be co-installed in the same opam switch.

MirageOS 3 resolved that by duplicating only the packages defining C bindings and (ab)using ocamlfind predicates to resolve link time depencencies for C archives and on relying on the now deprecated --output-obj option of the OCaml compiler.

The proposal for MirageOS 4 is to solve this issue via the built-in support for cross-compilation of dune. This is done by gathering all the sourceslocally, creating a dune-workspace file describing the C flags to use in each cross-compilation "context" and then call dune once.

An example: solo5

The current prototype is using duniverse to gather all sources and can be tested as follows:

$ opam pin add https://github.com/samoht/mirage.git#dune
$ opam pin add https://github.com/ocamllabs/duniverse.git
$ cd <your app>
$ mirage configure -t hvt
$ duniverse init --opam-repo https://github.com/samoht/opam-repository.git#duniverse
$ duniverse pull
$ dune build <app>.hvt
$ dune exec -- solo5-hvt <app.hvt>

Current limitations:

• xen support TBD
• Add enabled_if to install stanzas and enforce variable restrictions ocaml/dune#3408 to make dune build just work
• sort out Zarith fork situation

Possible improvements:

• do we want mirage exec to replace the last line?
• use dune to generate opam files

note: this PR builds on the amazing work done by @TheLortex @dinosaure who worked on various iterations of this patch over the last 2 years.