Module Mirage

Configuration keys.

The type for tracing.

Implementation of the tracing type.

Use mirage-profile to trace the unikernel. On Unix, this creates and mmaps a file called "trace.ctf". On Xen, it shares the trace buffer with dom0.

• parameter size:

  size of the ring buffer to use.

For the Qubes target, the Qubes database from which to look up * dynamic runtime configuration information.

A default qubes database, guessed from the usual valid configurations.

Abstract type for timers.

Implementations of the Mirage_time.S signature.

The default timer implementation.

Abstract type for POSIX clocks.

Implementations of the Mirage_clock.PCLOCK signature.

The default mirage-clock PCLOCK implementation.

Abstract type for monotonic clocks

Implementations of the Mirage_clock.MCLOCK signature.

The default mirage-clock MCLOCK implementation.

The type for log reporters.

Implementation of the log reporter type.

default_reporter ?clock ?level () is the log reporter that prints log messages to the console, timestampted with clock. If not provided, the default clock is default_posix_clock. level is the default log threshold. It is Logs.Info if not specified.

no_reporter disable log reporting.

Abstract type for random sources.

Implementations of the Mirage_random.S signature.

Default PRNG device to be used in unikernels. It uses getrandom/getentropy on Unix, and a Fortuna PRNG on other targets.

rng is the device Mirage_crypto_rng.Make.

Abstract type for consoles.

Implementations of the Mirage_console.S signature.

Default console implementation.

Custom console implementation.

Abstract type for raw block device configurations.

Implementations of the Mirage_block.S signature.

Use the given file as a raw block device.

Use the given XenStore ID (ex: /dev/xvdi1 or 51760) as a raw block device.

Use a ramdisk with the given name.

Abstract type for read-only key/value store.

Implementations of the Mirage_kv.RO signature.

Crunch a directory.

Use a TAR archive.

Direct access to the underlying filesystem as a key/value store. For Xen backends, this is equivalent to crunch.

Use a FAT formatted block device.

Generic key/value that will choose dynamically between direct_kv_ro and crunch. To use a filesystem implementation, try kv_ro_of_fs.

If no key is provided, it uses Key.kv_ro to create a new one.

docteur ?mode ?disk ?analyze remote is a read-only, key-value store device. Data is stored on that device using the Git PACK file format, version 2. This format has very good compression factors for many similar files of relatively small size. For instance, 14Gb of HTML files can be compressed into a disk image of 240Mb.

Unlike crunch, docteur produces an external image which means that less memory is used to keep and get files. The image can be produced from many sources:

• A local Git repository (like file://path/to/the/git/repository/)
• A simple directory (like file://path/to/a/simple/directory/)
• A remote Git repository (via SSH, HTTP(S) or TCP/IP as what git clone expects)

If you use a Git repository, you can choose a specific branch with the ?branch argument (like refs/heads/main). Otherwise, this argument is ignored.

If you use a simple directory, it can be a relative from your unikernel project (relativize://directory) or an absolute path (file://home/user/directory).

If a required file is produced by a dune rule, you must notice it via the extra_deps argument.

For a Solo5 target, users must attach the image as a block device:

$ solo5-hvt --block:<name>=<path-to-the-image> -- unikernel.{hvt,...}

For the Unix target, the program open the image at the beginning of the process. An integrity check of the image can be done via the analyze value (defaults to true).

It's possible to use the file-system into 2 modes:

• `Light: any access requires that we reconstruct the path to the requested file. That means that we will need to extract a few additional objects before the extraction of the requested one. `Light does not cache anything in memory but it can be slower if the requested file is deep in the directory structure.
• `Fast: reconstructs and cache the layout of the directory structure when the unikernel starts: it might increase boot-time and bigger memory requirements. However, `Fast allows the device to decode only the requested object so it is faster than the `Light mode.

Abstract type for read-write key/value store.

Implementations of the Mirage_kv.RW signature.

Direct access to the underlying filesystem as a key/value store. Only available on Unix backends.

An in-memory key-value store using mirage-kv-mem.

chamelon ~program_block_size returns a kv_rw filesystem which is an implementation of littlefs in OCaml. The chamelon device expects a block-device:

let program_block_size =
  let doc = Key.Arg.info [ "program-block-size" ] in
  Key.(create "program_block_size" Arg.(opt int 16 doc))

let block = block_of_file "db"
let fs = chamelon ~program_block_size block

For Solo5 targets, you finally can launch the unikernel with:

$ solo5-hvt --block:db=db.img unikernel.hvt

The block-device must be well-formed and formatted by the chamelon tool:

$ dd if=/dev/zero of=db.img bs=1M count=1
$ chamelon format db.img 512

ccm_block key block returns a new block which is a AES-CCM encrypted disk.

Note also that the available size of an encrypted block is always divided by 2 of its real size: a 512M block will only be able to contain 256M data if it is encrypted.

You can either use a fresh block device as encrypted storage. This does not need any preparation, just using ccm_block with the desired key. If you have an existing disk image that you want to encrypt, you can use the ccmblock tool given by the mirage-block-ccm opam package.

$ ccmblock enc -i db.img -k 0x10786d3a9c920d0b3ec80dfaaac557a7 -o edb.img

Then, into you config.ml, you just need to compose your block device with ccm_block:

let aes_ccm_key =
  let doc =
    Key.Arg.info [ "aes-ccm-key" ]
      ~doc:"The key of the block device (hex formatted)"
  in
  Key.(create "aes-ccm-key" Arg.(required string doc))

let block = block_of_file "edb"
let encrypted_block = ccm_block aes_ccm_key block

Finally, with Solo5, you can launch your unikernel with that:

$ solo5-hvt --block:edb=edb.img \
  --arg="--aes-ccm-key=0x10786d3a9c920d0b3ec80dfaaac557a7" \
  unikernel.hvt

You can finally compose a file-system such as chamelon with this block device (and you have a encrypted file-system!):

let fs = chamelon ~program_block_size encrypted_block

Abstract type for network configurations.

Implementations of the Mirage_net.S signature.

default_network is a dynamic network implementation * which attempts to do something reasonable based on the target.

A custom network interface. Exposes a Key.interface key.

Implementations of the Ethernet.S signature.

Implementation of the Arp.S signature.

ARP implementation provided by the arp library

Abstract type for IP configurations.

The Tcpip.Ip.S module signature with ipaddr = Ipaddr.V4.

The Tcpip.Ip.S module signature with ipaddr = Ipaddr.V6.

The Tcpip.Ip.S module signature with ipaddr = Ipaddr.t.

Types for manual IPv4 configuration.

Types for manual IPv6 configuration.

Use an IPv4 address Exposes the keys Key.V4.network and Key.V4.gateway. If provided, the values of these keys will override those supplied in the ipv4 configuration record, if that has been provided.

Use a given initialized QubesDB to look up and configure the appropriate * IPv4 interface.

Use an IPv6 address. Exposes the keys Key.V6.network, Key.V6.gateway.

Implementation of the Tcpip.Udp.S signature.

Implementation of the Tcpip.Tcp.S signature.

Implementation of the Tcpip.Stack.V4V6 signature.

Direct network stack with given ip.

Network stack with sockets.

Build a stackv4v6 by checking the Key.V6.network, and Key.V6.gateway keys for IPv4 and IPv6 configuration information, filling in unspecified information from ?config, then building a stack on top of that.

Generic stack using a net keys: Key.net.

• If net = socket then socket_stackv4v6 is used
• Else, if unix or macosx then socket_stackv4v6 is used
• Else, static_ipv4v6_stack is used.

If a key is not provided, it uses Key.net (with the group argument) to create it.

tcpv4v6 stackv4v6 is an helper to extract the TCP/IP stack regardless the UDP/IP stack expected by some devices such as protocols.

generic_dns_client stackv4v6 creates a new DNS value which is able to resolve domain-name from nameservers. It requires a network stack to communicate with these nameservers.

The nameservers argument is a list of strings. The format of them is:

• tcp:ipaddr(:port)? if you want to communicate with a DNS resolver via TCP/IP
• tls:ipaddr(:port)?(!<authenticator>) if you to communicate with a DNS resolver via TLS. You are able to introduce an <authenticator> (please, follow the documentation about X509.Authenticator.of_string to get an explanation of its format). Otherwise, by default, we use trust anchors from NSS' certdata.txt.

generic_happy_eyeballs stackv4v6 dns_client creates a new happy-eyeballs value which is able to resolve and connect to a remote host and allocate finally a connected flow from the given network implementation stackv4v6.

This device has several optional arguments of keys for timeouts specified in nanoseconds.

Helper for constructing a syslog_config.

The type for syslog

Implementation of the syslog type.

Emit log messages via UDP to the configured host.

Emit log messages via TCP to the configured host.

Emit log messages via TLS to the configured host, using the credentials (private key, certificate, trust anchor) provided in the KV_RO using the keyname.

mimic_happy_eyeballs stackv4v6 dns happy_eyeballs creates a device which initiate a global happy-eyeballs loop. By this way, an underlying instance works to initiate a TCP/IP connection from an IP address or a domain-name.

For the domain-name resolution, we ask the happy-eyeballs instance to resolve the given domain-name via the DNS instance created by dns (which includes several arguments like nameservers used - see generic_dns_client for more informations).

The resulting device can be used and re-used to for any clients which need to initiate a connection (like alpn_client or git_tcp).

cohttp_server starts a Cohttp server.

httpaf_server starts a http/af server.

cohttp_server starts a Cohttp server.

paf_server ~port tcpv4v6 creates an instance which will start to listen on the given port. With this instance and the produced module HTTP_server, the user can initiate:

• a simple HTTP server
• a simple HTTPS server (with a TLS configuration)
• a simple ALPN (http/1.1 & h2) server with TLS

This is a simple example of how to launch an HTTP server: unikernel.ml

module Make (HTTP_server : Paf_mirage.S with type ipaddr = Ipaddr.t) =
struct
  let error_handler (_ipaddr, _port) ?request:_ _error _send = ()

  let request_handler :
      HTTP_server.TCP.flow -> Ipaddr.t * int -> Httpaf.Reqd.t -> unit =
   fun _socket (_ipaddr, _port) reqd ->
    let contents = "Hello World!\n" in
    let headers =
      Httpaf.Headers.of_list
        [
          ("content-length", string_of_int (String.length contents));
          ("content-type", "text/plain");
          ("connection", "close");
        ]
    in
    let response = Httpaf.Response.create ~headers `OK in
    Httpaf.Reqd.respond_with_string reqd response contents

  let start http_server =
    let service =
      HTTP_service.http_service ~error_handler request_handler
    in
    let (`Initialized thread) = HTTP_server.serve service http_server in
    thread
end

config.ml

open Mirage

let port =
  let doc =
    Key.Arg.info ~doc:"Port of the HTTP service." [ "p"; "port" ]
  in
  Key.(create "port" Arg.(opt int 8080 doc))

let main = foreign "Unikernel.Make" (http_server @-> job)
let stackv4v6 = generic_stackv4v6 default_network
let http_server = paf_server ~port (tcpv4v6_of_stackv4v6 stackv4v6)
let () = register "main" [ main $ http_server ]

Abstract type for ALPN HTTP clients

paf_client tcpv4v6 ctx creates an ALPN device which can do HTTP (http/1.1 & h2) requests as a HTTP client. The device allocated represents values required to initiate a connection to HTTP webservers. The user can, then, use the module Http_mirage_client.request to communicate with HTTP webservers. This is an example of how to use the ALPN devices:

unikernel.ml

module Make (HTTP_client : Http_mirage_client.S) = struct
  let start http =
    Http_mirage_client.request http "https://google.com"
      (fun _response buf str -> Buffer.add_string buf str ; Lwt.return buf)
      (Buffer.create 0x100) >>= function
    | Ok (response, buf) ->
      let body = Buffer.contents buf in
      ...
    | Error _ -> ...
end

config.ml

open Mirage

let main = foreign "Unikernel.Make" (alpn_client @-> job)
let stackv4v6 = generic_stackv4v6 default_network
let dns = generic_dns_client stack

let alpn_client =
  let dns =
    mimic_happy_eyeballs stackv4v6 dns (generic_happy_eyeballs stack dns)
  in
  paf_client (tcpv4v6_of_stackv4v6 stackv4v6) dns

let () = register "main" [ main $ alpn_client ]

default_argv is a dynamic argv implementation * which attempts to do something reasonable based on the target.

no_argv Disable command line parsing and set argv to |""|.

The type for devices that implement the Git protocol.

merge_git_clients a b is a device that can connect to remote Git repositories using either the device a or the device b.

• deprecated

  You should use mimic_happy_eyeballs.

git_tcp tcpv4v6 dns is a device able to connect to a remote Git repository using TCP/IP.

git_ssh ?authenticator ~key tcpv4v6 dns is a device able to connect to a remote Git repository using an SSH connection with the given private key. The identity of the remote Git repository can be verified using authenticator.

The format of the private key is: <type>:<seed or b64 encoded>. <type> can be rsa or ed25519 and, if the type is RSA, we expect the seed of the private key. Otherwise (if the type is Ed25519), we expect the b64-encoded private key.

The format of the authenticator is SHA256:<b64-encoded-public-key>, the output of:

$ ssh-keygen -lf <(ssh-keyscan -t rsa|ed25519 remote 2>/dev/null)

git_http ?authenticator ?headers tcpv4v6 dns is a device able to connect to a remote Git repository via an HTTP(S) connection, using the provided HTTP headers. The identity of the remote Git repository can be verified using authenticator.

The format of it is:

• none no authentication
• key(:<hash>)?:<b64-encoded fingerprint> to authenticate via the key fingerprint
• cert(:<hash>)?:<b64-encoded fingerprint> to authenticate via the cert fingerprint
• trust-anchor(:<der-encoded cert>)+ to authenticate via a list of certificates - By default, we use X.509 trust anchors extracted from Mozilla's NSS

job is the combinator for representing main tasks.

noop is a job that does nothing, has no dependency and returns ()

keys argv is a job that loads argv.

info is the type for module implementing Mirage_runtime.Info.

info is the combinator to generate info values to use at runtime.

app_info exports all the information available at configure time into a runtime Mirage.Info.t value.

app_info exports all the information available at configure time into a runtime Mirage.Info.t value.

register name jobs registers the application named by name which will executes the given jobs.

• parameter packages

  The opam packages needed by this module.

• parameter keys

  The keys related to this module.

• parameter tracing

  Enable tracing.

• parameter reporter

  Configure logging. The default log reporter is default_reporter. To disable logging, use no_reporter.

• parameter argv

  Configure command-line argument parsing. The default parser is default_argv. To disable command-line parsing, use no_argv.