Introduction to monitoring

Re-developing an opam cache from scratch, as a MirageOS unikernel

All your metrics belong to influx

How to monitor your MirageOS unikernel with albatross and monitoring-experiments

Deploying binary MirageOS unikernels

Written by hannes 2021-04-23

Finally, we provide reproducible binary MirageOS unikernels together with packages to reproduce them and setup your own builder

Cryptography updates in OCaml and MirageOS

Elliptic curves (ECDSA/ECDH) are supported in a maintainable and secure way.

The road ahead for MirageOS in 2021

Written by hannes 2021-01-25

Home office, MirageOS unikernels, 2020 recap, 2021 tbd

Traceroute

A MirageOS unikernel which traces the path between itself and a remote host.

Deploying authoritative OCaml-DNS servers as MirageOS unikernels

A tutorial how to deploy authoritative name servers, let's encrypt, and updating entries from unix services.

Reproducible MirageOS unikernel builds

Written by hannes 2019-08-15

MirageOS unikernels are reproducible :)

X509 0.7

Five years since ocaml-x509 initial release, it has been reworked and used more widely

Summer 2019

Bringing MirageOS into production, take IV monitoring, CalDAV, DNS

The Bitcoin Piñata - no candy for you

More than three years ago we launched our Bitcoin Piñata as a transparent security bait. It is still up and running!

My 2018 contains robur and starts with re-engineering DNS

New year brings new possibilities and a new environment. I've been working on the most Widely deployed key-value store, the domain name system. Primary and secondary name services are available, including dynamic updates, notify, and tsig authentication.

Albatross - provisioning, deploying, managing, and monitoring virtual machines

all we need is X.509

Conex, establish trust in community repositories

Conex is a library to verify and attest package release integrity and authenticity through the use of cryptographic signatures.

Who maintains package X?

Written by hannes 2017-01-30

We describe why manual gathering of metadata is out of date, and version control systems are awesome.

Jackline, a secure terminal-based XMPP client

implement it once to know you can do it. implement it a second time and you get readable code. implementing it a third time from scratch may lead to useful libraries.

Exfiltrating log data using syslog

sometimes preservation of data is useful

Re-engineering ARP

If you want it as you like, you've to do it yourself

Minimising the virtual machine monitor

MirageOS solo5 multiboot native on bhyve

Counting Bytes

looking into dependencies and their sizes

Configuration DSL step-by-step

Written by hannes 2016-05-03

how to actually configure the system

Catch the bug, walking through the stack

10BTC could've been yours

Fitting the things together

building a simple website

Why OCaml

a gentle introduction into OCaml

Operating systems

Operating systems and MirageOS

\ No newline at end of file diff --git a/Posts/nqsbWebsite b/Posts/nqsbWebsite new file mode 100644 index 0000000..1c60e9e --- /dev/null +++ b/Posts/nqsbWebsite @@ -0,0 +1,194 @@ + +Fitting the things together

Fitting the things together

Written by hannes

Classified under: mirageos http tls protocol

Published: 2016-04-24 (last updated: 2021-11-19)

Task

Our task is to build a small unikernel which provides a project website. On our way we will wade through various layers using code examples. The website itself contains a few paragraphs of text, some link lists, and our published papers in pdf form.

Spoiler alert final result can be seen here, the full code here.

A first idea

We could go all the way to use conduit for wrapping connections, and mirage-http (using cohttp, a very lightweight HTTP server). We'd just need to write routing code which in the end reads from a virtual file system, and some HTML and CSS for the actual site.

Turns out, the conduit library is already 1.7 MB in size and depends on 34 libraries, cohttp is another 3.7 MB and 40 dependent libraries. +Both libraries are actively developed, combined there were 25 releases within the last year.

Plan

Let me state our demands more clearly:

easy to maintain +
updates roughly 3 times a year +
reasonable performance +

To achieve easy maintenance we keep build and run time dependencies small, use a single virtual machine image to ease deployment. We try to develop only little new code. Our general approach to performance is to do as little work as we can on each request, and precompute at compile time or once at startup as much as we can.

HTML code

From the tyxml description: "Tyxml provides a set of combinators to build Html5 and Svg documents. These combinators use the OCaml type-system to ensure the validity of the generated Html5 and Svg." A tutorial is available.

You can plug elements (or attributes) inside each other only if the HTML specification allows this (no <body> inside of a <body>). An example that can be rendered to a div with pcdata inside.

If you use utop (as interactive read-eval-print-loop), you first need to load tyxml by #require "tyxml".

open Html5.M
+
+let mycontent =
+  div ~a:[ a_class ["content"] ]
+    [ pcdata "This is a fabulous content." ]
+

In the end, our web server will deliver the page as a string, tyxml provides the function Html5.P.print : output:(string -> unit) -> doc -> unit. We use a temporary Buffer to print the document into.

# let buf = Buffer.create 100
+# Html5.P.print ~output:(Buffer.add_string buf) mycontent
+
+Error: This expression has type ([> Html5_types.div ] as 'a) elt but an expression was expected of type doc = [ `Html ] elt Type 'a = [> `Div ] is not compatible with type [ `Html ]
+The second variant type does not allow tag(s) `Div
+

This is pretty nice, we can only print complete HTML5 documents this way (there are printers for standalone elements as well), and will not be able to serve an incomplete page fragment!

To get it up and running, we wrap it inside of a html which has a header and a body:

# Html5.P.print ~output:(Buffer.add_string buf) (html (head (title (pcdata "title")) []) (body [ mycontent ]))
+# Buffer.contents buf
+
+"<!DOCTYPE html>\n<html xmlns=\"http://www.w3.org/1999/xhtml\"><head><title>title</title></head><body><div class=\"content\">This is a fabulous content.</div></body></html>"
+

The HTML content is done (in a pure way, no effects!), let's work on the binary pdfs. +Our full page source (CSS embedding is done via a string, no fancy types there (yet!?)) is on GitHub. Below we will use the render function for our content:

let render =
+  let buf = Buffer.create 500 in
+  Html5.P.print ~output:(Buffer.add_string buf) @@
+  html
+    (header "not quite so broken")
+    (body [ mycontent ]) ;
+  Cstruct.of_string @@ Buffer.contents buf
+

Binary data

There are various ways how to embed binary data into MirageOS:

connect an external (FAT) disk image; upside: works for large data, independent, can be shared with other systems; downside: an extra file to distribute onto the production machine, lots of code (block storage and file system access) which can contain directory traversals and other issues +
embed as a special ELF section; downside: not yet implemented +
embed strings in the code; upside: no deployment hassle, works everywhere for small files; downside: need to encode binary to string chunks during build and decode in the MirageOS unikernel, it breaks with large files +
likely others such as use a tar image, read it during build or runtime; wait during bootup on a network socket (or connect somewhere) to receive the static data; use a remote git repository +

We'll use the embedding. There is support for this built in the mirage tool via crunch. If you crunch "foo" in config.ml, it will create a read-only key value store (KV_RO) named static1.ml containing everything in the local "foo" directory during mirage configure. +Each file is encoded as a list of chunks, each 4096 bytes in size in ASCII (octal escaping \000 of control characters).

The API is:

val read : t -> string -> int -> int -> [ `Ok of page_aligned_buffer list | `UnknownKey of string ]
+val size : t -> string -> [ `Ok of int64 | `UnknownKey of string ]
+

The lookup needs to retrieve first the chunk list for the given filename, and then splice the fragments together and return the requested offset and length as page aligned structures. Since this is not for free, we will read our pdfs only once during startup, and then keep a reference to the full pdfs which we deliver upon request:

let read_full_kv kv name =
+  KV.size kv name >>= function
+  | `Error (KV.Unknown_key e) -> Lwt.fail (Invalid_argument e)
+  | `Ok size ->
+    KV.read kv name 0 (Int64.to_int size) >>= function
+    | `Error (KV.Unknown_key e) -> Lwt.fail (Invalid_argument e)
+    | `Ok bufs -> Lwt.return (Cstruct.concat bufs)
+
+let start kv =
+  let d_nqsb = Page.render in
+  read_full_kv kv "nqsbtls-usenix-security15.pdf" >>= fun d_usenix ->
+  read_full_kv kv "tron.pdf" >>= fun d_tron ->
+  ...
+

The funny >>= syntax notes that something is doing input/output, which might be blocking or interrupted or failing. It composes effects using an imperative style (semicolon in other languages, another term is monadic bind). The Page.render function is described above, and is pure, thus no >>=.

We now have all the resources we wanted available inside our MirageOS unikernel. There is some cost during configuration (converting binary into code), and startup (concatenating lists, lookups, rendering HTML into string representation).

Building a HTTP response

HTTP consists of headers and data, we already have the data. A HTTP header contains of an initial status line (HTTP/1.1 200 OK), and a list of keys-values, each of the form key + ": " + value + "\r\n" (+ is string concatenation). The header is separated with "\r\n\r\n" from the data:

let http_header ~status xs =
+  let headers = List.map (fun (k, v) -> k ^ ": " ^ v) xs in
+  let lines = status :: headers @ [ "\r\n" ] in
+  String.concat "\r\n" lines
+
+let header content_type =
+  http_header ~status:"HTTP/1.1 200 OK" [ ("content-type", content_type) ]
+

We also know statically (at compile time) which headers to send: content-type should be text/html for our main page, and application/pdf for the pdf files. The status code 200 is used in HTTP to signal that the request is successful. We can combine the headers and the data during startup, because our single communication channel is HTTP, and thus we don't need access to the data or headers separately (support for HTTP caching etc. is out of scope).

We are now finished with the response side of HTTP, and can emit three different resources. Now, we need to handle incoming HTTP requests and dispatch them to the resource. Let's first to a brief detour to HTTPS (and thus TLS).

Security via HTTPS

Transport layer security is a protocol on top of TCP providing an end-to-end encrypted and authenticated channel. In our setting, our web server has a certificate and a private key to authenticate itself to the clients.

A certificate is a token containing a public key, a name, a validity period, and a signature from the authority which issued the certificate. The authority is crucial here: this infrastructure only works if the client trusts the public key of the authority (and thus can verify their signature on our certificate). I used let's encrypt (actually the letsencrypt.sh client (would be great to have one natively in OCaml) to get a signed certificate, which is widely accepted by web browsers.

The MirageOS interface for TLS is that it takes a FLOW (byte stream, e.g. TCP) and provides a FLOW. Libraries can be written to be agnostic whether they use a TCP stream or a TLS session to carry data.

We need to setup our unikernel that on new connections to the HTTPS port, it should first do a TLS handshake, and afterwards talk the HTTP protocol. For a TLS handshake we need to put the certificate and private key into the unikernel, using yet another key value store (crunch "tls").

On startup we read the certificate and private key, and use that to create a TLS server config:

let start stack kv keys =
+  read_cert keys "nqsb" >>= fun c_nqsb ->
+  let config = Tls.Config.server ~certificates:(`Single c_nqsb) () in
+  S.listen_tcpv4 stack ~port:443 (tls_accept config)
+

The listen_tcpv4 is provided by the stackv4 module, and gets a stack, a port number (HTTPS uses 443), and a function which receives a flow instance.

let tls_accept cfg tcp =
+  TLS.server_of_flow cfg tcp >>= function
+    | `Error _ | `Eof -> TCP.close tcp
+    | `Ok tls  -> ...
+

The server_of_flow is provided by the Mirage TLS layer. It can fail, if the client and server do not speak a common protocol suite, ciphersuite, or if one of the sides behaves non-protocol compliant.

To wrap up, we managed to listen on the HTTPS port and establish TLS sessions for each incoming request. We have our resources available, and now need to dispatch the request onto the resource.

HTTP request handling

HTTP is a string based protocol, the first line of the request contains the method and resource which the client wants to access, GET / HTTP/1.1. We could read a single line from the client, and cut the part between GET and HTTP/1.1 to deliver the resource.

This would either need some (brittle?) string processing, or a full-blown HTTP library on our side. "I'm sorry Dave, I can't do that". There is no way we'll do string processing on data received from the network for this.

Looking a bit deeper into TLS, there is a specification for server name indication from 2003. The main purpose is to run on a single IP(v4) address multiple TLS services. The client indicates in the TLS handshake what the server name is it wants to talk to. This extension looks in wikipedia widely enough deployed.

During the TLS handshake there is already some server name information exposed, and we have a very small set of available resources. Thanks to let's encrypt, generating certificates is easy and free of cost.

And, if we're down to a single resource, we can use the same technique used by David in +the BTC Piñata: just send the resource back without waiting for a request.

Putting it all together

What we need is a hostname for each resource, and certificates and private keys for them, or a single certificate with all hostnames as alternative names.

Our TLS library supports to select a certificate chain based on the requested name (look here). The following snippet is a setup to use the nqsb.io certificate chain by default (if no SNI is provided, or none matches), and also have a usenix15 and a tron certificate chain.

let start stack keys kv =
+  read_cert keys "nqsb" >>= fun c_nqsb ->
+  read_cert keys "usenix15" >>= fun c_usenix ->
+  read_cert keys "tron" >>= fun c_tron ->
+  let config = Tls.Config.server ~certificates:(`Multiple_default (c_nqsb, [ c_usenix ; c_tron])) () in
+  S.listen_tcpv4 stack ~port:443 (tls_accept config) ;
+

Back to dispatching code. We can extract the hostname information from an opaque tls value (the epoch data is fully described here:

let extract_name tls =
+  match TLS.epoch tls with
+   | `Error -> None
+   | `Ok e -> e.Tls.Core.own_name
+

Since this TLS extension is optional, the return type will be a string option.

Now, putting the dispatch together we need a function that gets all resources and the tls state value, and returns the data to send out:

let dispatch nqsb usenix tron tls =
+  match extract_name tls with
+   | Some "usenix15.nqsb.io" -> usenix
+   | Some "tron.nqsb.io" ->  tron
+   | Some "nqsb.io" ->  nqsb
+   | _ -> nqsb
+

This is again pure code, we need to put it now into the handler, our tls_accept calls the provided function with the tls flow:

let tls_accept f cfg tcp =
+  TLS.server_of_flow cfg tcp >>= function
+   | `Error _ | `Eof -> TCP.close tcp
+   | `Ok tls  -> Tls.writev tls (f tls) >>= fun _ -> TLS.close tls
+

And our full startup code:

let start stack keys kv =
+  let d_nqsb = [ header "text/html;charset=utf-8" ; Page.render ] in
+  read_pdf kv "nqsbtls-usenix-security15.pdf" >>= fun d_usenix ->
+  read_pdf kv "tron.pdf" >>= fun d_tron ->
+  let f = dispatch d_nqsb d_usenix d_tron in
+
+  read_cert keys "nqsb" >>= fun c_nqsb ->
+  read_cert keys "usenix15" >>= fun c_usenix ->
+  read_cert keys "tron" >>= fun c_tron ->
+  let config = Tls.Config.server ~certificates:(`Multiple_default (c_nqsb, [ c_usenix ; c_tron])) () in
+
+  S.listen_tcpv4 stack ~port:443 (tls_accept f config) ;
+  S.listen stack
+

That's it, the nqsb.io contains slightly more code to log onto a console, and to redirect requests on port 80 (HTTP) to port 443 (by signaling a 301 Moved permanently HTTP status code).

Conclusion

A comparison using Firefox builtin network diagnostics shows that the waiting before receiving data is minimal (3ms, even spotted 0ms).

We do not render HTML for each request, we do not splice data together, we don't even read the client request. And I'm sure we can improve the performance even more by profiling.

We saw a journey from typed XML over key value stores, HTTP, TLS, and HTTPS. The actual application code of our unikernel serving nqsb,io is less than 100 lines of OCaml. We used MirageOS for our minimal HTTPS website, serving a single resource per hostname. We depend (directly) on the tyxml library, the mirage tool and network stack, and the tls library. That's it.

There is a long list of potential features, such as full HTTP protocol compliance (caching, favicon, ...), logging, natively getting let's encrypt certificates -- but in the web out there it is sufficient to get picked up by search engines, and the maintenance is marginal.

For a start in MirageOS unikernels, look into our mirage-skeleton project, and into the /dev/winter presentation by Matt Gray.

I'm interested in feedback, either via +twitter or via eMail.

Other updates in the MirageOS ecosystem

Canopy improvements: no bower anymore, HTTP caching support (via etags), listings now include dates, dates are now in big-endian (y-m-d) +
MirageOS call irclog from 2014-04-20 +
blog article about naive authentication service using MirageOS +
OCaml 4.03 post +

\ No newline at end of file diff --git a/atom b/atom new file mode 100644 index 0000000..92732f6 --- /dev/null +++ b/atom @@ -0,0 +1,1059 @@ +urn:uuid:981361ca-e71d-4997-a52c-baeee78e4156full stack engineer2022-10-11T12:14:07-00:00

<p>Re-developing an opam cache from scratch, as a MirageOS unikernel</p> +

2022-09-29T13:04:14-00:00<p>We at <a href="https://robur.coop">robur</a> developed <a href="https://git.robur.io/robur/opam-mirror">opam-mirror</a> in the last month and run a public opam mirror at https://opam.robur.coop (updated hourly).</p> +<h1>What is opam and why should I care?</h1> +<p><a href="https://opam.ocaml.org">Opam</a> is the OCaml package manager (also used by other projects such as <a href="https://coq.inria.fr">coq</a>). It is a source based system: the so-called repository contains the metadata (url to source tarballs, build dependencies, author, homepage, development repository) of all packages. The main repository is hosted on GitHub as <a href="https://github.com/ocaml/opam-repository">ocaml/opam-repository</a>, where authors of OCaml software can contribute (as pull request) their latest releases.</p> +<p>When opening a pull request, automated systems attempt to build not only the newly released package on various platforms and OCaml versions, but also all reverse dependencies, and also with dependencies with the lowest allowed version numbers. That's crucial since neither semantic versioning has been adapted across the OCaml ecosystem (which is tricky, for example due to local opens any newly introduced binding will lead to a major version bump), neither do many people add upper bounds of dependencies when releasing a package (nobody is keen to state "my package will not work with <a href="https://erratique.ch/software/cmdliner">cmdliner</a> in version 1.2.0").</p> +<p>So, the opam-repository holds the metadata of lots of OCaml packages (around 4000 at the moment this article was written) with lots of versions (in total 25000) that have been released. It is used by the opam client to figure out which packages to install or upgrade (using a solver that takes the version bounds into consideration).</p> +<p>Of course, opam can use other repositories (overlays) or forks thereof. So nothing stops you from using any other opam repository. The url to the source code of each package may be a tarball, or a git repository or other version control systems.</p> +<p>The vast majority of opam packages released to the opam-repository include a link to the source tarball and a cryptographic hash of the tarball. This is crucial for security (under the assumption the opam-repository has been downloaded from a trustworthy source - check back later this year for updates on <a href="/Posts/Conex">conex</a>). At the moment, there are some weak spots in respect to security: md5 is still allowed, and the hash and the tarball are downloaded from the same server: anyone who is in control of that server can inject arbitrary malicious data. As outlined above, we're working on infrastructure which fixes the latter issue.</p> +<h1>How does the opam client work?</h1> +<p>Opam, after initialisation, downloads the <code>index.tar.gz</code> from <code>https://opam.ocaml.org/index.tar.gz</code>, and uses this as the local opam universe. An <code>opam install cmdliner</code> will resolve the dependencies, and download all required tarballs. The download is first tried from the cache, and if that failed, the URL in the package file is used. The download from the cache uses the base url, appends the archive-mirror, followed by the hash algorithm, the first two characters of the has of the tarball, and the hex encoded hash of the archive, i.e. for cmdliner 1.1.1 which specifies its sha512: <code>https://opam.ocaml.org/cache/sha512/54/5478ad833da254b5587b3746e3a8493e66e867a081ac0f653a901cc8a7d944f66e4387592215ce25d939be76f281c4785702f54d4a74b1700bc8838a62255c9e</code>.</p> +<h1>How does the opam repository work?</h1> +<p>According to DNS, opam.ocaml.org is a machine at amazon. It likely, apart from the website, uses <code>opam admin index</code> periodically to create the index tarball and the cache. There's an observable delay between a package merge in the opam-repository and when it shows up at opam.ocaml.org. Recently, there was <a href="https://discuss.ocaml.org/t/opam-ocaml-org-is-currently-down-is-that-where-indices-are-kept-still/">a reported downtime</a>.</p> +<p>Apart from being a single point of failure, if you're compiling a lot of opam projects (e.g. a continuous integration / continuous build system), it makes sense from a network usage (and thus sustainability perspective) to move the cache closer to where you need the source archives. We're also organising the MirageOS <a href="http://retreat.mirage.io">hack retreats</a> in a northern African country with poor connectivity - so if you gather two dozen camels you better bring your opam repository cache with you to reduce the bandwidth usage (NB: this requires at the moment cooperation of all participants to configure their default opam repository accordingly).</p> +<h1>Re-developing "opam admin create" as MirageOS unikernel</h1> +<p>The need for a local opam cache at our <a href="https://builds.robur.coop">reproducible build infrastructure</a> and the retreats, we decided to develop <a href="https://git.robur.io/robur/opam-mirror">opam-mirror</a> as a <a href="https://mirage.io">MirageOS unikernel</a>. Apart from a useful showcase using persistent storage (that won't fit into memory), and having fun while developing it, our aim was to reduce our time spent on system administration (the <code>opam admin index</code> is only one part of the story, it needs a Unix system and a webserver next to it - plus remote access for doing software updates - which has quite some attack surface.</p> +<p>Another reason for re-developing the functionality was that the opam code (what opam admin index actually does) is part of the opam source code, which totals to 50_000 lines of code -- looking up whether one or all checksums are verified before adding the tarball to the cache, was rather tricky.</p> +<p>In earlier years, we avoided persistent storage and block devices in MirageOS (by embedding it into the source code with <a href="https://github.com/mirage/ocaml-crunch">crunch</a>, or using a remote git repository), but recent development, e.g. of <a href="https://somerandomidiot.com/blog/2022/03/04/chamelon/">chamelon</a> sparked some interest in actually using file systems and figuring out whether MirageOS is ready in that area. A month ago we started the opam-mirror project.</p> +<p>Opam-mirror takes a remote repository URL, and downloads all referenced archives. It serves as a cache and opam-repository - and does periodic updates from the remote repository. The idea is to validate all available checksums and store the tarballs only once, and store overlays (as maps) from the other hash algorithms.</p> +<h1>Code development and improvements</h1> +<p>Initially, our plan was to use <a href="https://github.com/mirage/ocaml-git">ocaml-git</a> for pulling the repository, <a href="https://github.com/yomimono/chamelon">chamelon</a> for persistent storage, and <a href="https://github.com/inhabitedtype/httpaf">httpaf</a> as web server. With <a href="https://github.com/mirage/ocaml-tar">ocaml-tar</a> recent support of <a href="https://github.com/mirage/ocaml-tar/pull/88">gzip</a> we should be all set, and done within a few days.</p> +<p>There is already a gap in the above plan: which http client to use - in the best case something similar to our <a href="https://github.com/roburio/http-lwt-client">http-lwt-client</a> - in MirageOS: it should support HTTP 1.1 and HTTP 2, TLS (with certificate validation), and using <a href="https://github.com/roburio/happy-eyeballs">happy-eyeballs</a> to seemlessly support both IPv6 and legacy IPv4. Of course it should follow redirect, without that we won't get far in the current Internet.</p> +<p>On the path (over the last month), we fixed file descriptor leaks (memory leaks) in <a href="https://github.com/dinosaure/paf-le-chien">paf</a> -- which is used as a runtime for httpaf and h2.</p> +<p>Then we ran into some trouble with chamelon (<a href="https://github.com/yomimono/chamelon/issues/11">out of memory</a>, some degraded peformance, it reporting out of disk space), and re-thought our demands for opam-mirror. Since the cache is only ever growing (new packages are released), there's no need to ever remove anything: it is append-only. Once we figured that out, we investigated what needs to be done in ocaml-tar (where tar is in fact a tape archive, and was initially designed as file format to be appended to) to support appending to an archive.</p> +<p>We also re-thought our bandwidth usage, and instead of cloning the git remote at startup, we developed <a href="https://git.robur.io/robur/git-kv">git-kv</a> which can dump and restore the git state.</p> +<p>Also, initially we computed all hashes of all tarballs, but with the size increasing (all archives are around 7.5GB) this lead to a major issue of startup time (around 5 minutes on a laptop), so we wanted to save and restore the maps as well.</p> +<p>Since neither git state nor the maps are suitable for tar's append-only semantics, and we didn't want to investigate yet another file system - such as <a href="https://github.com/mirage/ocaml-fat">fat</a> may just work fine, but the code looks slightly bitrot, and the reported issues and non-activity doesn't make this package very trustworthy from our point of view. Instead, we developed <a href="https://github.com/reynir/mirage-block-partition">mirage-block-partition</a> to partition a block device into two. Then we just store the maps and the git state at the end - the end of a tar archive is 2 blocks of zeroes, so stuff at the far end aren't considered by any tooling. Extending the tar archive is also possible, only the maps and git state needs to be moved to the end (or recomputed). As file system, we developed <a href="https://git.robur.io/reynir/oneffs">oneffs</a> which stores a single value on the block device.</p> +<p>We observed a high memory usage, since each requested archive was first read from the block device into memory, and then sent out. Thanks to Pierre Alains <a href="https://github.com/mirage/mirage-kv/pull/28">recent enhancements</a> of the mirage-kv API, there is a <code>get_partial</code>, that we use to chunk-wise read the archive and send it via HTTP. Now, the memory usage is around 20MB (the git repository and the generated tarball are kept in memory).</p> +<p>What is next? Downloading and writing to the tar archive could be done chunk-wise as well; also dumping and restoring the git state is quite CPU intensive, we would like to improve that. Adding the TLS frontend (currently done on our site by our TLS termination proxy <a href="https://github.com/roburio/tlstunnel">tlstunnel</a>) similar to how <a href="https://github.com/roburio/unipi">unipi</a> does it, including let's encrypt provisioning -- should be straightforward (drop us a note if you'd be interesting in that feature).</p> +<h1>Conclusion</h1> +<p>To conclude, we managed within a month to develop this opam-mirror cache from scratch. It has a reasonable footprint (CPU and memory-wise), is easy to maintain and easy to update - if you want to use it, we also provide <a href="https://builds.robur.coop/job/opam-mirror">reproducible binaries</a> for solo5-hvt. You can use our opam mirror with <code>opam repository set-url default https://opam.robur.coop</code> (revert to the other with <code>opam repository set-url default https://opam.ocaml.org</code>) or use it as a backup with <code>opam repository add robur --rank 2 https://opam.robur.coop</code>.</p> +<p>Please reach out to us (at team AT robur DOT coop) if you have feedback and suggestions. We are a non-profit company, and rely on <a href="https://robur.coop/Donate">donations</a> for doing our work - everyone can contribute.</p> +urn:uuid:0dbd251f-32c7-57bd-8e8f-7392c0833a09Mirroring the opam repository and all tarballs2022-10-11T12:14:07-00:00hannes

<p>How to monitor your MirageOS unikernel with albatross and monitoring-experiments</p> +

2022-03-08T11:26:31-00:00<h1>Introduction to monitoring</h1> +<p>At <a href="https://robur.coop">robur</a> we use a range of MirageOS unikernels. Recently, we worked on improving the operations story thereof. One part is shipping binaries using our <a href="https://builds.robur.coop">reproducible builds infrastructure</a>. Another part is, once deployed we want to observe what is going on.</p> +<p>I first got into touch with monitoring - collecting and graphing metrics - with <a href="https://oss.oetiker.ch/mrtg/">MRTG</a> and <a href="https://munin-monitoring.org/">munin</a> - and the simple network management protocol <a href="https://en.wikipedia.org/wiki/Simple_Network_Management_Protocol">SNMP</a>. From the whole system perspective, I find it crucial that the monitoring part of a system does not add pressure. This favours a push-based design, where reporting is done at the disposition of the system.</p> +<p>The rise of monitoring where graphs are done dynamically (such as <a href="https://grafana.com/">Grafana</a>) and can be programmed (with a query language) by the operator are very neat, it allows to put metrics in relation after they have been recorded - thus if there's a thesis why something went berserk, you can graph the collected data from the past and prove or disprove the thesis.</p> +<h1>Monitoring a MirageOS unikernel</h1> +<p>From the operational perspective, taking security into account - either the data should be authenticated and integrity-protected, or being transmitted on a private network. We chose the latter, there's a private network interface only for monitoring. Access to that network is only granted to the unikernels and metrics collector.</p> +<p>For MirageOS unikernels, we use the <a href="https://github.com/mirage/metrics">metrics</a> library - which design shares the idea of <a href="https://erratique.ch/software/logs">logs</a> that only if there's a reporter registered, work is performed. We use the Influx line protocol via TCP to report via <a href="https://www.influxdata.com/time-series-platform/telegraf/">Telegraf</a> to <a href="https://www.influxdata.com/">InfluxDB</a>. But due to the design of <a href="https://github.com/mirage/metrics">metrics</a>, other reporters can be developed and used -- prometheus, SNMP, your-other-favourite are all possible.</p> +<p>Apart from monitoring metrics, we use the same network interface for logging via syslog. Since the logs library separates the log message generation (in the OCaml libraries) from the reporting, we developed <a href="https://github.com/hannesm/logs-syslog">logs-syslog</a>, which registers a log reporter sending each log message to a syslog sink.</p> +<p>We developed a small library for metrics reporting of a MirageOS unikernel into the <a href="https://github.com/roburio/monitoring-experiments">monitoring-experiments</a> package - which also allows to dynamically adjust log level and disable or enable metrics sources.</p> +<h2>Required components</h2> +<p>Install from your operating system the packages providing telegraf, influxdb, and grafana.</p> +<p>Setup telegraf to contain a socket listener:</p> +<pre><code>[[inputs.socket_listener]] + service_address = "tcp://192.168.42.14:8094" + keep_alive_period = "5m" + data_format = "influx" +</code></pre> +<p>Use a unikernel that reports to Influx (below the heading "Unikernels (with metrics reported to Influx)" on <a href="https://builds.robur.coop">builds.robur.coop</a>) and provide <code>--monitor=192.168.42.14</code> as boot parameter. Conventionally, these unikernels expect a second network interface (on the "management" bridge) where telegraf (and a syslog sink) are running. You'll need to pass <code>--net=management</code> and <code>--arg='--management-ipv4=192.168.42.x/24'</code> to albatross-client-local.</p> +<p>Albatross provides a <code>albatross-influx</code> daemon that reports information from the host system about the unikernels to influx. Start it with <code>--influx=192.168.42.14</code>.</p> +<h2>Adding monitoring to your unikernel</h2> +<p>If you want to extend your own unikernel with metrics, follow along these lines.</p> +<p>An example is the <a href="https://github.com/roburio/dns-primary-git">dns-primary-git</a> unikernel, where on the branch <code>future</code> we have a single commit ahead of main that adds monitoring. The difference is in the unikernel configuration and the main entry point. See the <a href="https://builds.robur.coop/job/dns-primary-git-monitoring/build/latest/">binary builts</a> in contrast to the <a href="https://builds.robur.coop/job/dns-primary-git/build/latest/">non-monitoring builts</a>.</p> +<p>In config, three new command line arguments are added: <code>--monitor=IP</code>, <code>--monitor-adjust=PORT</code> <code>--syslog=IP</code> and <code>--name=STRING</code>. In addition, the package <code>monitoring-experiments</code> is required. And a second network interface <code>management_stack</code> using the prefix <code>management</code> is required and passed to the unikernel. Since the syslog reporter requires a console (to report when logging fails), also a console is passed to the unikernel. Each reported metrics includes a tag <code>vm=<name></code> that can be used to distinguish several unikernels reporting to the same InfluxDB.</p> +<p>Command line arguments:</p> +<pre><code class="language-patch"> let doc = Key.Arg.info ~doc:"The fingerprint of the TLS certificate." [ "tls-cert-fingerprint" ] in + Key.(create "tls_cert_fingerprint" Arg.(opt (some string) None doc)) + ++let monitor = ++ let doc = Key.Arg.info ~doc:"monitor host IP" ["monitor"] in ++ Key.(create "monitor" Arg.(opt (some ip_address) None doc)) ++ ++let monitor_adjust = ++ let doc = Key.Arg.info ~doc:"adjust monitoring (log level, ..)" ["monitor-adjust"] in ++ Key.(create "monitor_adjust" Arg.(opt (some int) None doc)) ++ ++let syslog = ++ let doc = Key.Arg.info ~doc:"syslog host IP" ["syslog"] in ++ Key.(create "syslog" Arg.(opt (some ip_address) None doc)) ++ ++let name = ++ let doc = Key.Arg.info ~doc:"Name of the unikernel" ["name"] in ++ Key.(create "name" Arg.(opt string "ns.nqsb.io" doc)) ++ + let mimic_impl random stackv4v6 mclock pclock time = + let tcpv4v6 = tcpv4v6_of_stackv4v6 $ stackv4v6 in + let mhappy_eyeballs = mimic_happy_eyeballs $ random $ time $ mclock $ pclock $ stackv4v6 in +</code></pre> +<p>Requiring <code>monitoring-experiments</code>, registering command line arguments:</p> +<pre><code class="language-patch"> package ~min:"3.7.0" ~max:"3.8.0" "git-mirage"; + package ~min:"3.7.0" "git-paf"; + package ~min:"0.0.8" ~sublibs:["mirage"] "paf"; ++ package "monitoring-experiments"; ++ package ~sublibs:["mirage"] ~min:"0.3.0" "logs-syslog"; + ] in + foreign +- ~keys:[Key.abstract remote_k ; Key.abstract axfr] ++ ~keys:[ ++ Key.abstract remote_k ; Key.abstract axfr ; ++ Key.abstract name ; Key.abstract monitor ; Key.abstract monitor_adjust ; Key.abstract syslog ++ ] + ~packages +</code></pre> +<p>Added console and a second network stack to <code>foreign</code>:</p> +<pre><code class="language-patch"> "Unikernel.Main" +- (random @-> pclock @-> mclock @-> time @-> stackv4v6 @-> mimic @-> job) ++ (console @-> random @-> pclock @-> mclock @-> time @-> stackv4v6 @-> mimic @-> stackv4v6 @-> job) ++ +</code></pre> +<p>Passing a console implementation (<code>default_console</code>) and a second network stack (with <code>management</code> prefix) to <code>register</code>:</p> +<pre><code class="language-patch">+let management_stack = generic_stackv4v6 ~group:"management" (netif ~group:"management" "management") + + let () = + register "primary-git" +- [dns_handler $ default_random $ default_posix_clock $ default_monotonic_clock $ +- default_time $ net $ mimic_impl] ++ [dns_handler $ default_console $ default_random $ default_posix_clock $ default_monotonic_clock $ ++ default_time $ net $ mimic_impl $ management_stack] +</code></pre> +<p>Now, in the unikernel module the functor changes (console and second network stack added):</p> +<pre><code class="language-patch">@@ -4,17 +4,48 @@ + + open Lwt.Infix + +-module Main (R : Mirage_random.S) (P : Mirage_clock.PCLOCK) (M : Mirage_clock.MCLOCK) (T : Mirage_time.S) (S : Mirage_stack.V4V6) (_ : sig e +nd) = struct ++module Main (C : Mirage_console.S) (R : Mirage_random.S) (P : Mirage_clock.PCLOCK) (M : Mirage_clock.MCLOCK) (T : Mirage_time.S) (S : Mirage +_stack.V4V6) (_ : sig end) (Management : Mirage_stack.V4V6) = struct + + module Store = Irmin_mirage_git.Mem.KV(Irmin.Contents.String) + module Sync = Irmin.Sync(Store) +</code></pre> +<p>And in the <code>start</code> function, the command line arguments are processed and used to setup syslog and metrics monitoring to the specified addresses. Also, a TCP listener is waiting for monitoring and logging adjustments if <code>--monitor-adjust</code> was provided:</p> +<pre><code class="language-patch"> module D = Dns_server_mirage.Make(P)(M)(T)(S) ++ module Monitoring = Monitoring_experiments.Make(T)(Management) ++ module Syslog = Logs_syslog_mirage.Udp(C)(P)(Management) + +- let start _rng _pclock _mclock _time s ctx = ++ let start c _rng _pclock _mclock _time s ctx management = ++ let hostname = Key_gen.name () in ++ (match Key_gen.syslog () with ++ | None -> Logs.warn (fun m -> m "no syslog specified, dumping on stdout") ++ | Some ip -> Logs.set_reporter (Syslog.create c management ip ~hostname ())); ++ (match Key_gen.monitor () with ++ | None -> Logs.warn (fun m -> m "no monitor specified, not outputting statistics") ++ | Some ip -> Monitoring.create ~hostname ?listen_port:(Key_gen.monitor_adjust ()) ip management); + connect_store ctx >>= fun (store, upstream) -> + load_git None store upstream >>= function + | Error (`Msg msg) -> +</code></pre> +<p>Once you compiled the unikernel (or downloaded a binary with monitoring), and start that unikernel by passing <code>--net:service=tap0</code> and <code>--net:management=tap10</code> (or whichever your <code>tap</code> interfaces are), and as unikernel arguments <code>--ipv4=<my-ip-address></code> and <code>--management-ipv4=192.168.42.2/24</code> for IPv4 configuration, <code>--monitor=192.168.42.14</code>, <code>--syslog=192.168.42.10</code>, <code>--name=my.unikernel</code>, <code>--monitor-adjust=12345</code>.</p> +<p>With this, your unikernel will report metrics using the influx protocol to 192.168.42.14 on port 8094 (every 10 seconds), and syslog messages via UDP to 192.168.0.10 (port 514). You should see your InfluxDB getting filled and syslog server receiving messages.</p> +<p>When you configure <a href="https://grafana.com/docs/grafana/latest/getting-started/getting-started-influxdb/">Grafana to use InfluxDB</a>, you'll be able to see the data in the data sources.</p> +<p>Please reach out to us (at team AT robur DOT coop) if you have feedback and suggestions.</p> +urn:uuid:b8f1fa5b-d8dd-5a54-a9e4-064b9dcd053eAll your metrics belong to influx2022-03-08T11:26:31-00:00hannes

<p>Finally, we provide reproducible binary MirageOS unikernels together with packages to reproduce them and setup your own builder</p> +

2021-06-30T13:13:37-00:00<h2>Introduction</h2> +<p>MirageOS development focus has been a lot on tooling and the developer experience, but to accomplish <a href="https://robur.coop">our</a> goal to "get MirageOS into production", we need to lower the barrier. This means for us to release binary unikernels. As described <a href="/Posts/NGI">earlier</a>, we received a grant for "Deploying MirageOS" from <a href="https://pointer.ngi.eu">NGI Pointer</a> to work on the required infrastructure. This is joint work with <a href="https://reynir.dk/">Reynir</a>.</p> +<p>We provide at <a href="https://builds.robur.coop">builds.robur.coop</a> binary unikernel images (and supplementary software). Doing binary releases of MirageOS unikernels is challenging in two aspects: firstly to be useful for everyone, a binary unikernel should not contain any configuration (such as private keys, certificates, etc.). Secondly, the binaries should be <a href="https://reproducible-builds.org">reproducible</a>. This is crucial for security; everyone can reproduce the exact same binary and verify that our build service did only use the sources. No malware or backdoors included.</p> +<p>This post describes how you can deploy MirageOS unikernels without compiling it from source, then dives into the two issues outlined above - configuration and reproducibility - and finally describes how to setup your own reproducible build infrastructure for MirageOS, and how to bootstrap it.</p> +<h2>Deploying MirageOS unikernels from binary</h2> +<p>To execute a MirageOS unikernel, apart from a hypervisor (Xen/KVM/Muen), a tender (responsible for allocating host system resources and passing these to the unikernel) is needed. Using virtio, this is conventionally done with qemu on Linux, but its code size (and attack surface) is huge. For MirageOS, we develop <a href="https://github.com/solo5/solo5">Solo5</a>, a minimal tender. It supports <em>hvt</em> - hardware virtualization (Linux KVM, FreeBSD BHyve, OpenBSD VMM), <em>spt</em> - sandboxed process (a tight seccomp ruleset (only a handful of system calls allowed, no hardware virtualization needed), Linux only). Apart from that, <a href="https://muen.sk"><em>muen</em></a> (a hypervisor developed in Ada), <em>virtio</em> (for some cloud deployments), and <em>xen</em> (PVHv2 or Qubes 4.0) - <a href="https://github.com/Solo5/solo5/blob/master/docs/building.md">read more</a>. We deploy our unikernels as hvt with FreeBSD BHyve as hypervisor.</p> +<p>On <a href="https://builds.robur.coop">builds.robur.coop</a>, next to the unikernel images, <a href="https://builds.robur.coop/job/solo5-hvt/"><em>solo5-hvt</em> packages</a> are provided - download the binary and install it. A <a href="https://github.com/NixOS/nixpkgs/tree/master/pkgs/os-specific/solo5">NixOS package</a> is already available - please note that <a href="https://github.com/Solo5/solo5/pull/494">soon</a> packaging will be much easier (and we will work on packages merged into distributions).</p> +<p>When the tender is installed, download a unikernel image (e.g. the <a href="https://builds.robur.coop/job/traceroute/build/latest/">traceroute</a> described in <a href="/Posts/Traceroute">an earlier post</a>), and execute it:</p> +<pre><code>$ solo5-hvt --net:service=tap0 -- traceroute.hvt --ipv4=10.0.42.2/24 --ipv4-gateway=10.0.42.1 +</code></pre> +<p>If you plan to orchestrate MirageOS unikernels, you may be interested in <a href="https://github.com/roburio/albatross">albatross</a> - we provide <a href="https://builds.robur.coop/job/albatross/">binary packages as well for albatross</a>. An upcoming post will go into further details of how to setup albatross.</p> +<h2>MirageOS configuration</h2> +<p>A MirageOS unikernel has a specific purpose - composed of OCaml libraries - selected at compile time, which allows to only embed the required pieces. This reduces the attack surface drastically. At the same time, to be widely useful to multiple organisations, no configuration data must be embedded into the unikernel.</p> +<p>Early MirageOS unikernels such as <a href="https://github.com/mirage/mirage-www">mirage-www</a> embed content (blog posts, ..) and TLS certificates and private keys in the binary (using <a href="https://github.com/mirage/ocaml-crunch">crunch</a>). The <a href="https://github.com/mirage/qubes-mirage-firewall">Qubes firewall</a> (read the <a href="http://roscidus.com/blog/blog/2016/01/01/a-unikernel-firewall-for-qubesos/">blog post by Thomas</a> for more information) used to include the firewall rules until <a href="https://github.com/mirage/qubes-mirage-firewall/releases/tag/v0.6">v0.6</a> in the binary, since <a href="https://github.com/mirage/qubes-mirage-firewall/tree/v0.7">v0.7</a> the rules are read dynamically from QubesDB. This is big usability improvement.</p> +<p>We have several possibilities to provide configuration information in MirageOS, on the one hand via boot parameters (can be pre-filled at development time, and further refined at configuration time, but those passed at boot time take precedence). Boot parameters have a length limitation.</p> +<p>Another option is to <a href="https://github.com/roburio/tlstunnel/">use a block device</a> - where the TLS reverse proxy stores the configuration, modifiable via a TCP control socket (authentication using a shared hmac secret).</p> +<p>Several other unikernels, such as <a href="https://github.com/Engil/Canopy">this website</a> and <a href="https://github.com/roburio/caldav">our CalDAV server</a>, store the content in a remote git repository. The git URI and credentials (private key seed, host key fingerprint) are passed via boot parameter.</p> +<p>Finally, another option that we take advantage of is to introduce a post-link step that rewrites the binary to embed configuration. The tool <a href="https://github.com/dinosaure/caravan">caravan</a> developed by Romain that does this rewrite is used by our <a href="https://github.com/roburio/openvpn/tree/robur/mirage-router">openvpn router</a> (<a href="https://builds.robur.coop/job/openvpn-router/build/latest/">binary</a>).</p> +<p>In the future, some configuration information - such as monitoring system, syslog sink, IP addresses - may be done via DHCP on one of the private network interfaces - this would mean that the DHCP server has some global configuration option, and the unikernels no longer require that many boot parameters. Another option we want to investigate is where the tender shares a file as read-only memory-mapped region from the host system to the guest system - but this is tricky considering all targets above (especially virtio and muen).</p> +<h2>Behind the scenes: reproducible builds</h2> +<p>To provide a high level of assurance and trust, if you distribute binaries in 2021, you should have a recipe how they can be reproduced in a bit-by-bit identical way. This way, different organisations can run builders and rebuilders, and a user can decide to only use a binary if it has been reproduced by multiple organisations in different jurisdictions using different physical machines - to avoid malware being embedded in the binary.</p> +<p>For a reproduction to be successful, you need to collect the checksums of all sources that contributed to the built, together with other things (host system packages, environment variables, etc.). Of course, you can record the entire OS and sources as a tarball (or file system snapshot) and distribute that - but this may be suboptimal in terms of bandwidth requirements.</p> +<p>With opam, we already have precise tracking which opam packages are used, and since opam 2.1 the <code>opam switch export</code> includes <a href="https://github.com/ocaml/opam/pull/4040">extra-files (patches)</a> and <a href="https://github.com/ocaml/opam/pull/4055">records the VCS version</a>. Based on this functionality, <a href="https://github.com/roburio/orb">orb</a>, an alternative command line application using the opam-client library, can be used to collect (a) the switch export, (b) host system packages, and (c) the environment variables. Only required environment variables are kept, all others are unset while conducting a build. The only required environment variables are <code>PATH</code> (sanitized with an allow list, <code>/bin</code>, <code>/sbin</code>, with <code>/usr</code>, <code>/usr/local</code>, and <code>/opt</code> prefixes), and <code>HOME</code>. To enable Debian's <code>apt</code> to install packages, <code>DEBIAN_FRONTEND</code> is set to <code>noninteractive</code>. The <code>SWITCH_PATH</code> is recorded to allow orb to use the same path during a rebuild. The <code>SOURCE_DATE_EPOCH</code> is set to enable tools that record a timestamp to use a static one. The <code>OS*</code> variables are only used for recording the host OS and version.</p> +<p>The goal of reproducible builds can certainly be achieved in several ways, including to store all sources and used executables in a huge tarball (or docker container), which is preserved for rebuilders. The question of minimal trusted computing base and how such a container could be rebuild from sources in reproducible way are open.</p> +<p>The opam-repository is a community repository, where packages are released to on a daily basis by a lot of OCaml developers. Package dependencies usually only use lower bounds of other packages, and the continuous integration system of the opam repository takes care that upon API changes all reverse dependencies include the right upper bounds. Using the head commit of opam-repository usually leads to a working package universe.</p> +<p>For our MirageOS unikernels, we don't want to stay behind with ancient versions of libraries. That's why our automated building is done on a daily basis with the head commit of opam-repository. Since our unikernels are not part of the main opam repository (they include the configuration information which target to use, e.g. <em>hvt</em>), and we occasionally development versions of opam packages, we use <a href="https://git.robur.io/robur/unikernel-repo">the unikernel-repo</a> as overlay.</p> +<p>If no dependent package got a new release, the resulting binary has the same checksum. If any dependency was released with a newer release, this is picked up, and eventually the checksum changes.</p> +<p>Each unikernel (and non-unikernel) job (e.g. <a href="https://builds.robur.coop/job/dns-primary-git/build/latest/">dns-primary</a> outputs some artifacts:</p> +<ul> +<li>the <a href="https://builds.robur.coop/job/dns-primary-git/build/latest/f/bin/primary_git.hvt">binary image</a> (in <code>bin/</code>, unikernel image, OS package) +</li> +<li>the <a href="https://builds.robur.coop/job/dns-primary-git/build/latest/f/build-environment"><code>build-environment</code></a> containing the environment variables used for this build +</li> +<li>the <a href="https://builds.robur.coop/job/dns-primary-git/build/latest/f/system-packages"><code>system-packages</code></a> containing all packages installed on the host system +</li> +<li>the <a href="https://builds.robur.coop/job/dns-primary-git/build/latest/f/opam-switch"><code>opam-switch</code></a> that contains all opam packages, including git commit or tarball with checksum, and potentially extra patches, used for this build +</li> +<li>a job script and console output +</li> +</ul> +<p>To reproduce such a built, you need to get the same operating system (OS, OS_FAMILY, OS_DISTRIBUTION, OS_VERSION in build-environment), the same set of system packages, and then you can <code>orb rebuild</code> which sets the environment variables and installs the opam packages from the opam-switch.</p> +<p>You can <a href="https://builds.robur.coop/job/dns-primary-git/">browse</a> the different builds, and if there are checksum changes, you can browse to a diff between the opam switches to reason whether the checksum change was intentional (e.g. <a href="https://builds.robur.coop/compare/ba9ab091-9400-4e8d-ad37-cf1339114df8/23341f6b-cd26-48ab-9383-e71342455e81/opam-switch">here</a> the checksum of the unikernel changed when the x509 library was updated).</p> +<p>The opam reproducible build infrastructure is driven by:</p> +<ul> +<li><a href="https://github.com/roburio/orb">orb</a> conducting reproducible builds (<a href="https://builds.robur.coop/job/orb/">packages</a>) +</li> +<li><a href="https://github.com/roburio/builder">builder</a> scheduling builds in contained environments (<a href="https://builds.robur.coop/job/builder/">packages</a>) +</li> +<li><a href="https://git.robur.io/robur/builder-web">builder-web</a> storing builds in a database and providing a HTTP interface (<a href="https://builds.robur.coop/job/builder-web/">packages</a>) +</li> +</ul> +<p>These tools are themselves reproducible, and built on a daily basis. The infrastructure executing the build jobs installs the most recent packages of orb and builder before conducting a build. This means that our build infrastructure is reproducible as well, and uses the latest code when it is released.</p> +<h2>Conclusion</h2> +<p>Thanks to NGI funding we now have reproducible MirageOS binary builds available at <a href="https://builds.robur.coop">builds.robur.coop</a>. The underlying infrastructure is reproducible, available for multiple platforms (Ubuntu using docker, FreeBSD using jails), and can be easily bootstrapped from source (once you have OCaml and opam working, getting builder and orb should be easy). All components are open source software, mostly with permissive licenses.</p> +<p>We also have an index over sha-256 checksum of binaries - in the case you find a running unikernel image where you forgot which exact packages were used, you can do a reverse lookup.</p> +<p>We are aware that the web interface can be improved (PRs welcome). We will also work on the rebuilder setup and run some rebuilds.</p> +<p>Please reach out to us (at team AT robur DOT coop) if you have feedback and suggestions.</p> +urn:uuid:331831d8-6093-5dd7-9164-445afff953cbDeploying binary MirageOS unikernels2021-11-15T11:17:23-00:00hannes

<p>Elliptic curves (ECDSA/ECDH) are supported in a maintainable and secure way.</p> +

2021-04-23T13:33:06-00:00<h2>Introduction</h2> +<p>Tl;DR: mirage-crypto-ec, with x509 0.12.0, and tls 0.13.0, provide fast and secure elliptic curve support in OCaml and MirageOS - using the verified <a href="https://github.com/mit-plv/fiat-crypto/">fiat-crypto</a> stack (Coq to OCaml to executable which generates C code that is interfaced by OCaml). In x509, a long standing issue (countryName encoding), and archive (PKCS 12) format is now supported, in addition to EC keys. In tls, ECDH key exchanges are supported, and ECDSA and EdDSA certificates.</p> +<h2>Elliptic curve cryptography</h2> +<p><a href="https://mirage.io/blog/tls-1-3-mirageos">Since May 2020</a>, our <a href="https://usenix15.nqsb.io">OCaml-TLS</a> stack supports TLS 1.3 (since tls version 0.12.0 on opam).</p> +<p>TLS 1.3 requires elliptic curve cryptography - which was not available in <a href="https://github.com/mirage/mirage-crypto">mirage-crypto</a> (the maintained fork of <a href="https://github.com/mirleft/ocaml-nocrypto">nocrypto</a>).</p> +<p>There are two major uses of elliptic curves: <a href="https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman">key exchange (ECDH)</a> for establishing a shared secret over an insecure channel, and <a href="https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm">digital signature (ECDSA)</a> for authentication, integrity, and non-repudiation. (Please note that the construction of digital signatures on Edwards curves (Curve25519, Ed448) is called EdDSA instead of ECDSA.)</p> +<p>Elliptic curve cryptoraphy is <a href="https://eprint.iacr.org/2020/615">vulnerable</a> <a href="https://raccoon-attack.com/">to</a> <a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5407">various</a> <a href="https://github.com/mimoo/timing_attack_ecdsa_tls">timing</a> <a href="https://minerva.crocs.fi.muni.cz/">attacks</a> - have a read of the <a href="https://blog.trailofbits.com/2020/06/11/ecdsa-handle-with-care/">overview article on ECDSA</a>. When implementing elliptic curve cryptography, it is best to avoid these known attacks. Gladly, there are some projects which address these issues by construction.</p> +<p>In addition, to use the code in MirageOS, it should be boring C code: no heap allocations, only using a very small amount of C library functions -- the code needs to be compiled in an environment with <a href="https://github.com/mirage/ocaml-freestanding/tree/v0.6.4/nolibc">nolibc</a>.</p> +<p>Two projects started in semantics, to solve the issue from the grounds up: <a href="https://github.com/mit-plv/fiat-crypto/">fiat-crypto</a> and <a href="https://github.com/project-everest/hacl-star/">hacl-star</a>: their approach is to use a proof system (<a href="https://coq.inria.fr">Coq</a> or <a href="https://www.fstar-lang.org/">F*</a> to verify that the code executes in constant time, not depending on data input. Both projects provide as output of their proof systems C code.</p> +<p>For our initial TLS 1.3 stack, <a href="https://github.com/pascutto/">Clément</a>, <a href="https://github.com/NathanReb/">Nathan</a> and <a href="https://github.com/emillon/">Etienne</a> developed <a href="https://github.com/mirage/fiat">fiat-p256</a> and <a href="https://github.com/mirage/hacl">hacl_x5519</a>. Both were one-shot interfaces for a narrow use case (ECDH for NIST P-256 and X25519), worked well for their purpose, and allowed to gather some experience from the development side.</p> +<h3>Changed requirements</h3> +<p>Revisiting our cryptography stack with the elliptic curve perspective had several reasons, on the one side the customer project <a href="https://www.nitrokey.com/products/nethsm">NetHSM</a> asked for feasibility of ECDSA/EdDSA for various elliptic curves, on the other side <a href="https://github.com/mirage/ocaml-dns/pull/251">DNSSec</a> uses elliptic curve cryptography (ECDSA), and also <a href="https://www.wireguard.com/">wireguard</a> relies on elliptic curve cryptography. The number of X.509 certificates using elliptic curves is increasing, and we don't want to leave our TLS stack in a state where it can barely talk to a growing number of services on the Internet.</p> +<p>Looking at <a href="https://github.com/project-everest/hacl-star/"><em>hacl-star</em></a>, their <a href="https://hacl-star.github.io/Supported.html">support</a> is limited to P-256 and Curve25519, any new curve requires writing F*. Another issue with hacl-star is C code quality: their C code does neither <a href="https://github.com/mirage/hacl/issues/46">compile with older C compilers (found on Oracle Linux 7 / CentOS 7)</a>, nor when enabling all warnings (> 150 are generated). We consider the C compiler as useful resource to figure out undefined behaviour (and other problems), and when shipping C code we ensure that it compiles with <code>-Wall -Wextra -Wpedantic --std=c99 -Werror</code>. The hacl project <a href="https://github.com/mirage/hacl/tree/master/src/kremlin">ships</a> a bunch of header files and helper functions to work on all platforms, which is a clunky <code>ifdef</code> desert. The hacl approach is to generate a whole algorithm solution: from arithmetic primitives, group operations, up to cryptographic protocol - everything included.</p> +<p>In contrast, <a href="https://github.com/mit-plv/fiat-crypto/"><em>fiat-crypto</em></a> is a Coq development, which as part of compilation (proof verification) generates executables (via OCaml code extraction from Coq). These executables are used to generate modular arithmetic (as C code) given a curve description. The <a href="https://github.com/mirage/mirage-crypto/tree/main/ec/native">generated C code</a> is highly portable, independent of platform (word size is taken as input) - it only requires a <code><stdint.h></code>, and compiles with all warnings enabled (once <a href="https://github.com/mit-plv/fiat-crypto/pull/906">a minor PR</a> got merged). Supporting a new curve is simple: generate the arithmetic code using fiat-crypto with the new curve description. The downside is that group operations and protocol needs to implemented elsewhere (and is not part of the proven code) - gladly this is pretty straightforward to do, especially in high-level languages.</p> +<h3>Working with fiat-crypto</h3> +<p>As mentioned, our initial <a href="https://github.com/mirage/fiat">fiat-p256</a> binding provided ECDH for the NIST P-256 curve. Also, BoringSSL uses fiat-crypto for ECDH, and developed the code for group operations and cryptographic protocol on top of it.</p> +<p>The work needed was (a) ECDSA support and (b) supporting more curves (let's focus on NIST curves). For ECDSA, the algorithm requires modular arithmetics in the field of the group order (in addition to the prime). We generate these primitives with fiat-crypto (named <code>npYYY_AA</code>) - that required <a href="https://github.com/mit-plv/fiat-crypto/commit/e31a36d5f1b20134e67ccc5339d88f0ff3cb0f86">a small fix in decoding hex</a>. Fiat-crypto also provides inversion <a href="https://github.com/mit-plv/fiat-crypto/pull/670">since late October 2020</a>, <a href="https://eprint.iacr.org/2021/549">paper</a> - which allowed to reduce our code base taken from BoringSSL. The ECDSA protocol was easy to implement in OCaml using the generated arithmetics.</p> +<p>Addressing the issue of more curves was also easy to achieve, the C code (group operations) are macros that are instantiated for each curve - the OCaml code are functors that are applied with each curve description.</p> +<p>Thanks to the test vectors (as structured data) from <a href="https://github.com/google/wycheproof/">wycheproof</a> (and again thanks to Etienne, Nathan, and Clément for their OCaml code decodin them), I feel confident that our elliptic curve code works as desired.</p> +<p>What was left is X25519 and Ed25519 - dropping the hacl dependency entirely felt appealing (less C code to maintain from fewer projects). This turned out to require more C code, which we took from BoringSSL. It may be desirable to reduce the imported C code, or to wait until a project on top of fiat-crypto which provides proven cryptographic protocols is in a usable state.</p> +<p>To avoid performance degradation, I distilled some <a href="https://github.com/mirage/mirage-crypto/pull/107#issuecomment-799701703">X25519 benchmarks</a>, turns out the fiat-crypto and hacl performance is very similar.</p> +<h3>Achievements</h3> +<p>The new opam package <a href="https://mirage.github.io/mirage-crypto/doc/mirage-crypto-ec/Mirage_crypto_ec/index.html">mirage-crypto-ec</a> is released, which includes the C code generated by fiat-crypto (including <a href="https://github.com/mit-plv/fiat-crypto/pull/670">inversion</a>), <a href="https://github.com/mirage/mirage-crypto/blob/main/ec/native/point_operations.h">point operations</a> from BoringSSL, and some <a href="https://github.com/mirage/mirage-crypto/blob/main/ec/mirage_crypto_ec.ml">OCaml code</a> for invoking these functions and doing bounds checks, and whether points are on the curve. The OCaml code are some functors that take the curve description (consisting of parameters, C function names, byte length of value) and provide Diffie-Hellman (Dh) and digital signature algorithm (Dsa) modules. The nonce for ECDSA is computed deterministically, as suggested by <a href="https://tools.ietf.org/html/rfc6979">RFC 6979</a>, to avoid private key leakage.</p> +<p>The code has been developed in <a href="https://github.com/mirage/mirage-crypto/pull/101">NIST curves</a>, <a href="https://github.com/mirage/mirage-crypto/pull/106">removing blinding</a> (since we use operations that are verified to be constant-time), <a href="https://github.com/mirage/mirage-crypto/pull/108">added missing length checks</a> (reported by <a href="https://github.com/greg42">Greg</a>), <a href="https://github.com/mirage/mirage-crypto/pull/107">curve25519</a>, <a href="https://github.com/mirage/mirage-crypto/pull/117">a fix for signatures that do not span the entire byte size (discovered while adapting X.509)</a>, <a href="https://github.com/mirage/mirage-crypto/pull/118">fix X25519 when the input has offset <> 0</a>. It works on x86 and arm, both 32 and 64 bit (checked by CI). The development was partially sponsored by Nitrokey.</p> +<p>What is left to do, apart from further security reviews, is <a href="https://github.com/mirage/mirage-crypto/issues/109">performance improvements</a>, <a href="https://github.com/mirage/mirage-crypto/issues/112">Ed448/X448 support</a>, and <a href="https://github.com/mirage/mirage-crypto/issues/105">investigating deterministic k for P521</a>. Pull requests are welcome.</p> +<p>When you use the code, and encounter any issues, please <a href="https://github.com/mirage/mirage-crypto/issues">report them</a>.</p> +<h2>Layer up - X.509 now with ECDSA / EdDSA and PKCS 12 support, and a long-standing issue fixed</h2> +<p>With the sign and verify primitives, the next step is to interoperate with other tools that generate and use these public and private keys. This consists of serialisation to and deserialisation from common data formats (ASN.1 DER and PEM encoding), and support for handling X.509 certificates with elliptic curve keys. Since X.509 0.12.0, it supports EC private and public keys, including certificate validation and issuance.</p> +<p>Releasing X.509 also included to go through the issue tracker and attempt to solve the existing issues. This time, the <a href="https://github.com/mirleft/ocaml-x509/issues/69">"country name is encoded as UTF8String, while RFC demands PrintableString"</a> filed more than 5 years ago by <a href="https://github.com/reynir">Reynir</a>, re-reported by <a href="https://github.com/paurkedal">Petter</a> in early 2017, and again by <a href="https://github.com/NightBlues">Vadim</a> in late 2020, <a href="https://github.com/mirleft/ocaml-x509/pull/140">was fixed by Vadim</a>.</p> +<p>Another long-standing pull request was support for <a href="https://tools.ietf.org/html/rfc7292">PKCS 12</a>, the archive format for certificate and private key bundles. This has <a href="https://github.com/mirleft/ocaml-x509/pull/114">been developed and merged</a>. PKCS 12 is a widely used and old format (e.g. when importing / exporting cryptographic material in your browser, used by OpenVPN, ...). Its specification uses RC2 and 3DES (see <a href="https://unmitigatedrisk.com/?p=654">this nice article</a>), which are the default algorithms used by <code>openssl pkcs12</code>.</p> +<h2>One more layer up - TLS</h2> +<p>In TLS we are finally able to use ECDSA (and EdDSA) certificates and private keys, this resulted in slightly more complex configuration - the constraints between supported groups, signature algorithms, ciphersuite, and certificates are intricate:</p> +<p>The ciphersuite (in TLS before 1.3) specifies which key exchange mechanism to use, but also which signature algorithm to use (RSA/ECDSA). The supported groups client hello extension specifies which elliptic curves are supported by the client. The signature algorithm hello extension (TLS 1.2 and above) specifies the signature algorithm. In the end, at load time the TLS configuration is validated and groups, ciphersuites, and signature algorithms are condensed depending on configured server certificates. At session initiation time, once the client reports what it supports, these parameters are further cut down to eventually find some suitable cryptographic parameters for this session.</p> +<p>From the user perspective, earlier the certificate bundle and private key was a pair of <code>X509.Certificate.t list</code> and <code>Mirage_crypto_pk.Rsa.priv</code>, now the second part is a <code>X509.Private_key.t</code> - all provided constructors have been updates (notably <code>X509_lwt.private_of_pems</code> and <code>Tls_mirage.X509.certificate</code>).</p> +<h2>Finally, conduit and mirage</h2> +<p>Thanks to <a href="https://github.com/dinosaure">Romain</a>, conduit* 4.0.0 was released which supports the modified API of X.509 and TLS. Romain also developed patches and released mirage 3.10.3 which supports the above mentioned work.</p> +<h2>Conclusion</h2> +<p>Elliptic curve cryptography is now available in OCaml using verified cryptographic primitives from the fiat-crypto project - <code>opam install mirage-crypto-ec</code>. X.509 since 0.12.0 and TLS since 0.13.0 and MirageOS since 3.10.3 support this new development which gives rise to smaller EC keys. Our old bindings, fiat-p256 and hacl_x25519 have been archived and will no longer be maintained.</p> +<p>Thanks to everyone involved on this journey: reporting issues, sponsoring parts of the work, helping with integration, developing initial prototypes, and keep motivating me to continue this until the release is done.</p> +<p>In the future, it may be possible to remove zarith and gmp from the dependency chain, and provide EC-only TLS servers and clients for MirageOS. The benefit will be much less C code (libgmp-freestanding.a is 1.5MB in size) in our trusted code base.</p> +<p>Another potential project that is very close now is a certificate authority developed in MirageOS - now that EC keys, PKCS 12, revocation lists, ... are implemented.</p> +<h2>Footer</h2> +<p>If you want to support our work on MirageOS unikernels, please <a href="https://robur.coop/Donate">donate to robur</a>. I'm interested in feedback, either via <a href="https://twitter.com/h4nnes">twitter</a>, <a href="https://mastodon.social/@hannesm">hannesm@mastodon.social</a> or via eMail.</p> +urn:uuid:16427713-5da1-50cd-b17c-ca5b5cca431dCryptography updates in OCaml and MirageOS2021-11-19T18:04:52-00:00hannes

<p>Home office, MirageOS unikernels, 2020 recap, 2021 tbd</p> +

2021-01-25T12:45:54-00:00<h2>Introduction</h2> +<p>2020 was an intense year. I hope you're healthy and keep being healthy. I am privileged (as lots of software engineers and academics are) to be able to work from home during the pandemic. Let's not forget people in less privileged situations, and let’s try to give them as much practical, psychological and financial support as we can these days. And as much joy as possible to everyone around :)</p> +<p>I cancelled the autumn MirageOS retreat due to the pandemic. Instead I collected donations for our hosts in Marrakech - they were very happy to receive our financial support, since they had a difficult year, since their income is based on tourism. I hope that in autumn 2021 we'll have an on-site retreat again.</p> +<p>For 2021, we (at <a href="https://robur.coop">robur</a>) got a grant from the EU (via <a href="https://pointer.ngi.eu">NGI pointer</a>) for "Deploying MirageOS" (more details below), and another grant from <a href="https://ocaml-sf.org">OCaml software foundation</a> for securing the opam supply chain (using <a href="https://github.com/hannesm/conex">conex</a>). Some long-awaited releases for MirageOS libraries, namely a <a href="https://discuss.ocaml.org/t/ann-first-release-of-awa-ssh">ssh implementation</a> and a rewrite of our <a href="https://discuss.ocaml.org/t/ann-release-of-ocaml-git-v3-0-duff-encore-decompress-etc/">git implementation</a> have already been published.</p> +<p>With my MirageOS view, 2020 was a pretty successful year, where we managed to add more features, fixed lots of bugs, and paved the road ahead. I want to thank <a href="https://ocamllabs.io/">OCamlLabs</a> for funding work on MirageOS maintenance.</p> +<h2>Recap 2020</h2> +<p>Here is a very subjective random collection of accomplishments in 2020, where I was involved with some degree.</p> +<h3>NetHSM</h3> +<p><a href="https://www.nitrokey.com/products/nethsm">NetHSM</a> is a hardware security module in software. It is a product that uses MirageOS for security, and is based on the <a href="https://muen.sk">muen</a> separation kernel. We at <a href="https://robur.coop">robur</a> were heavily involved in this product. It already has been security audited by an external team. You can pre-order it from Nitrokey.</p> +<h3>TLS 1.3</h3> +<p>Dating back to 2016, at the <a href="https://www.ndss-symposium.org/ndss2016/tron-workshop-programme/">TRON</a> (TLS 1.3 Ready or NOt), we developed a first draft of a 1.3 implementation of <a href="https://github.com/mirleft/ocaml-tls">OCaml-TLS</a>. Finally in May 2020 we got our act together, including ECC (ECDH P256 from <a href="https://github.com/mit-plv/fiat-crypto/">fiat-crypto</a>, X25519 from <a href="https://project-everest.github.io/">hacl</a>) and testing with <a href="https://github.com/tlsfuzzer/tlsfuzzer">tlsfuzzer</a>, and release tls 0.12.0 with TLS 1.3 support. Later we added <a href="https://github.com/mirleft/ocaml-tls/pull/414">ECC ciphersuites to TLS version 1.2</a>, implemented <a href="https://github.com/mirleft/ocaml-tls/pull/414">ChaCha20/Poly1305</a>, and fixed an <a href="https://github.com/mirleft/ocaml-tls/pull/424">interoperability issue with Go's implementation</a>.</p> +<p><a href="https://github.com/mirage/mirage-crypto">Mirage-crypto</a> provides the underlying cryptographic primitives, initially released in March 2020 as a fork of <a href="https://github.com/mirleft/ocaml-nocrypto">nocrypto</a> -- huge thanks to <a href="https://github.com/pqwy">pqwy</a> for his great work. Mirage-crypto detects <a href="https://github.com/mirage/mirage-crypto/pull/53">CPU features at runtime</a> (thanks to <a href="https://github.com/Julow">Julow</a>) (<a href="https://github.com/mirage/mirage-crypto/pull/96">bugfix for bswap</a>), using constant time modular exponentation (powm_sec) and hardens against Lenstra's CRT attack, supports <a href="https://github.com/mirage/mirage-crypto/pull/39">compilation on Windows</a> (thanks to <a href="https://github.com/avsm">avsm</a>), <a href="https://github.com/mirage/mirage-crypto/pull/90">async entropy harvesting</a> (thanks to <a href="https://github.com/seliopou">seliopou</a>), <a href="https://github.com/mirage/mirage-crypto/pull/65">32 bit support</a>, <a href="https://github.com/mirage/mirage-crypto/pull/72">chacha20/poly1305</a> (thanks to <a href="https://github.com/abeaumont">abeaumont</a>), <a href="https://github.com/mirage/mirage-crypto/pull/84">cross-compilation</a> (thanks to <a href="https://github.com/EduardoRFS">EduardoRFS</a>) and <a href="https://github.com/mirage/mirage-crypto/pull/78">various</a> <a href="https://github.com/mirage/mirage-crypto/pull/81">bug</a> <a href="https://github.com/mirage/mirage-crypto/pull/83">fixes</a>, even <a href="https://github.com/mirage/mirage-crypto/pull/95">memory leak</a> (thanks to <a href="https://github.com/talex5">talex5</a> for reporting several of these issues), and <a href="https://github.com/mirage/mirage-crypto/pull/99">RSA</a> <a href="https://github.com/mirage/mirage-crypto/pull/100">interoperability</a> (thanks to <a href="https://github.com/psafont">psafont</a> for investigation and <a href="https://github.com/mattjbray">mattjbray</a> for reporting). This library feels very mature now - being used by multiple stakeholders, and lots of issues have been fixed in 2020.</p> +<h3>Qubes Firewall</h3> +<p>The <a href="https://github.com/mirage/qubes-mirage-firewall/">MirageOS based Qubes firewall</a> is the most widely used MirageOS unikernel. And it got major updates: in May <a href="https://github.com/linse">Steffi</a> <a href="https://groups.google.com/g/qubes-users/c/Xzplmkjwa5Y">announced</a> her and <a href="https://github.com/yomimono">Mindy's</a> work on improving it for Qubes 4.0 - including <a href="https://www.qubes-os.org/doc/vm-interface/#firewall-rules-in-4x">dynamic firewall rules via QubesDB</a>. Thanks to <a href="https://prototypefund.de/project/portable-firewall-fuer-qubesos/">prototypefund</a> for sponsoring.</p> +<p>In October 2020, we released <a href="https://mirage.io/blog/announcing-mirage-39-release">Mirage 3.9</a> with PVH virtualization mode (thanks to <a href="https://github.com/mato">mato</a>). There's still a <a href="https://github.com/mirage/qubes-mirage-firewall/issues/120">memory leak</a> to be investigated and fixed.</p> +<h3>IPv6</h3> +<p>In December, with <a href="https://mirage.io/blog/announcing-mirage-310-release">Mirage 3.10</a> we got the IPv6 code up and running. Now MirageOS unikernels have a dual stack available, besides IPv4-only and IPv6-only network stacks. Thanks to <a href="https://github.com/nojb">nojb</a> for the initial code and <a href="https://github.com/MagnusS">MagnusS</a>.</p> +<p>Turns out this blog, but also robur services, are now available via IPv6 :)</p> +<h3>Albatross</h3> +<p>Also in December, I pushed an initial release of <a href="https://github.com/roburio/albatross">albatross</a>, a unikernel orchestration system with remote access. <em>Deploy your unikernel via a TLS handshake -- the unikernel image is embedded in the TLS client certificates.</em></p> +<p>Thanks to <a href="https://github.com/reynir">reynir</a> for statistics support on Linux and improvements of the systemd service scripts. Also thanks to <a href="https://github.com/cfcs">cfcs</a> for the initial Linux port.</p> +<h3>CA certs</h3> +<p>For several years I postponed the problem of how to actually use the operating system trust anchors for OCaml-TLS connections. Thanks to <a href="https://github.com/emillon">emillon</a> for initial code, there are now <a href="https://github.com/mirage/ca-certs">ca-certs</a> and <a href="https://github.com/mirage/ca-certs-nss">ca-certs-nss</a> opam packages (see <a href="https://discuss.ocaml.org/t/ann-ca-certs-and-ca-certs-nss">release announcement</a>) which fills this gap.</p> +<h2>Unikernels</h2> +<p>I developed several useful unikernels in 2020, and also pushed <a href="https://mirage.io/wiki/gallery">a unikernel gallery</a> to the Mirage website:</p> +<h3>Traceroute in MirageOS</h3> +<p>I already wrote about <a href="/Posts/Traceroute">traceroute</a> which traces the routing to a given remote host.</p> +<h3>Unipi - static website hosting</h3> +<p><a href="https://github.com/roburio/unipi">Unipi</a> is a static site webserver which retrieves the content from a remote git repository. Let's encrypt certificate provisioning and dynamic updates via a webhook to be executed for every push.</p> +<h4>TLSTunnel - TLS demultiplexing</h4> +<p>The physical machine this blog and other robur infrastructure runs on has been relocated from Sweden to Germany mid-December. Thanks to UPS! Fewer IPv4 addresses are available in the new data center, which motivated me to develop <a href="https://github.com/roburio/tlstunnel">tlstunnel</a>.</p> +<p>The new behaviour is as follows (see the <code>monitoring</code> branch):</p> +<ul> +<li>listener on TCP port 80 which replies with a permanent redirect to <code>https</code> +</li> +<li>listener on TCP port 443 which forwards to a backend host if the requested server name is configured +</li> +<li>its configuration is stored on a block device, and can be dynamically changed (with a custom protocol authenticated with a HMAC) +</li> +<li>it is setup to hold a wildcard TLS certificate and in DNS a wildcard entry is pointing to it +</li> +<li>setting up a new service is very straightforward: only the new name needs to be registered with tlstunnel together with the TCP backend, and everything will just work +</li> +</ul> +<h2>2021</h2> +<p>The year started with a release of <a href="https://discuss.ocaml.org/t/ann-first-release-of-awa-ssh">awa</a>, a SSH implementation in OCaml (thanks to <a href="https://github.com/haesbaert">haesbaert</a> for initial code). This was followed by a <a href="https://discuss.ocaml.org/t/ann-release-of-ocaml-git-v3-0-duff-encore-decompress-etc/">git 3.0 release</a> (thanks to <a href="https://github.com/dinosaure">dinosaure</a>).</p> +<h3>Deploying MirageOS - NGI Pointer</h3> +<p>For 2021 we at robur received funding from the EU (via <a href="https://pointer.ngi.eu/">NGI pointer</a>) for "Deploying MirageOS", which boils down into three parts:</p> +<ul> +<li>reproducible binary releases of MirageOS unikernels, +</li> +<li>monitoring (and other devops features: profiling) and integration into existing infrastructure, +</li> +<li>and further documentation and advertisement. +</li> +</ul> +<p>Of course this will all be available open source. Please get in touch via eMail (team aT robur dot coop) if you're eager to integrate MirageOS unikernels into your infrastructure.</p> +<p>We discovered at an initial meeting with an infrastructure provider that a DNS resolver is of interest - even more now that dnsmasq suffered from <a href="https://www.jsof-tech.com/wp-content/uploads/2021/01/DNSpooq_Technical-Whitepaper.pdf">dnspooq</a>. We are already working on an <a href="https://github.com/mirage/ocaml-dns/pull/251">implementation of DNSSec</a>.</p> +<p>MirageOS unikernels are binary reproducible, and <a href="https://github.com/rjbou/orb/pull/1">infrastructure tools are available</a>. We are working hard on a web interface (and REST API - think of it as "Docker Hub for MirageOS unikernels"), and more tooling to verify reproducibility.</p> +<h3>Conex - securing the supply chain</h3> +<p>Another funding from the <a href="http://ocaml-sf.org/">OCSF</a> is to continue development and deploy <a href="https://github.com/hannesm/conex">conex</a> - to bring trust into opam-repository. This is a great combination with the reproducible build efforts, and will bring much more trust into retrieving OCaml packages and using MirageOS unikernels.</p> +<h3>MirageOS 4.0</h3> +<p>Mirage so far still uses ocamlbuild and ocamlfind for compiling the virtual machine binary. But the switch to dune is <a href="https://github.com/mirage/mirage/issues/1195">close</a>, a lot of effort has been done. This will make the developer experience of MirageOS much more smooth, with a per-unikernel monorepo workflow where you can push your changes to the individual libraries.</p> +<h2>Footer</h2> +<p>If you want to support our work on MirageOS unikernels, please <a href="https://robur.coop/Donate">donate to robur</a>. I'm interested in feedback, either via <a href="https://twitter.com/h4nnes">twitter</a>, <a href="https://mastodon.social/@hannesm">hannesm@mastodon.social</a> or via eMail.</p> +urn:uuid:bc7675a5-47d0-5ce1-970c-01ed07fdf404The road ahead for MirageOS in 20212021-11-19T18:04:52-00:00hannes

<p>A MirageOS unikernel which traces the path between itself and a remote host.</p> +

2020-06-24T10:38:10-00:00<h2>Traceroute</h2> +<p>Is a diagnostic utility which displays the route and measures transit delays of +packets across an Internet protocol (IP) network.</p> +<pre><code class="language-bash">$ doas solo5-hvt --net:service=tap0 -- traceroute.hvt --ipv4=10.0.42.2/24 --ipv4-gateway=10.0.42.1 --host=198.167.222.207 + | ___| + __| _ \ | _ \ __ \ +\__ \ ( | | ( | ) | +____/\___/ _|\___/____/ +Solo5: Bindings version v0.6.5 +Solo5: Memory map: 512 MB addressable: +Solo5: reserved @ (0x0 - 0xfffff) +Solo5: text @ (0x100000 - 0x212fff) +Solo5: rodata @ (0x213000 - 0x24bfff) +Solo5: data @ (0x24c000 - 0x317fff) +Solo5: heap >= 0x318000 < stack < 0x20000000 +2020-06-22 15:41:25 -00:00: INF [netif] Plugging into service with mac 76:9b:36:e0:e5:74 mtu 1500 +2020-06-22 15:41:25 -00:00: INF [ethernet] Connected Ethernet interface 76:9b:36:e0:e5:74 +2020-06-22 15:41:25 -00:00: INF [ARP] Sending gratuitous ARP for 10.0.42.2 (76:9b:36:e0:e5:74) +2020-06-22 15:41:25 -00:00: INF [udp] UDP interface connected on 10.0.42.2 +2020-06-22 15:41:25 -00:00: INF [application] 1 10.0.42.1 351us +2020-06-22 15:41:25 -00:00: INF [application] 2 192.168.42.1 1.417ms +2020-06-22 15:41:25 -00:00: INF [application] 3 192.168.178.1 1.921ms +2020-06-22 15:41:25 -00:00: INF [application] 4 88.72.96.1 16.716ms +2020-06-22 15:41:26 -00:00: INF [application] 5 * +2020-06-22 15:41:27 -00:00: INF [application] 6 92.79.215.112 16.794ms +2020-06-22 15:41:27 -00:00: INF [application] 7 145.254.2.215 21.305ms +2020-06-22 15:41:27 -00:00: INF [application] 8 145.254.2.217 22.05ms +2020-06-22 15:41:27 -00:00: INF [application] 9 195.89.99.1 21.088ms +2020-06-22 15:41:27 -00:00: INF [application] 10 62.115.9.133 20.105ms +2020-06-22 15:41:27 -00:00: INF [application] 11 213.155.135.82 30.861ms +2020-06-22 15:41:27 -00:00: INF [application] 12 80.91.246.200 30.716ms +2020-06-22 15:41:27 -00:00: INF [application] 13 80.91.253.163 28.315ms +2020-06-22 15:41:27 -00:00: INF [application] 14 62.115.145.27 30.436ms +2020-06-22 15:41:27 -00:00: INF [application] 15 80.67.4.239 42.826ms +2020-06-22 15:41:27 -00:00: INF [application] 16 80.67.10.147 47.213ms +2020-06-22 15:41:27 -00:00: INF [application] 17 198.167.222.207 48.598ms +Solo5: solo5_exit(0) called +</code></pre> +<p>This means with a traceroute utility you can investigate which route is taken +to a destination host, and what the round trip time(s) on the path are. The +sample output above is taken from a virtual machine on my laptop to the remote +host 198.167.222.207. You can see there are 17 hops between us, with the first +being my laptop with a tiny round trip time of 351us, the second and third are +using private IP addresses, and are my home network. The round trip time of the +fourth hop is much higher, this is the first hop on the other side of my DSL +modem. You can see various hops on the public Internet: the packets pass from +my Internet provider's backbone across some exchange points to the destination +Internet provider somewhere in Sweden.</p> +<p>The implementation of traceroute relies mainly on the time-to-live (ttl) field +(in IPv6 lingua it is "hop limit") of IP packets, which is meant to avoid route +cycles that would infinitely forward IP packets in circles. Every router, when +forwarding an IP packet, first checks that the ttl field is greater than zero, +and then forwards the IP packet where the ttl is decreased by one. If the ttl +field is zero, instead of forwarding, an ICMP time exceeded packet is sent back +to the source.</p> +<p>Traceroute works by exploiting this mechanism: a series of IP packets with +increasing ttls is sent to the destination. Since upfront the length of the +path is unknown, it is a reactive system: first send an IP packet with a ttl of +one, if a ICMP time exceeded packet is returned, send an IP packet with a ttl of +two, etc. -- until an ICMP packet of type destination unreachable is received. +Since some hosts do not reply with a time exceeded message, it is crucial for +not getting stuck to use a timeout for each packet: when the timeout is reached, +an IP packet with an increased ttl is sent and an unknown for the ttl is +printed (see the fifth hop in the example above).</p> +<p>The packets send out are conventionally UDP packets without payload. From a +development perspective, one question is how to correlate the ICMP packet +with the sent UDP packet. Conveniently, ICMP packets contain the IP header and +the first eight bytes of the next protocol - the UDP header containing source +port, destination port, checksum, and payload length (each fields of size two +bytes). This means when we record the outgoing ports together with the sent +timestamp, and correlate the later received ICMP packet to the sent packet. +Great.</p> +<p>But as a functional programmer, let's figure whether we can abolish the +(globally shared) state. Since the ICMP packet contains the original IP +header and the first eight bytes of the UDP header, this is where we will +embed data. As described above, the data is the sent timestamp and the value +of the ttl field. For the latter, we can arbitrarily restrict it to 31 (5 bits). +For the timestamp, it is mainly a question about precision and maximum expected +round trip time. Taking the source and destination port are 32 bits, using 5 for +ttl, remaining are 27 bits (an unsigned value up to 134217727). Looking at the +decimal representation, 1 second is likely too small, 13 seconds are sufficient +for the round trip time measurement. This implies our precision is 100ns, by +counting the digits.</p> +<p>Finally to the code. First we need forth and back conversions between ports +and ttl, timestamp:</p> +<pre><code class="language-OCaml">(* takes a time-to-live (int) and timestamp (int64, nanoseconda), encodes them + into 16 bit source port and 16 bit destination port: + - the timestamp precision is 100ns (thus, it is divided by 100) + - use the bits 27-11 of the timestamp as source port + - use the bits 11-0 as destination port, and 5 bits of the ttl +*) +let ports_of_ttl_ts ttl ts = + let ts = Int64.div ts 100L in + let src_port = 0xffff land (Int64.(to_int (shift_right ts 11))) + and dst_port = 0xffe0 land (Int64.(to_int (shift_left ts 5))) lor (0x001f land ttl) + in + src_port, dst_port + +(* inverse operation of ports_of_ttl_ts for the range (src_port and dst_port + are 16 bit values) *) +let ttl_ts_of_ports src_port dst_port = + let ttl = 0x001f land dst_port in + let ts = + let low = Int64.of_int (dst_port lsr 5) + and high = Int64.(shift_left (of_int src_port) 11) + in + Int64.add low high + in + let ts = Int64.mul ts 100L in + ttl, ts +</code></pre> +<p>They should be inverse over the range of valid input: ports are 16 bit numbers, +ttl expected to be at most 31, ts a int64 expressed in nanoseconds.</p> +<p>Related is the function to print out one hop and round trip measurement:</p> +<pre><code class="language-OCaml">(* write a log line of a hop: the number, IP address, and round trip time *) +let log_one now ttl sent ip = + let now = Int64.(mul (logand (div now 100L) 0x7FFFFFFL) 100L) in + let duration = Mtime.Span.of_uint64_ns (Int64.sub now sent) in + Logs.info (fun m -> m "%2d %a %a" ttl Ipaddr.V4.pp ip Mtime.Span.pp duration) +</code></pre> +<p>The most logic is when a ICMP packet is received:</p> +<pre><code class="language-OCaml">module Icmp = struct + type t = { + send : int -> unit Lwt.t ; + log : int -> int64 -> Ipaddr.V4.t -> unit ; + task_done : unit Lwt.u ; + } + + let connect send log task_done = + let t = { send ; log ; task_done } in + Lwt.return t + + (* This is called for each received ICMP packet. *) + let input t ~src ~dst buf = + let open Icmpv4_packet in + (* Decode the received buffer (the IP header has been cut off already). *) + match Unmarshal.of_cstruct buf with + | Error s -> + Lwt.fail_with (Fmt.strf "ICMP: error parsing message from %a: %s" Ipaddr.V4.pp src s) + | Ok (message, payload) -> + let open Icmpv4_wire in + (* There are two interesting cases: Time exceeded (-> send next packet), + and Destination (port) unreachable (-> we reached the final host and can exit) *) + match message.ty with + | Time_exceeded -> + (* Decode the payload, which should be an IPv4 header and a protocol header *) + begin match Ipv4_packet.Unmarshal.header_of_cstruct payload with + | Ok (pkt, off) when + (* Ensure this packet matches our sent packet: the protocol is UDP + and the destination address is the host we're tracing *) + pkt.Ipv4_packet.proto = Ipv4_packet.Marshal.protocol_to_int `UDP && + Ipaddr.V4.compare pkt.Ipv4_packet.dst (Key_gen.host ()) = 0 -> + let src_port = Cstruct.BE.get_uint16 payload off + and dst_port = Cstruct.BE.get_uint16 payload (off + 2) + in + (* Retrieve ttl and sent timestamp, encoded in the source port and + destination port of the UDP packet we sent, and received back as + ICMP payload. *) + let ttl, sent = ttl_ts_of_ports src_port dst_port in + (* Log this hop. *) + t.log ttl sent src; + (* Sent out the next UDP packet with an increased ttl. *) + let ttl' = succ ttl in + Logs.debug (fun m -> m "ICMP time exceeded from %a to %a, now sending with ttl %d" + Ipaddr.V4.pp src Ipaddr.V4.pp dst ttl'); + t.send ttl' + | Ok (pkt, _) -> + (* Some stray ICMP packet. *) + Logs.debug (fun m -> m "unsolicited time exceeded from %a to %a (proto %X dst %a)" + Ipaddr.V4.pp src Ipaddr.V4.pp dst pkt.Ipv4_packet.proto Ipaddr.V4.pp pkt.Ipv4_packet.dst); + Lwt.return_unit + | Error e -> + (* Decoding error. *) + Logs.warn (fun m -> m "couldn't parse ICMP time exceeded payload (IPv4) (%a -> %a) %s" + Ipaddr.V4.pp src Ipaddr.V4.pp dst e); + Lwt.return_unit + end + | Destination_unreachable when Ipaddr.V4.compare src (Key_gen.host ()) = 0 -> + (* We reached the final host, and the destination port was not listened to *) + begin match Ipv4_packet.Unmarshal.header_of_cstruct payload with + | Ok (_, off) -> + let src_port = Cstruct.BE.get_uint16 payload off + and dst_port = Cstruct.BE.get_uint16 payload (off + 2) + in + (* Retrieve ttl and sent timestamp. *) + let ttl, sent = ttl_ts_of_ports src_port dst_port in + (* Log the final hop. *) + t.log ttl sent src; + (* Wakeup the waiter task to exit the unikernel. *) + Lwt.wakeup t.task_done (); + Lwt.return_unit + | Error e -> + (* Decoding error. *) + Logs.warn (fun m -> m "couldn't parse ICMP unreachable payload (IPv4) (%a -> %a) %s" + Ipaddr.V4.pp src Ipaddr.V4.pp dst e); + Lwt.return_unit + end + | ty -> + Logs.debug (fun m -> m "ICMP unknown ty %s from %a to %a: %a" + (ty_to_string ty) Ipaddr.V4.pp src Ipaddr.V4.pp dst + Cstruct.hexdump_pp payload); + Lwt.return_unit +end +</code></pre> +<p>Now, the remaining main unikernel is the module <code>Main</code>:</p> +<pre><code class="language-OCaml">module Main (R : Mirage_random.S) (M : Mirage_clock.MCLOCK) (Time : Mirage_time.S) (N : Mirage_net.S) = struct + module ETH = Ethernet.Make(N) + module ARP = Arp.Make(ETH)(Time) + module IPV4 = Static_ipv4.Make(R)(M)(ETH)(ARP) + module UDP = Udp.Make(IPV4)(R) + + (* Global mutable state: the timeout task for a sent packet. *) + let to_cancel = ref None + + (* Send a single packet with the given time to live. *) + let rec send_udp udp ttl = + (* This is called by the ICMP handler which successfully received a + time exceeded, thus we cancel the timeout task. *) + (match !to_cancel with + | None -> () + | Some t -> Lwt.cancel t ; to_cancel := None); + (* Our hop limit is 31 - 5 bit - should be sufficient for most networks. *) + if ttl > 31 then + Lwt.return_unit + else + (* Create a timeout task which: + - sleeps for --timeout interval + - logs an unknown hop + - sends another packet with increased ttl + *) + let cancel = + Lwt.catch (fun () -> + Time.sleep_ns (Duration.of_ms (Key_gen.timeout ())) >>= fun () -> + Logs.info (fun m -> m "%2d *" ttl); + send_udp udp (succ ttl)) + (function Lwt.Canceled -> Lwt.return_unit | exc -> Lwt.fail exc) + in + (* Assign this timeout task. *) + to_cancel := Some cancel; + (* Figure out which source and destination port to use, based on ttl + and current timestamp. *) + let src_port, dst_port = ports_of_ttl_ts ttl (M.elapsed_ns ()) in + (* Send packet via UDP. *) + UDP.write ~ttl ~src_port ~dst:(Key_gen.host ()) ~dst_port udp Cstruct.empty >>= function + | Ok () -> Lwt.return_unit + | Error e -> Lwt.fail_with (Fmt.strf "while sending udp frame %a" UDP.pp_error e) + + (* The main unikernel entry point. *) + let start () () () net = + let cidr = Key_gen.ipv4 () + and gateway = Key_gen.ipv4_gateway () + in + let log_one = fun port ip -> log_one (M.elapsed_ns ()) port ip + (* Create a task to wait on and a waiter to wakeup. *) + and t, w = Lwt.task () + in + (* Setup network stack: ethernet, ARP, IPv4, UDP, and ICMP. *) + ETH.connect net >>= fun eth -> + ARP.connect eth >>= fun arp -> + IPV4.connect ~cidr ~gateway eth arp >>= fun ip -> + UDP.connect ip >>= fun udp -> + let send = send_udp udp in + Icmp.connect send log_one w >>= fun icmp -> + + (* The callback cascade for an incoming network packet. *) + let ethif_listener = + ETH.input + ~arpv4:(ARP.input arp) + ~ipv4:( + IPV4.input + ~tcp:(fun ~src:_ ~dst:_ _ -> Lwt.return_unit) + ~udp:(fun ~src:_ ~dst:_ _ -> Lwt.return_unit) + ~default:(fun ~proto ~src ~dst buf -> + match proto with + | 1 -> Icmp.input icmp ~src ~dst buf + | _ -> Lwt.return_unit) + ip) + ~ipv6:(fun _ -> Lwt.return_unit) + eth + in + (* Start the callback in a separate asynchronous task. *) + Lwt.async (fun () -> + N.listen net ~header_size:Ethernet_wire.sizeof_ethernet ethif_listener >|= function + | Ok () -> () + | Error e -> Logs.err (fun m -> m "netif error %a" N.pp_error e)); + (* Send the initial UDP packet with a ttl of 1. This entails the domino + effect to receive ICMP packets, send out another UDP packet with ttl + increased by one, etc. - until a destination unreachable is received, + or the hop limit is reached. *) + send 1 >>= fun () -> + t +end +</code></pre> +<p>The configuration (<code>config.ml</code>) for this unikernel is as follows:</p> +<pre><code class="language-OCaml">open Mirage + +let host = + let doc = Key.Arg.info ~doc:"The host to trace." ["host"] in + Key.(create "host" Arg.(opt ipv4_address (Ipaddr.V4.of_string_exn "141.1.1.1") doc)) + +let timeout = + let doc = Key.Arg.info ~doc:"Timeout (in millisecond)" ["timeout"] in + Key.(create "timeout" Arg.(opt int 1000 doc)) + +let ipv4 = + let doc = Key.Arg.info ~doc:"IPv4 address" ["ipv4"] in + Key.(create "ipv4" Arg.(required ipv4 doc)) + +let ipv4_gateway = + let doc = Key.Arg.info ~doc:"IPv4 gateway" ["ipv4-gateway"] in + Key.(create "ipv4-gateway" Arg.(required ipv4_address doc)) + +let main = + let packages = [ + package ~sublibs:["ipv4"; "udp"; "icmpv4"] "tcpip"; + package "ethernet"; + package "arp-mirage"; + package "mirage-protocols"; + package "mtime"; + ] in + foreign + ~keys:[Key.abstract ipv4 ; Key.abstract ipv4_gateway ; Key.abstract host ; Key.abstract timeout] + ~packages + "Unikernel.Main" + (random @-> mclock @-> time @-> network @-> job) + +let () = + register "traceroute" + [ main $ default_random $ default_monotonic_clock $ default_time $ default_network ] +</code></pre> +<p>And voila, that's all the code. If you copy it together (or download the two +files from <a href="https://github.com/roburio/traceroute">the GitHub repository</a>), +and have OCaml, opam, and <a href="https://mirage.io/wiki/install">mirage (>= 3.8.0)</a> installed, +you should be able to:</p> +<pre><code class="language-bash">$ mirage configure -t hvt +$ make depend +$ make +$ solo5-hvt --net:service=tap0 -- traceroute.hvt ... +... get the output shown at top ... +</code></pre> +<p>Enhancements may be to use a different protocol (TCP? or any other protocol ID (may be used to encode more information), encode data into IPv4 ID, or the full 8 bytes of the upper protocol), encrypt/authenticate the data transmitted (and verify it has not been tampered with in the ICMP reply), improve error handling and recovery, send multiple packets for improved round trip time measurements, ...</p> +<p>If you develop enhancements you'd like to share, please sent a pull request to the git repository.</p> +<p>Motivation for this traceroute unikernel was while talking with <a href="https://twitter.com/networkservice">Aaron</a> and <a href="https://github.com/phaer">Paul</a>, who contributed several patches to the IP stack which pass the ttl through.</p> +<p>If you want to support our work on MirageOS unikernels, please <a href="https://robur.coop/Donate">donate to robur</a>. I'm interested in feedback, either via <a href="https://twitter.com/h4nnes">twitter</a>, <a href="https://mastodon.social/@hannesm">hannesm@mastodon.social</a> or via eMail.</p> +urn:uuid:ed3036f6-83d2-5e80-b3da-4ccbedb5ae9eTraceroute2021-11-19T18:04:52-00:00hannes

<p>A tutorial how to deploy authoritative name servers, let's encrypt, and updating entries from unix services.</p> +

2019-12-23T21:30:53-00:00<h2>Goal</h2> +<p>Have your domain served by OCaml-DNS authoritative name servers. Data is stored in a git remote, and let's encrypt certificates can be requested to DNS. This software is deployed since more than two years for several domains such as <code>nqsb.io</code> and <code>robur.coop</code>. This present the authoritative server side, and certificate library of the OCaml-DNS implementation formerly known as <a href="/Posts/DNS">µDNS</a>.</p> +<h2>Prerequisites</h2> +<p>You need to own a domain, and be able to delegate the name service to your own servers. +You also need two spare public IPv4 addresses (in different /24 networks) for your name servers. +A git server or remote repository reachable via git over ssh. +Servers which support <a href="https://github.com/solo5/solo5">solo5</a> guests, and have the corresponding tender installed. +A computer with <a href="https://opam.ocaml.org">opam</a> (>= 2.0.0) installed.</p> +<h2>Data preparation</h2> +<p>Figure out a way to get the DNS entries of your domain in a <a href="https://tools.ietf.org/html/rfc1034">"master file format"</a>, i.e. what bind uses.</p> +<p>This is a master file for the <code>mirage</code> domain, defining <code>$ORIGIN</code> to avoid typing the domain name after each hostname (use <code>@</code> if you need the domain name only; if you need to refer to a hostname in a different domain end it with a dot (<code>.</code>), i.e. <code>ns2.foo.com.</code>). The default time to live <code>$TTL</code> is an hour (3600 seconds). +The zone contains a <a href="https://tools.ietf.org/html/rfc1035#section-3.3.13">start of authority (<code>SOA</code>) record</a> containing the nameserver, hostmaster, serial, refresh, retry, expiry, and minimum. +Also, a single <a href="https://tools.ietf.org/html/rfc1035#section-3.3.11">name server (<code>NS</code>) record</a> <code>ns1</code> is specified with an accompanying <a href="https://tools.ietf.org/html/rfc1035#section-3.4.1">address (<code>A</code>) records</a> pointing to their IPv4 address.</p> +<pre><code class="language-shell">git-repo> cat mirage +$ORIGIN mirage. +$TTL 3600 +@ SOA ns1 hostmaster 1 86400 7200 1048576 3600 +@ NS ns1 +ns1 A 127.0.0.1 +www A 1.1.1.1 +git-repo> git add mirage && git commit -m initial && git push +</code></pre> +<h2>Installation</h2> +<p>On your development machine, you need to install various OCaml packages. You don't need privileged access if common tools (C compiler, make, libgmp) are already installed. You have <code>opam</code> installed.</p> +<p>Let's create a fresh <code>switch</code> for the DNS journey:</p> +<pre><code class="language-shell">$ opam init +$ opam update +$ opam switch create udns 4.09.0 +# waiting a bit, a fresh OCaml compiler is getting bootstrapped +$ eval `opam env` #sets some environment variables +</code></pre> +<p>The last command set environment variables in your current shell session, please use the same shell for the commands following (or run <code>eval $(opam env)</code> in another shell and proceed in there - the output of <code>opam switch</code> sohuld point to <code>udns</code>).</p> +<h3>Validation of our zonefile</h3> +<p>First let's check that OCaml-DNS can parse our zonefile:</p> +<pre><code class="language-shell">$ opam install dns-cli #installs ~/.opam/udns/bin/ozone and other binaries +$ ozone <git-repo>/mirage # see ozone --help +successfully checked zone +</code></pre> +<p>Great. Error reporting is not great, but line numbers are indicated (<code>ozone: zone parse problem at line 3: syntax error</code>), <a href="https://github.com/mirage/ocaml-dns/tree/v4.2.0/zone">lexer and parser are lex/yacc style</a> (PRs welcome).</p> +<p>FWIW, <code>ozone</code> accepts <code>--old <filename></code> to check whether an update from the old zone to the new is fine. This can be used as <a href="https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks">pre-commit hook</a> in your git repository to avoid bad parse states in your name servers.</p> +<h3>Getting the primary up</h3> +<p>The next step is to compile the primary server and run it to serve the domain data. Since the git-via-ssh client is not yet released, we need to add a custom opam repository to this switch.</p> +<pre><code class="language-shell"># git via ssh is not yet released, but this opam repository contains the branch information +$ opam repo add git-ssh git+https://github.com/roburio/git-ssh-dns-mirage3-repo.git +# get the `mirage` application via opam +$ opam install lwt mirage + +# get the source code of the unikernels +$ git clone -b future https://github.com/roburio/unikernels.git +$ cd unikernels/primary-git + +# let's build the server first as unix application +$ mirage configure --prng fortuna #--no-depext if you have all system dependencies +$ make depend +$ make + +# run it +$ ./primary_git +# starts a unix process which clones https://github.com/roburio/udns.git +# attempts to parse the data as zone files, and fails on parse error +$ ./primary-git --remote=https://my-public-git-repository +# this should fail with ENOACCESS since the DNS server tries to listen on port 53 + +# which requires a privileged user, i.e. su, sudo or doas +$ sudo ./primary-git --remote=https://my-public-git-repository +# leave it running, run the following programs in a different shell + +# test it +$ host ns1.mirage 127.0.0.1 +ns1.mirage has address 127.0.0.1 +$ dig any mirage @127.0.0.1 +# a DNS packet printout with all records available for mirage +</code></pre> +<p>That's exciting, the DNS server serving answers from a remote git repository.</p> +<h3>Securing the git access with ssh</h3> +<p>Let's authenticate the access by using ssh, so we feel ready to push data there as well. The primary-git unikernel already includes an experimental <a href="https://github.com/haesbaert/awa-ssh">ssh client</a>, all we need to do is setting up credentials - in the following a RSA keypair and the server fingerprint.</p> +<pre><code class="language-shell"># collect the RSA host key fingerprint +$ ssh-keyscan <git-server> > /tmp/git-server-public-keys +$ ssh-keygen -l -E sha256 -f /tmp/git-server-public-keys | grep RSA +2048 SHA256:a5kkkuo7MwTBkW+HDt4km0gGPUAX0y1bFcPMXKxBaD0 <git-server> (RSA) +# we're interested in the SHA256:yyy only + +# generate a ssh keypair +$ awa_gen_key # installed by the make depend step above in ~/.opam/udns/bin +seed is pIKflD07VT2W9XpDvqntcmEW3OKlwZL62ak1EZ0m +ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC5b2cSSkZ5/MAu7pM6iJLOaX9tJsfA8DB1RI34Zygw6FA0y8iisbqGCv6Z94ZxreGATwSVvrpqGo5p0rsKs+6gQnMCU1+sOC4PRlxy6XKgj0YXvAZcQuxwmVQlBHshuq0CraMK9FASupGrSO8/dW30Kqy1wmd/IrqW9J1Cnw+qf0C/VEhIbo7btlpzlYpJLuZboTvEk1h67lx1ZRw9bSPuLjj665yO8d0caVIkPp6vDX20EsgITdg+cFjWzVtOciy4ETLFiKkDnuzHzoQ4EL8bUtjN02UpvX2qankONywXhzYYqu65+edSpogx2TuWFDJFPHgcyO/ZIMoluXGNgQlP awa@awa.local +# please run your own awa_gen_key, don't use the numbers above +</code></pre> +<p>The public key needs is in standard OpenSSH format and needs to be added to the list of accepted keys on your server - the exact steps depend on your git server, if you're running your own with <a href="https://github.com/tv42/gitosis">gitosis</a>, add it as new public key file and grant that key access to the data repository. If you use gitlab or github, you may want to create a new user account and with the generated key.</p> +<p>The private key is not displayed, but only the seed required to re-generate it, when using the same random number generator, in our case <a href="http://mirleft.github.io/ocaml-nocrypto/doc/Nocrypto.Rng.html">fortuna implemented by nocrypto</a> - used by both <code>awa_gen_key</code> and <code>primary_git</code>. The seed is provided as command-line argument while starting <code>primary_git</code>:</p> +<pre><code class="language-shell"># execute with git over ssh, authenticator from ssh-keyscan, seed from awa_gen_key +$ ./primary_git --authenticator=SHA256:a5kkkuo7MwTBkW+HDt4km0gGPUAX0y1bFcPMXKxBaD0 --seed=pIKflD07VT2W9XpDvqntcmEW3OKlwZL62ak1EZ0m --remote=ssh://git@<git-server>/repo-name.git +# started up, you can try the host and dig commands from above if you like +</code></pre> +<p>To wrap up, we now have a primary authoritative name server for our zone running as Unix process, which clones a remote git repository via ssh on startup and then serves it.</p> +<h3>Authenticated data updates</h3> +<p>Our remote git repository is the source of truth, if you need to add a DNS entry to the zone, you git pull, edit the zone file, remember to increase the serial in the SOA line, run <code>ozone</code>, git commit and push to the repository.</p> +<p>So, the <code>primary_git</code> needs to be informed of git pushes. This requires a communication channel from the git server (or somewhere else, e.g. your laptop) to the DNS server. I prefer in-protocol solutions over adding yet another protocol stack, no way my DNS server will talk HTTP REST.</p> +<p>The DNS protocol has an extension for <a href="https://tools.ietf.org/html/rfc1996">notifications of zone changes</a> (as a DNS packet), usually used between the primary and secondary servers. The <code>primary_git</code> accepts these notify requests (i.e. bends the standard slightly), and upon receival pulls the remote git repository, and serves the fresh zone files. Since a git pull may be rather excessive in terms of CPU cycles and network bandwidth, only authenticated notifications are accepted.</p> +<p>The DNS protocol specifies in another extension <a href="https://tools.ietf.org/html/rfc2845">authentication (DNS TSIG)</a> with transaction signatures on DNS packets including a timestamp and fudge to avoid replay attacks. As key material hmac secrets distribued to both the communication endpoints are used.</p> +<p>To recap, the primary server is configured with command line parameters (for remote repository url and ssh credentials), and serves data from a zonefile. If the secrets would be provided via command line, a restart would be necessary for adding and removing keys. If put into the zonefile, they would be publicly served on request. So instead, we'll use another file, still in zone file format, in the top-level domain <code>_keys</code>, i.e. the <code>mirage._keys</code> file contains keys for the <code>mirage</code> zone. All files ending in <code>._keys</code> are parsed with the normal parser, but put into an authentication store instead of the domain data store, which is served publically.</p> +<p>For encoding hmac secrets into DNS zone file format, the <a href="https://tools.ietf.org/html/rfc4034#section-2"><code>DNSKEY</code></a> format is used (designed for DNSsec). The <a href="https://www.isc.org/bind/">bind</a> software comes with <code>dnssec-keygen</code> and <code>tsig-keygen</code> to generate DNSKEY output: flags is 0, protocol is 3, and algorithm identifier for SHA256 is 163 (SHA384 164, SHA512 165). This is reused by the OCaml DNS library. The key material itself is base64 encoded.</p> +<p>Access control and naming of keys follows the DNS domain name hierarchy - a key has the form name._operation.domain, and has access granted to domain and all subdomains of it. Two operations are supported: update and transfer. In the future there may be a dedicated notify operation, for now we'll use update. The name part is ignored for the update operation.</p> +<p>Since we now embedd secret information in the git repository, it is a good idea to restrict access to it, i.e. make it private and not publicly cloneable or viewable. Let's generate a first hmac secret and send a notify:</p> +<pre><code class="language-shell">$ dd if=/dev/random bs=1 count=32 | b64encode - +begin-base64 644 - +kJJqipaQHQWqZL31Raar6uPnepGFIdtpjkXot9rv2xg= +==== +[..] +git-repo> echo "personal._update.mirage. DNSKEY 0 3 163 kJJqipaQHQWqZL31Raar6uPnepGFIdtpjkXot9rv2xg=" > mirage._keys +git-repo> git add mirage._keys && git commit -m "add hmac secret" && git push + +# now we need to restart the primary git to get the git repository with the key +$ ./primary_git --seed=... # arguments from above, remote git, host key fingerprint, private key seed + +# now test that a notify results in a git pull +$ onotify 127.0.0.1 mirage --key=personal._update.mirage:SHA256:kJJqipaQHQWqZL31Raar6uPnepGFIdtpjkXot9rv2xg= +# onotify was installed by dns-cli in ~/.opam/udns/bin/onotify, see --help for options +# further changes to the hmac secrets don't require a restart anymore, a notify packet is sufficient :D +</code></pre> +<p>Ok, this onotify command line could be setup as a git post-commit hook, or run manually after each manual git push.</p> +<h3>Secondary</h3> +<p>It's time to figure out how to integrate the secondary name server. An already existing bind or something else that accepts notifications and issues zone transfers with hmac-sha256 secrets should work out of the box. If you encounter interoperability issues, please get in touch with me.</p> +<p>The <code>secondary</code> subdirectory of the cloned <code>unikernels</code> repository is another unikernel that acts as secondary server. It's only command line argument is a list of hmac secrets used for authenticating that the received data originates from the primary server. Data is initially transferred by a <a href="https://tools.ietf.org/html/rfc5936">full zone transfer (AXFR)</a>, later updates (upon refresh timer or notify request sent by the primary) use <a href="https://tools.ietf.org/html/rfc1995">incremental (IXFR)</a>. Zone transfer requests and data are authenticated with transaction signatures again.</p> +<p>Convenience by OCaml DNS is that transfer key names matter, and are of the form <primary-ip>.<secondary-ip>._transfer.domain, i.e. <code>1.1.1.1.2.2.2.2._transfer.mirage</code> if the primary server is 1.1.1.1, and the secondary 2.2.2.2. Encoding the IP address in the name allows both parties to start the communication: the secondary starts by requesting a SOA for all domains for which keys are provided on command line, and if an authoritative SOA answer is received, the AXFR is triggered. The primary server emits notification requests on startup and then on every zone change (i.e. via git pull) to all secondary IP addresses of transfer keys present for the specific zone in addition to the notifications to the NS records in the zone.</p> +<pre><code class="language-shell">$ cd ../secondary +$ mirage configure --prng fortuna +# make depend should not be needed since all packages are already installed by the primary-git +$ make +$ ./secondary +</code></pre> +<h3>IP addresses and routing</h3> +<p>Both primary and secondary serve the data on the DNS port (53) on UDP and TCP. To run both on the same machine and bind them to different IP addresses, we'll use a layer 2 network (ethernet frames) with a host system software switch (bridge interface <code>service</code>), the unikernels as virtual machines (or seccomp-sandboxed) via the <a href="https://github.com/solo5/solo5">solo5</a> backend. Using xen is possible as well. As IP address range we'll use 10.0.42.0/24, and the host system uses the 10.0.42.1.</p> +<p>The primary git needs connectivity to the remote git repository, thus on a laptop in a private network we need network address translation (NAT) from the bridge where the unikernels speak to the Internet where the git repository resides.</p> +<pre><code class="language-shell"># on FreeBSD: +# configure NAT with pf, you need to have forwarding enabled +$ sysctl net.inet.ip.forwarding: 1 +$ echo 'nat pass on wlan0 inet from 10.0.42.0/24 to any -> (wlan0)' >> /etc/pf.conf +$ service pf restart + +# make tap interfaces UP on open() +$ sysctl net.link.tap.up_on_open: 1 + +# bridge creation, naming, and IP setup +$ ifconfig bridge create +bridge0 +$ ifconfig bridge0 name service +$ ifconfig bridge0 10.0.42.1/24 + +# two tap interfaces for our unikernels +$ ifconfig tap create +tap0 +$ ifconfig tap create +tap1 +# add them to the bridge +$ ifconfig service addm tap0 addm tap1 +</code></pre> +<h3>Primary and secondary setup</h3> +<p>Let's update our zone slightly to reflect the IP changes.</p> +<pre><code class="language-shell">git-repo> cat mirage +$ORIGIN mirage. +$TTL 3600 +@ SOA ns1 hostmaster 2 86400 7200 1048576 3600 +@ NS ns1 +@ NS ns2 +ns1 A 10.0.42.2 +ns2 A 10.0.42.3 + +# we also need an additional transfer key +git-repo> cat mirage._keys +personal._update.mirage. DNSKEY 0 3 163 kJJqipaQHQWqZL31Raar6uPnepGFIdtpjkXot9rv2xg= +10.0.42.2.10.0.42.3._transfer.mirage. DNSKEY 0 3 163 cDK6sKyvlt8UBerZlmxuD84ih2KookJGDagJlLVNo20= +git-repo> git commit -m "udpates" . && git push +</code></pre> +<p>Ok, the git repository is ready, now we need to compile the unikernels for the virtualisation target (see <a href="https://mirage.io/wiki/hello-world#Building-for-Another-Backend">other targets</a> for further information).</p> +<pre><code class="language-shell"># back to primary +$ cd ../primary-git +$ mirage configure -t hvt --prng fortuna # or e.g. -t spt (and solo5-spt below) +# installs backend-specific opam packages, recompiles some +$ make depend +$ make +[...] +$ solo5-hvt --net:service=tap0 -- primary_git.hvt --ipv4=10.0.42.2/24 --ipv4-gateway=10.0.42.1 --seed=.. --authenticator=.. --remote=ssh+git://... +# should now run as a virtual machine (kvm, bhyve), and clone the git repository +$ dig any mirage @10.0.42.2 +# should reply with the SOA and NS records, and also the name server address records in the additional section + +# secondary +$ cd ../secondary +$ mirage configure -t hvt --prng fortuna +$ make +$ solo5-hvt --net:service=tap1 -- secondary.hvt --ipv4=10.0.42.3/24 --keys=10.0.42.2.10.0.42.3._transfer.mirage:SHA256:cDK6sKyvlt8UBerZlmxuD84ih2KookJGDagJlLVNo20= +# an ipv4-gateway is not needed in this setup, but in real deployment later +# it should start up and transfer the mirage zone from the primary + +$ dig any mirage @10.0.42.3 +# should now output the same information as from 10.0.42.2 + +# testing an update and propagation +# edit mirage zone, add a new record and increment the serial number +git-repo> echo "foo A 127.0.0.1" >> mirage +git-repo> vi mirage <- increment serial +git-repo> git commit -m 'add foo' . && git push +$ onotify 10.0.42.2 mirage --key=personal._update.mirage:SHA256:kJJqipaQHQWqZL31Raar6uPnepGFIdtpjkXot9rv2xg= + +# now check that it worked +$ dig foo.mirage @10.0.42.2 # primary +$ dig foo.mirage @10.0.42.3 # secondary got notified and transferred the zone +</code></pre> +<p>You can also check the behaviour when restarting either of the VMs, whenever the primary is available the zone is synchronised. If the primary is down, the secondary still serves the zone. When the secondary is started while the primary is down, it won't serve any data until the primary is online (the secondary polls periodically, the primary sends notifies on startup).</p> +<h3>Dynamic data updates via DNS, pushed to git</h3> +<p>DNS is a rich protocol, and it also has builtin <a href="https://tools.ietf.org/html/rfc2136">updates</a> that are supported by OCaml DNS, again authenticated with hmac-sha256 and shared secrets. Bind provides the command-line utility <code>nsupdate</code> to send these update packets, a simple <code>oupdate</code> unix utility is available as well (i.e. for integration of dynamic DNS clients). You know the drill, add a shared secret to the primary, git push, notify the primary, and voila we can dynamically in-protocol update. An update received by the primary via this way will trigger a git push to the remote git repository, and notifications to the secondary servers as described above.</p> +<pre><code class="language-shell"># being lazy, I reuse the key above +$ oupdate 10.0.42.2 personal._update.mirage:SHA256:kJJqipaQHQWqZL31Raar6uPnepGFIdtpjkXot9rv2xg= my-other.mirage 1.2.3.4 + +# let's observe the remote git +git-repo> git pull +# there should be a new commit generated by the primary +git-repo> git log + +# test it, should return 1.2.3.4 +$ dig my-other.mirage @10.0.42.2 +$ dig my-other.mirage @10.0.42.3 +</code></pre> +<p>So we can deploy further <code>oupdate</code> (or <code>nsupdate</code>) clients, distribute hmac secrets, and have the DNS zone updated. The source of truth is still the git repository, where the primary-git pushes to. Merge conflicts and timing of pushes is not yet dealt with. They are unlikely to happen since the primary is notified on pushes and should have up-to-date data in storage. Sorry, I'm unsure about the error semantics, try it yourself.</p> +<h3>Let's encrypt!</h3> +<p><a href="https://letsencrypt.org/">Let's encrypt</a> is a certificate authority (CA), which certificate is shipped as trust anchor in web browsers. They specified a protocol for <a href="https://tools.ietf.org/html/draft-ietf-acme-acme-05">automated certificate management environment (ACME)</a>, used to get X509 certificates for your services. In the protocol, a certificate signing request (publickey and hostname) is sent to let's encrypt servers, which sends a challenge to proof the ownership of the hostnames. One widely-used way to solve this challenge is running a web server, another is to serve it as text record from the authoritative DNS server.</p> +<p>Since I avoid persistent storage when possible, and also don't want to integrate a HTTP client stack in the primary server, I developed a third unikernel that acts as (hidden) secondary server, performs the tedious HTTP communication with let's encrypt servers, and stores all data in the public DNS zone.</p> +<p>For encoding of certificates, the DANE working group specified <a href="https://tools.ietf.org/html/rfc6698.html#section-7.1">TLSA</a> records in DNS. They are quadruples of usage, selector, matching type, and ASN.1 DER-encoded material. We set usage to 3 (domain-issued certificate), matching type to 0 (no hash), and selector to 0 (full certificate) or 255 (private usage) for certificate signing requests. The interaction is as follows:</p> +<ol> +<li>Primary, secondary, and let's encrypt unikernels are running +</li> +<li>A service (<code>ocertify</code>, <code>unikernels/certificate</code>, or the <code>dns-certify.mirage</code> library) demands a TLS certificate, and has a hmac-secret for the primary DNS +</li> +<li>The service generates a certificate signing request with the desired hostname(s), and performs an nsupdate with TLSA 255 <DER encoded signing-request> +</li> +<li>The primary accepts the update, pushes the new zone to git, and sends notifies to secondary and let's encrypt unikernels which (incrementally) transfer the zone +</li> +<li>The let's encrypt unikernel notices while transferring the zone a signing request without a certificate, starts HTTP interaction with let's encrypt +</li> +<li>The let's encrypt unikernel solves the challenge, sends the response as update of a TXT record to the primary nameserver +</li> +<li>The primary pushes the TXT record to git, and notifies secondaries (which transfer the zone) +</li> +<li>The let's encrypt servers request the TXT record from either or both authoritative name servers +</li> +<li>The let's encrypt unikernel polls for the issued certificate and send an update to the primary TLSA 0 <DER encoded certificate> +</li> +<li>The primary pushes the certificate to git, notifies secondaries (which transfer the zone) +</li> +<li>The service polls TLSA records for the hostname, and use it upon retrieval +</li> +</ol> +<p>Note that neither the signing request nor the certificate contain private key material, thus it is fine to serve them publically. Please also note, that the service polls for the certificate for the hostname in DNS, which is valid (start and end date) certificate and uses the same public key, this certificate is used and steps 3-10 are not executed.</p> +<p>The let's encrypt unikernel does not serve anything, it is a reactive system which acts upon notification from the primary. Thus, it can be executed in a private address space (with a NAT). Since the OCaml DNS server stack needs to push notifications to it, it preserves all incoming signed SOA requests as candidates for notifications on update. The let's encrypt unikernel ensures to always have a connection to the primary to receive notifications.</p> +<pre><code class="language-shell"># getting let's encrypt up and running +$ cd ../lets-encrypt +$ mirage configure -t hvt --prng fortuna +$ make depend +$ make + +# run it +$ solo5-hvt --net:service=tap2 -- letsencrypt.hvt --keys=... + +# test it +$ ocertify 10.0.42.2 foo.mirage +</code></pre> +<p>For actual testing with let's encrypt servers you need to have the primary and secondary deployed on your remote hosts, and your domain needs to be delegated to these servers. Good luck. And ensure you have backup your git repository.</p> +<p>As fine print, while this tutorial was about the <code>mirage</code> zone, you can stick any number of zones into the git repository. If you use a <code>_keys</code> file (without any domain prefix), you can configure hmac secrets for all zones, i.e. something to use in your let's encrypt unikernel and secondary unikernel. Dynamic addition of zones is supported, just create a new zonefile and notify the primary, the secondary will be notified and pick it up. The primary responds to a signed SOA for the root zone (i.e. requested by the secondary) with the SOA response (not authoritative), and additionally notifications for all domains of the primary.</p> +<h3>Conclusion and thanks</h3> +<p>This tutorial presented how to use the OCaml DNS based unikernels to run authoritative name servers for your domain, using a git repository as the source of truth, dynamic authenticated updates, and let's encrypt certificate issuing.</p> +<p>There are further steps to take, such as monitoring -- have a look at the <code>monitoring</code> branch of the opam repository above, and the <code>future-robur</code> branch of the unikernels repository above, which use a second network interface for reporting syslog and metrics to telegraf / influx / grafana. Some DNS features are still missing, most prominently DNSSec.</p> +<p>I'd like to thank all people involved in this software stack, without other key components, including <a href="https://github.com/mirage/ocaml-git">git</a>, <a href="https://irmin.io/">irmin 2.0</a>, <a href="https://github.com/mirleft/ocaml-nocrypto">nocrypto</a>, <a href="https://github.com/haesbaert/awa-ssh">awa-ssh</a>, <a href="https://github.com/mirage/ocaml-cohttp">cohttp</a>, <a href="https://github.com/solo5/sol5">solo5</a>, <a href="https://github.com/mirage/mirage">mirage</a>, <a href="https://github.com/mmaker/ocaml-letsencrypt">ocaml-letsencrypt</a>, and more.</p> +<p>If you want to support our work on MirageOS unikernels, please <a href="https://robur.coop/Donate">donate to robur</a>. I'm interested in feedback, either via <a href="https://twitter.com/h4nnes">twitter</a>, <a href="https://mastodon.social/@hannesm">hannesm@mastodon.social</a> or via eMail.</p> +urn:uuid:e3d4fd9e-e379-5c86-838e-46034ddd435dDeploying authoritative OCaml-DNS servers as MirageOS unikernels2021-11-19T18:04:52-00:00hannes

<p>MirageOS unikernels are reproducible :)</p> +

2019-12-16T18:29:30-00:00<h2>Reproducible builds summit</h2> +<p>I'm just back from the <a href="https://reproducible-builds.org/events/Marrakesh2019/">Reproducible builds summit 2019</a>. In 2018, several people developing <a href="https://ocaml.org">OCaml</a> and <a href="https://opam.ocaml.org">opam</a> and <a href="https://mirage.io">MirageOS</a>, attended <a href="https://reproducible-builds.org/events/paris2018/">the Reproducible builds summit in Paris</a>. The notes from last year on <a href="https://reproducible-builds.org/events/paris2018/report/#Toc11410_331763073">opam reproducibility</a> and <a href="https://reproducible-builds.org/events/paris2018/report/#Toc11681_331763073">MirageOS reproducibility</a> are online. After last years workshop, Raja started developing the opam reproducibilty builder <a href="https://github.com/rjbou/orb">orb</a>, which I extended at and after this years summit. This year before and after the facilitated summit there were hacking days, which allowed further interaction with participants, writing some code and conduct experiments. I had this year again an exciting time at the summit and hacking days, thanks to our hosts, organisers, and all participants.</p> +<h2>Goal</h2> +<p>Stepping back a bit, first look on the <a href="https://reproducible-builds.org/">goal of reproducible builds</a>: when compiling source code multiple times, the produced binaries should be identical. It should be sufficient if the binaries are behaviourally equal, but this is pretty hard to check. It is much easier to check <strong>bit-wise identity of binaries</strong>, and relaxes the burden on the checker -- checking for reproducibility is reduced to computing the hash of the binaries. Let's stick to the bit-wise identical binary definition, which also means software developers have to avoid non-determinism during compilation in their toolchains, dependent libraries, and developed code.</p> +<p>A <a href="https://reproducible-builds.org/docs/test-bench/">checklist</a> of potential things leading to non-determinism has been written up by the reproducible builds project. Examples include recording the build timestamp into the binary, ordering of code and embedded data. The reproducible builds project also developed <a href="https://packages.debian.org/sid/disorderfs">disorderfs</a> for testing reproducibility and <a href="https://diffoscope.org/">diffoscope</a> for comparing binaries with file-dependent readers, falling back to <code>objdump</code> and <code>hexdump</code>. A giant <a href="https://tests.reproducible-builds.org/">test infrastructure</a> with <a href="https://tests.reproducible-builds.org/debian/index_variations.html">lots of variations</a> between the builds, mostly using Debian, has been setup over the years.</p> +<p>Reproducibility is a precondition for trustworthy binaries. See <a href="https://reproducible-builds.org/#why-does-it-matter">why does it matter</a>. If there are no instructions how to get from the published sources to the exact binary, why should anyone trust and use the binary which claims to be the result of the sources? It may as well contain different code, including a backdoor, bitcoin mining code, outputting the wrong results for specific inputs, etc. Reproducibility does not imply the software is free of security issues or backdoors, but instead of a audit of the binary - which is tedious and rarely done - the source code can be audited - but the toolchain (compiler, linker, ..) used for compilation needs to be taken into account, i.e. trusted or audited to not be malicious. <strong>I will only ever publish binaries if they are reproducible</strong>.</p> +<p>My main interest at the summit was to enhance existing tooling and conduct some experiments about the reproducibility of <a href="https://mirage.io">MirageOS unikernels</a> -- a unikernel is a statically linked ELF binary to be run as Unix process or <a href="https://github.com/solo5/solo5">virtual machine</a>. MirageOS heavily uses <a href="https://ocaml.org">OCaml</a> and <a href="https://opam.ocaml.org">opam</a>, the OCaml package manager, and is an opam package itself. Thus, <em>checking reproducibility of a MirageOS unikernel is the same problem as checking reproducibility of an opam package</em>.</p> +<h2>Reproducible builds with opam</h2> +<p>Testing for reproducibility is achieved by taking the sources and compile them twice independently. Afterwards the equality of the resulting binaries can be checked. In trivial projects, the sources is just a single file, or originate from a single tarball. In OCaml, opam uses <a href="https://github.com/ocaml/opam-repository">a community repository</a> where OCaml developers publish their package releases to, but can also use custom repositores, and in addition pin packages to git remotes (url including branch or commit), or a directory on the local filesystem. Manually tracking and updating all dependent packages of a MirageOS unikernel is not feasible: our hello-world compiled for hvt (kvm/BHyve) already has 79 opam dependencies, including the OCaml compiler which is distribued as opam package. The unikernel serving this website depends on 175 opam packages.</p> +<p>Conceptually there should be two tools, the <em>initial builder</em>, which takes the latest opam packages which do not conflict, and exports exact package versions used during the build, as well as hashes of binaries. The other tool is a <em>rebuilder</em>, which imports the export, conducts a build, and outputs the hashes of the produced binaries.</p> +<p>Opam has the concept of a <code>switch</code>, which is an environment where a package set is installed. Switches are independent of each other, and can already be exported and imported. Unfortunately the export is incomplete: if a package includes additional patches as part of the repository -- sometimes needed for fixing releases where the actual author or maintainer of a package responds slowly -- these package neither the patches end up in the export. Also, if a package is pinned to a git branch, the branch appears in the export, but this may change over time by pushing more commits or even force-pushing to that branch. In <a href="https://github.com/ocaml/opam/pull/4040">PR #4040</a> (under discussion and review), also developed during the summit, I propose to embed the additional files as base64 encoded values in the opam file. To solve the latter issue, I modified the export mechanism to <a href="https://github.com/ocaml/opam/pull/4055">embed the git commit hash (PR #4055)</a>, and avoid sources from a local directory and which do not have a checksum.</p> +<p>So the opam export contains the information required to gather the exact same sources and build instructions of the opam packages. If the opam repository would be self-contained (i.e. not depend on any other tools), this would be sufficient. But opam does not run in thin air, it requires some system utilities such as <code>/bin/sh</code>, <code>sed</code>, a GNU make, commonly <code>git</code>, a C compiler, a linker, an assembler. Since opam is available on various operating systems, the plugin <code>depext</code> handles host system dependencies, e.g. if your opam package requires <code>gmp</code> to be installed, this requires slightly different names depending on host system or distribution, take a look at <a href="https://github.com/ocaml/opam-repository/blob/master/packages/conf-gmp/conf-gmp.1/opam">conf-gmp</a>. This also means, opam has rather good information about both the opam dependencies and the host system dependencies for each package. Please note that the host system packages used during compilation are not yet recorded (i.e. which <code>gmp</code> package was installed and used during the build, only that a <code>gmp</code> package has to be installed). The base utilities mentioned above (C compiler, linker, shell) are also not recorded yet.</p> +<p>Operating system information available in opam (such as architecture, distribution, version), which in some cases maps to exact base utilities, is recorded in the build-environment, a separate artifact. The environment variable <a href="https://reproducible-builds.org/specs/source-date-epoch/"><code>SOURCE_DATE_EPOCH</code></a>, used for communicating the same timestamp when software is required to record a timestamp into the resulting binary, is also captured in the build environment.</p> +<p>Additional environment variables may be captured or used by opam packages to produce different output. To avoid this, both the initial builder and the rebuilder are run with minimal environment variables: only <code>PATH</code> (normalised to a whitelist of <code>/bin</code>, <code>/usr/bin</code>, <code>/usr/local/bin</code> and <code>/opt/bin</code>) and <code>HOME</code> are defined. Missing information at the moment includes CPU features: some libraries (gmp?, nocrypto) emit different code depending on the CPU feature.</p> +<h2>Tooling</h2> +<p><em>TL;DR: A <strong>build</strong> builds an opam package, and outputs <code>.opam-switch</code>, <code>.build-hashes.N</code>, and <code>.build-environment.N</code>. A <strong>rebuild</strong> uses these artifacts as input, builds the package and outputs another <code>.build-hashes.M</code> and <code>.build-environment.M</code>.</em></p> +<p>The command-line utility <code>orb</code> can be installed and used:</p> +<pre><code class="language-sh">$ opam pin add orb git+https://github.com/hannesm/orb.git#active +$ orb build --twice --keep-build-dir --diffoscope <your-favourite-opam-package> +</code></pre> +<p>It provides two subcommands <code>build</code> and <code>rebuild</code>. The <code>build</code> command takes a list of local opam <code>--repos</code> where to take opam packages from (defaults to <code>default</code>), a compiler (either a variant <code>--compiler=4.09.0+flambda</code>, a version <code>--compiler=4.06.0</code>, or a pin to a local development version <code>--compiler-pin=~/ocaml</code>), and optionally an existing switch <code>--use-switch</code>. It creates a switch, builds the packages, and emits the opam export, hashes of all files installed by these packages, and the build environment. The flags <code>--keep-build</code> retains the build products, opam's <code>--keep-build-dir</code> in addition temporary build products and generated source code. If <code>--twice</code> is provided, a rebuild (described next) is executed after the initial build.</p> +<p>The <code>rebuild</code> command takes a directory with the opam export and build environment to build the opam package. It first compares the build-environment with the host system, sets the <code>SOURCE_DATE_EPOCH</code> and switch location accordingly and executes the import. Once the build is finished, it compares the hashes of the resulting files with the previous run. On divergence, if build directories were kept in the previous build, and if diffoscope is available and <code>--diffoscope</code> was provided, diffoscope is run on the diverging files. If <code>--keep-build-dir</code> was provided as well, <code>diff -ur</code> can be used to compare the temporary build and sources, including build logs.</p> +<p>The builds are run in parallel, as opam does, this parallelism does not lead to different binaries in my experiments.</p> +<h2>Results and discussion</h2> +<p><strong>All MirageOS unikernels I have deployed are reproducible \o/</strong>. Also, several binaries such as <code>orb</code> itself, <code>opam</code>, <code>solo5-hvt</code>, and all <code>albatross</code> utilities are reproducible.</p> +<p>The unikernel range from hello world, web servers (e.g. this blog, getting its data on startup via a git clone to memory), authoritative DNS servers, CalDAV server. They vary in size between 79 and 200 opam packages, resulting in 2MB - 16MB big ELF binaries (including debug symbols). The <a href="https://github.com/roburio/reproducible-unikernel-repo">unikernel opam repository</a> contains some reproducible unikernels used for testing. Some work-in-progress enhancements are needed to achieve this:</p> +<p>At the moment, the opam package of a MirageOS unikernel is automatically generated by <code>mirage configure</code>, but only used for tracking opam dependencies. I worked on <a href="https://github.com/mirage/mirage/pull/1022">mirage PR #1022</a> to extend the generated opam package with build and install instructions.</p> +<p>As mentioned above, if locale is set, ocamlgraph needs to be patched to emit a (locale-dependent) timestamp.</p> +<p>The OCaml program <a href="https://github.com/mirage/ocaml-crunch"><code>crunch</code></a> embeds a subdirectory as OCaml code into a binary, which we use in MirageOS quite regularly for static assets, etc. This plays in several ways into reproducibility: on the one hand, it needs a timestamp for its <code>last_modified</code> functionality (and adheres since <a href="https://github.com/mirage/ocaml-crunch/pull/45">June 2018</a> to the <code>SOURCE_DATE_EPOCH</code> spec, thanks to Xavier Clerc). On the other hand, it used before version 3.2.0 (released Dec 14th) hashtables for storing the file contents, where iteration is not deterministic (the insertion is not sorted), <a href="https://github.com/mirage/ocaml-crunch/pull/51">fixed in PR #51</a> by using a Map instead.</p> +<p>In functoria, a tool used to configure MirageOS devices and their dependencies, can emit a list of opam packages which were required to build the unikernel. This uses <code>opam list --required-by --installed --rec <pkgs></code>, which uses the cudf graph (<a href="https://github.com/mirage/functoria/pull/189#issuecomment-566696426">thanks to Raja for explanation</a>), that is during the rebuild dropping some packages. The <a href="https://github.com/mirage/functoria/pull/189">PR #189</a> avoids by not using the <code>--rec</code> argument, but manually computing the fixpoint.</p> +<p>Certainly, the choice of environment variables, and whether to vary them (as <a href="https://tests.reproducible-builds.org/debian/index_variations.html">debian does</a>) or to not define them (or normalise) while building, is arguably. Since MirageOS does neither support time zone nor internationalisation, there is no need to prematurely solving this issue. On related note, even with different locale settings, MirageOS unikernels are reproducible apart from an <a href="https://github.com/backtracking/ocamlgraph/pull/90">issue in ocamlgraph #90</a> embedding the output of <a href="https://pubs.opengroup.org/onlinepubs/9699919799/utilities/date.html"><code>date</code></a>, which is different depending on <code>LANG</code> and locale (<code>LC_*</code>) settings.</p> +<p>Prior art in reproducible MirageOS unikernels is the <a href="https://github.com/mirage/qubes-mirage-firewall/">mirage-qubes-firewall</a>. Since <a href="https://github.com/mirage/qubes-mirage-firewall/commit/07ff3d61477383860216c69869a1ffee59145e45">early 2017</a> it is reproducible. Their approach is different by building in a docker container with the opam repository pinned to an exact git commit.</p> +<h2>Further work</h2> +<p>I only tested a certain subset of opam packages and MirageOS unikernels, mainly on a single machine (my laptop) running FreeBSD, and am happy if others will test reproducibility of their OCaml programs with the tools provided. There could as well be CI machines rebuilding opam packages and reporting results to a central repository. I'm pretty sure there are more reproducibility issues in the opam ecosystem. I developed an <a href="https://github.com/roburio/reproducible-testing-repo">reproducible testing opam repository</a> with opam packages that do not depend on OCaml, mainly for further tooling development. Some tests were also conducted on a Debian system with the same result. The variations, apart from build time, were using a different user, and different locale settings.</p> +<p>As mentioned above, more environment, such as the CPU features, and external system packages, should be captured in the build environment.</p> +<p>When comparing OCaml libraries, some output files (cmt / cmti / cma / cmxa) are not deterministic, but contain minimal diverge where I was not able to spot the root cause. It would be great to fix this, likely in the OCaml compiler distribution. Since the final result, the binary I'm interested in, is not affected by non-identical intermediate build products, I hope someone (you?) is interested in improving on this side. OCaml bytecode output also seems to be non-deterministic. There is <a href="https://github.com/coq/coq/issues/11229">a discussion on the coq issue tracker</a> which may be related.</p> +<p>In contrast to initial plans, I did not used the <a href="https://reproducible-builds.org/specs/build-path-prefix-map/"><code>BUILD_PATH_PREFIX_MAP</code></a> environment variable, which is implemented in OCaml by <a href="https://github.com/ocaml/ocaml/pull/1515">PR #1515</a> (and followups). The main reasons are that something in the OCaml toolchain (I suspect the bytecode interpreter) needed absolute paths to find libraries, thus I'd need a symlink from the left-hand side to the current build directory, which was tedious. Also, my installed assembler does not respect the build path prefix map, and BUILD_PATH_PREFIX_MAP is not widely supported. See e.g. the Debian <a href="https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/ocaml-zarith.html">zarith</a> package with different build paths and its effects on the binary.</p> +<p>I'm fine with recording the build path (switch location) in the build environment for now - it turns out to end up only once in MirageOS unikernels, likely by the last linking step, which <a href="http://blog.llvm.org/2019/11/deterministic-builds-with-clang-and-lld.html">hopefully soon be solved by llvm 9.0</a>.</p> +<p>What was fun was to compare the unikernel when built on Linux with gcc against a built on FreeBSD with clang and lld - spoiler: they emit debug sections with different dwarf versions, it is pretty big. Other fun differences were between OCaml compiler versions: the difference between minor versions (4.08.0 vs 4.08.1) is pretty small (~100kB as human-readable output), while the difference between major version (4.08.1 vs 4.09.0) is rather big (~900kB as human-readable diff).</p> +<p>An item on my list for the future is to distribute the opam export, build hashes and build environment artifacts in a authenticated way. I want to integrate this as <a href="https://in-toto.io/">in-toto</a> style into <a href="https://github.com/hannesm/conex">conex</a>, my not-yet-deployed implementation of <a href="https://theupdateframework.github.io/">tuf</a> for opam that needs further development and a test installation, hopefully in 2020.</p> +<p>If you want to support our work on MirageOS unikernels, please <a href="https://robur.coop/Donate">donate to robur</a>. I'm interested in feedback, either via <a href="https://twitter.com/h4nnes">twitter</a>, <a href="https://mastodon.social/@hannesm">hannesm@mastodon.social</a> or via eMail.</p> +urn:uuid:09922d6b-56c8-595d-8086-5aef9656cbc4Reproducible MirageOS unikernel builds2021-11-19T18:04:52-00:00hannes

<p>Five years since ocaml-x509 initial release, it has been reworked and used more widely</p> +

2019-08-15T11:21:30-00:00<h2>Cryptographic material</h2> +<p>Once a private and public key pair is generated (doesn't matter whether it is plain RSA, DSA, ECC on any curve), this is fine from a scientific point of view, and can already be used for authenticating and encrypting. From a practical point of view, the public parts need to be exchanged and verified (usually a fingerprint or hash thereof). This leads to the struggle how to encode this cryptographic material, and how to embed an identity (or multiple), capabilities, and other information into it. <a href="https://en.wikipedia.org/wiki/X.509">X.509</a> is a standard to solve this encoding and embedding, and provides more functionality, such as establishing chains of trust and revocation of invalidated or compromised material. X.509 uses certificates, which contain the public key, and additional information (in a extensible key-value store), and are signed by an issuer, either the private key corresponding to the public key - a so-called self-signed certificate - or by a different private key, an authority one step up the chain. A rather long, but very good introduction to certificates by Mike Malone is <a href="https://smallstep.com/blog/everything-pki.html">available here</a>.</p> +<h2>OCaml ecosystem evolving</h2> +<p>More than 5 years ago David Kaloper and I <a href="https://mirage.io/blog/introducing-x509">released the initial ocaml-x509</a> package as part of our <a href="https://nqsb.io">TLS stack</a>, which contained code for decoding and encoding certificates, and path validation of a certificate chain (as described in <a href="https://tools.ietf.org/html/rfc6125">RFC 5280</a>). The validation logic and the decoder/encoder, based on the ASN.1 grammar specified in the RFC, implemented using David's <a href="https://github.com/mirleft/ocaml-asn1-combinators">asn1-combinators</a> library changed much over time.</p> +<p>The OCaml ecosystem evolved over the years, which lead to some changes:</p> +<ul> +<li>Camlp4 deprecation - we used camlp4 for stream parsers of PEM-encoded certificates, and sexplib.syntax to derive s-expression decoders and encoders; +</li> +<li>Avoiding brittle ppx converters - which we used for s-expression decoders and encoders of certificates after camlp4 was deprecated; +</li> +<li>Build and release system iterations - initially oasis and a packed library, then topkg and ocamlbuild, now dune; +</li> +<li>Introduction of the <code>result</code> type in the standard library - we used to use <code>[ `Ok of certificate option | `Fail of failure ]</code>; +</li> +<li>No more leaking exceptions in the public API; +</li> +<li>Usage of pretty-printers, esp with the <a href="https://erratique.ch/software/fmt">fmt</a> library <code>val pp : Format.formatter -> 'a -> unit</code>, instead of <code>val to_string : t -> string</code> functions; +</li> +<li>Release of <a href="https://erratique.ch/software/ptime">ptime</a>, a platform-independent POSIX time support; +</li> +<li>Release of <a href="https://erratique.ch/software/rresult">rresult</a>, which includes combinators for computation <code>result</code>s; +</li> +<li>Release of <a href="https://github.com/hannesm/gmap">gmap</a>, a <code>Map</code> whose value types depend on the key, used for X.509 extensions, GeneralName, DistinguishedName, etc.; +</li> +<li>Release of <a href="https://github.com/hannesm/domain-name">domain-name</a>, a library for domain name operations (as specified in <a href="https://tools.ietf.org/html/rfc1035">RFC 1035</a>) - used for name validation; +</li> +<li>Usage of the <a href="https://github.com/mirage/alcotest">alcotest</a> unit testing framework (instead of oUnit). +</li> +</ul> +<h2>More use cases for X.509</h2> +<p>Initially, we designed and used ocaml-x509 for providing TLS server endpoints and validation in TLS clients - mostly on the public web, where each operating system ships a set of ~100 trust anchors to validate any web server certificate against. But once you have a X.509 implementation, every authentication problem can be solved by applying it.</p> +<h3>Authentication with path building</h3> +<p>It turns out that the trust anchor sets are not equal across operating systems and versions, thus some web servers serve sets, instead of chains, of certificates - as described in <a href="https://tools.ietf.org/html/rfc4158">RFC 4158</a>, where the client implementation needs to build valid paths and accept a connection if any path can be validated. The path building was initially in 0.5.2 slightly wrong, but fixed quickly in <a href="https://github.com/mirleft/ocaml-x509/commit/1a1476308d24bdcc49d45c4cd9ef539ca57461d2">0.5.3</a>.</p> +<h3>Fingerprint authentication</h3> +<p>The chain of trust validation is useful for the open web, where you as software developer don't know to which remote endpoint your software will ever connect to - as long as the remote has a certificate signed (via intermediates) by any of the trust anchors. In the early days, before <a href="https://letsencrypt.org/">let's encrypt</a> was launched and embedded as trust anchors (or cross-signed by already deployed trust anchors), operators needed to pay for a certificate - a business model where some CAs did not bother to check the authenticity of a certificate signing request, and thus random people owning valid certificates for microsoft.com or google.com.</p> +<p>Instead of using the set of trust anchors, the fingerprint of the server certificate, or preferably the fingerprint of the public key of the certificate, can be used for authentication, as optionally done since some years in <a href="https://github.com/hannesm/jackline/commit/a1e6f3159be1e45e6b690845e1b29366c41239a2">jackline</a>, an XMPP client. Support for this certificate / public key pinning was added in x509 0.2.1 / 0.5.0.</p> +<h3>Certificate signing requests</h3> +<p>Until x509 0.4.0 there was no support for generating certificate signing requests (CSR), as defined in PKCS 10, which are self-signed blobs containing a public key, an identity, and possibly extensions. Such as CSR is sent to the certificate authority, and after validation of ownership of the identity and paying a fee, the certificate is issued. Let's encrypt specified the ACME protocol which automates the proof of ownership: they provide a HTTP API for requesting a challenge, providing the response (the proof of ownership) via HTTP or DNS, and then allow the submission of a CSR and downloading the signed certificate. The ocaml-x509 library provides operations for creating such a CSR, and also for signing a CSR to generate a certificate.</p> +<p>Mindy developed the command-line utility <a href="https://github.com/yomimono/ocaml-certify/">certify</a> which uses these operations from the ocaml-x509 library and acts as a swiss-army knife purely in OCaml for these required operations.</p> +<p>Maker developed a <a href="https://github.com/mmaker/ocaml-letsencrypt">let's encrypt library</a> which implements the above mentioned ACME protocol for provisioning CSR to certificates, also using our ocaml-x509 library.</p> +<p>To complete the required certificate authority functionality, in x509 0.6.0 certificate revocation lists, both validation and signing, was implemented.</p> +<h3>Deploying unikernels</h3> +<p>As <a href="/Posts/VMM">described in another post</a>, I developed <a href="https://github.com/hannesm/albatross">albatross</a>, an orchestration system for MirageOS unikernels. This uses ASN.1 for internal socket communication and allows remote management via a TLS connection which is mutually authenticated with a X.509 client certificate. To encrypt the X.509 client certificate, first a TLS handshake where the server authenticates itself to the client is established, and over that connection another TLS handshake is established where the client certificate is requested. Note that this mechanism can be dropped with TLS 1.3, since there the certificates are transmitted over an already encrypted channel.</p> +<p>The client certificate already contains the command to execute remotely - as a custom extension, being it "show me the console output", or "destroy the unikernel with name = YYY", or "deploy the included unikernel image". The advantage is that the commands are already authenticated, and there is no need for developing an ad-hoc protocol on top of the TLS session. The resource limits, assigned by the authority, are also part of the certificate chain - i.e. the number of unikernels, access to network bridges, available accumulated memory, accumulated size for block devices, are constrained by the certificate chain presented to the server, and currently running unikernels. The names of the chain are used for access control - if Alice and Bob have intermediate certificates from the same CA, neither Alice may manage Bob's unikernels, nor Bob may manage Alice's unikernels. I'm using albatross since 2.5 years in production on two physical machines with ~20 unikernels total (multiple users, multiple administrative domains), and it works stable and is much nicer to deal with than <code>scp</code> and custom hacked shell scripts.</p> +<h2>Why 0.7?</h2> +<p>There are still some missing pieces in our ocaml-x509 implementation, namely modern ECC certificates (depending on elliptic curve primitives not yet available in OCaml), RSA-PSS signing (should be straightforward), PKCS 12 (there is a <a href="https://github.com/mirleft/ocaml-x509/pull/114">pull request</a>, but this should wait until asn1-combinators supports the <code>ANY defined BY</code> construct to cleanup the code), ... +Once these features are supported, the library should likely be named PKCS since it supports more than X.509, and released as 1.0.</p> +<p>The 0.7 release series moved a lot of modules and function names around, thus it is a major breaking release. By using a map instead of lists for extensions, GeneralName, ..., the API was further revised - invariants that each extension key (an ASN.1 object identifier) may occur at most once are now enforced. By not leaking exceptions through the public interface, the API is easier to use safely - see <a href="https://github.com/mmaker/ocaml-letsencrypt/commit/dc53518f46310f384c9526b1d96a8e8f815a09c7">let's encrypt</a>, <a href="https://git.robur.io/?p=openvpn.git;a=commitdiff;h=929c53116c1438ba1214f53df7506d32da566ccc">openvpn</a>, <a href="https://github.com/yomimono/ocaml-certify/pull/17">certify</a>, <a href="https://github.com/mirleft/ocaml-tls/pull/394">tls</a>, <a href="https://github.com/mirage/capnp-rpc/pull/158">capnp</a>, <a href="https://github.com/hannesm/albatross/commit/50ed6a8d1ead169b3e322aaccb469e870ad72acc">albatross</a>.</p> +<p>I intended in 0.7.0 to have much more precise types, esp. for the SubjectAlternativeName (SAN) extension that uses a GeneralName, but it turns out the GeneralName is as well used for NameConstraints (NC) in a different way -- IP in SAN is an IPv4 or IPv6 address, in CN it is the IP/netmask; DNS is a domain name in SAN, in CN it is a name starting with a leading dot (i.e. ".example.com"), which is not a valid domain name. In 0.7.1, based on a bug report, I had to revert these variants and use less precise types.</p> +<h2>Conclusion</h2> +<p>The work on X.509 was sponsored by <a href="http://ocamllabs.io/">OCaml Labs</a>. You can support our work at robur by a <a href="https://robur.io/Donate">donation</a>, which we will use to work on our OCaml and MirageOS projects. You can also reach out to us to realize commercial products.</p> +<p>I'm interested in feedback, either via <strike><a href="https://twitter.com/h4nnes">twitter</a></strike> <a href="https://mastodon.social/@hannesm">hannesm@mastodon.social</a> or via eMail.</p> +urn:uuid:f2cf2a6a-8eef-5c2c-be03-d81a1bf0f066X509 0.72021-11-19T18:04:52-00:00hannes

<p>Bringing MirageOS into production, take IV monitoring, CalDAV, DNS</p> +

2019-07-08T19:29:05-00:00<h2>Working at <a href="https://robur.io">robur</a></h2> +<p>As announced <a href="/Posts/DNS">previously</a>, I started to work at robur early 2018. We're a collective of five people, distributed around Europe and the US, with the goal to deploy MirageOS unikernels. We do this by developing bespoke MirageOS unikernels which provide useful services, and deploy them for ourselves. We also develop new libraries and enhance existing ones and other components of MirageOS. Example unikernels include <a href="https://robur.io">our website</a> which uses <a href="https://github.com/Engil/Canopy">Canopy</a>, a <a href="https://robur.io/Our%20Work/Projects#CalDAV-Server">CalDAV server that stores entries in a git remote</a>, and <a href="https://github.com/roburio/unikernels">DNS servers</a> (the latter two are further described below).</p> +<p>Robur is part of the non-profit company <a href="https://techcultivation.org">Center for the Cultivation of Technology</a>, who are managing the legal and administrative sides for us. We're ourselves responsible to acquire funding to pay ourselves reasonable salaries. We received funding for CalDAV from <a href="https://prototypefund.de">prototypefund</a> and further funding from <a href="https://tarides.com">Tarides</a>, for TLS 1.3 from <a href="http://ocamllabs.io/">OCaml Labs</a>; security-audited an OCaml codebase, and received <a href="https://robur.io/Donate">donations</a>, also in the form of Bitcoins. We're looking for further funded collaborations and also contracting, mail us at <code>team@robur.io</code>. Please <a href="https://robur.io/Donate">donate</a> (tax-deductible in EU), so we can accomplish our goal of putting robust and sustainable MirageOS unikernels into production, replacing insecure legacy system that emit tons of CO<span style="vertical-align: baseline; position: relative;bottom: -0.4em;">2</span>.</p> +<h2>Deploying MirageOS unikernels</h2> +<p>While several examples are running since years (the <a href="https://mirage.io">MirageOS website</a>, <a href="http://ownme.ipredator.se">Bitcoin Piñata</a>, <a href="https://tls.nqsb.io">TLS demo server</a>, etc.), and some shell-scripts for cloud providers are floating around, it is not (yet) streamlined.</p> +<p>Service deployment is complex: you have to consider its configuration, exfiltration of logs and metrics, provisioning with valid key material (TLS certificate, hmac shared secret) and authenticators (CA certificate, ssh key fingerprint). Instead of requiring millions lines of code during orchestration (such as Kubernetes), creating the images (docker), or provisioning (ansible), why not minimise the required configuration and dependencies?</p> +<p><a href="/Posts/VMM">Earlier in this blog I introduced Albatross</a>, which serves in an enhanced version as our deployment platform on a physical machine (running 15 unikernels at the moment), I won't discuss more detail thereof in this article.</p> +<h2>CalDAV</h2> +<p><a href="https://linse.me/">Steffi</a> and I developed in 2018 a CalDAV server. Since November 2018 we have a test installation for robur, initially running as a Unix process on a virtual machine and persisting data to files on the disk. Mid-June 2019 we migrated it to a MirageOS unikernel, thanks to great efforts in <a href="https://github.com/mirage/ocaml-git">git</a> and <a href="https://github.com/mirage/irmin">irmin</a>, unikernels can push to a remote git repository. We <a href="https://github.com/haesbaert/awa-ssh/pull/8">extended the ssh library</a> with a ssh client and <a href="https://github.com/mirage/ocaml-git/pull/362">use this in git</a>. This also means our CalDAV server is completely immutable (does not carry state across reboots, apart from the data in the remote repository) and does not have persistent state in the form of a block device. Its configuration is mainly done at compile time by the selection of libraries (syslog, monitoring, ...), and boot arguments passed to the unikernel at startup.</p> +<p>We monitored the resource usage when migrating our CalDAV server from Unix process to a MirageOS unikernel. The unikernel size is just below 10MB. The workload is some clients communicating with the server on a regular basis. We use <a href="https://grafana.com/">Grafana</a> with a <a href="https://www.influxdata.com/">influx</a> time series database to monitor virtual machines. Data is collected on the host system (<code>rusage</code> sysctl, <code>kinfo_mem</code> sysctl, <code>ifdata</code> sysctl, <code>vm_get_stats</code> BHyve statistics), and our unikernels these days emit further metrics (mostly counters: gc statistics, malloc statistics, tcp sessions, http requests and status codes).</p> +<p><a href="/static/img/crobur-june-2019.png"><img src="/static/img/crobur-june-2019.png" width="700" /></a></p> +<p>Please note that memory usage (upper right) and vm exits (lower right) use logarithmic scale. The CPU usage reduced by more than a factor of 4. The memory usage dropped by a factor of 25, and the network traffic increased - previously we stored log messages on the virtual machine itself, now we send them to a dedicated log host.</p> +<p>A MirageOS unikernel, apart from a smaller attack surface, indeed uses fewer resources and actually emits less CO<span style="vertical-align: baseline; position: relative;bottom: -0.4em;">2</span> than the same service on a Unix virtual machine. So we're doing something good for the environment! :)</p> +<p>Our calendar server contains at the moment 63 events, the git repository had around 500 commits in the past month: nearly all of them from the CalDAV server itself when a client modified data via CalDAV, and two manual commits: the initial data imported from the file system, and one commit for fixing a bug of the encoder in our <a href="https://github.com/roburio/icalendar/pull/2">icalendar library</a>.</p> +<p>Our CalDAV implementation is very basic, scheduling, adding attendees (which requires sending out eMail), is not supported. But it works well for us, we have individual calendars and a shared one which everyone can write to. On the client side we use macOS and iOS iCalendar, Android DAVdroid, and Thunderbird. If you like to try our CalDAV server, have a look <a href="https://github.com/roburio/caldav/tree/future/README.md">at our installation instructions</a>. Please <a href="https://github.com/roburio/caldav/issues">report issues</a> if you find issues or struggle with the installation.</p> +<h2>DNS</h2> +<p>There has been more work on our DNS implementation, now <a href="https://github.com/mirage/ocaml-dns">here</a>. We included a DNS client library, and some <a href="https://github.com/roburio/unikernels/tree/future">example unikernels</a> are available. They as well require our <a href="https://github.com/roburio/git-ssh-dns-mirage3-repo">opam repository overlay</a>. Please report issues if you run into trouble while experimenting with that.</p> +<p>Most prominently is <code>primary-git</code>, a unikernel which acts as a primary authoritative DNS server (UDP and TCP). On startup, it fetches a remote git repository that contains zone files and shared hmac secrets. The zones are served, and secondary servers are notified with the respective serial numbers of the zones, authenticated using TSIG with the shared secrets. The primary server provides dynamic in-protocol updates of DNS resource records (<code>nsupdate</code>), and after successful authentication pushes the change to the remote git. To change the zone, you can just edit the zonefile and push to the git remote - with the proper pre- and post-commit-hooks an authenticated notify is send to the primary server which then pulls the git remote.</p> +<p>Another noteworthy unikernel is <code>letsencrypt</code>, which acts as a secondary server, and whenever a TLSA record with custom type (0xFF) and a DER-encoded certificate signing request is observed, it requests a signature from letsencrypt by solving the DNS challenge. The certificate is pushed to the DNS server as TLSA record as well. The DNS implementation provides <code>ocertify</code> and <code>dns-mirage-certify</code> which use the above mechanism to retrieve valid let's encrypt certificates. The caller (unikernel or Unix command-line utility) either takes a private key directly or generates one from a (provided) seed and generates a certificate signing request. It then looks in DNS for a certificate which is still valid and matches the public key and the hostname. If such a certificate is not present, the certificate signing request is pushed to DNS (via the nsupdate protocol), authenticated using TSIG with a given secret. This way our public facing unikernels (website, this blog, TLS demo server, ..) block until they got a certificate via DNS on startup - we avoid embedding of the certificate into the unikernel image.</p> +<h2>Monitoring</h2> +<p>We like to gather statistics about the resource usage of our unikernels to find potential bottlenecks and observe memory leaks ;) The base for the setup is the <a href="https://github.com/mirage/metrics">metrics</a> library, which is similarly in design to the <a href="https://erratique.ch/software/logs">logs</a> library: libraries use the core to gather metrics. A different aspect is the reporter, which is globally registered and responsible for exfiltrating the data via their favourite protocol. If no reporter is registered, the work overhead is negligible.</p> +<p><a href="/static/img/crobur-june-2019-unikernel.png"><img src="/static/img/crobur-june-2019-unikernel.png" width="700" /></a></p> +<p>This is a dashboard which combines both statistics gathered from the host system and various metrics from the MirageOS unikernel. The <code>monitoring</code> branch of our opam repository overlay is used together with <a href="https://github.com/hannesm/monitoring-experiments">monitoring-experiments</a>. The logs errors counter (middle right) was the icalendar parser which tried to parse its badly emitted ics (the bug is now fixed, the dashboard is from last month).</p> +<h2>OCaml libraries</h2> +<p>The <a href="https://github.com/hannesm/domain-name">domain-name</a> library was developed to handle RFC 1035 domain names and host names. It initially was part of the DNS code, but is now freestanding to be used in other core libraries (such as ipaddr) with a small dependency footprint.</p> +<p>The <a href="https://github.com/hannesm/gmap">GADT map</a> is a normal OCaml Map structure, but takes key-dependent value types by using a GADT. This library also was part of DNS, but is more broadly useful, we already use it in our icalendar (the data format for calendar entries in CalDAV) library, our <a href="https://git.robur.io/?p=openvpn.git;a=summary">OpenVPN</a> configuration parser uses it as well, and also <a href="https://github.com/mirleft/ocaml-x509/pull/115">x509</a> - which got reworked quite a bit recently (release pending), and there's preliminary PKCS12 support (which deserves its own article). <a href="https://github.com/hannesm/ocaml-tls">TLS 1.3</a> is available on a branch, but is not yet merged. More work is underway, hopefully with sufficient time to write more articles about it.</p> +<h2>Conclusion</h2> +<p>More projects are happening as we speak, it takes time to upstream all the changes, such as monitoring, new core libraries, getting our DNS implementation released, pushing Conex into production, more features such as DNSSec, ...</p> +<p>I'm interested in feedback, either via <strike><a href="https://twitter.com/h4nnes">twitter</a></strike> <a href="https://mastodon.social/@hannesm">hannesm@mastodon.social</a> or via eMail.</p> +urn:uuid:fd3a6aa5-a7ba-549a-9d0f-5f05fa6c434eSummer 20192021-11-19T18:04:52-00:00hannes \ No newline at end of file diff --git a/index.html b/index.html new file mode 100644 index 0000000..1ec6330 --- /dev/null +++ b/index.html @@ -0,0 +1,28 @@ + +full stack engineer

Mirroring the opam repository and all tarballs

Re-developing an opam cache from scratch, as a MirageOS unikernel

All your metrics belong to influx

How to monitor your MirageOS unikernel with albatross and monitoring-experiments

Deploying binary MirageOS unikernels

Written by hannes 2021-04-23

Finally, we provide reproducible binary MirageOS unikernels together with packages to reproduce them and setup your own builder

Cryptography updates in OCaml and MirageOS

Elliptic curves (ECDSA/ECDH) are supported in a maintainable and secure way.

The road ahead for MirageOS in 2021

Written by hannes 2021-01-25

Home office, MirageOS unikernels, 2020 recap, 2021 tbd

Traceroute

A MirageOS unikernel which traces the path between itself and a remote host.

Deploying authoritative OCaml-DNS servers as MirageOS unikernels

A tutorial how to deploy authoritative name servers, let's encrypt, and updating entries from unix services.

Reproducible MirageOS unikernel builds

Written by hannes 2019-08-15

MirageOS unikernels are reproducible :)

X509 0.7

Five years since ocaml-x509 initial release, it has been reworked and used more widely

Summer 2019

Bringing MirageOS into production, take IV monitoring, CalDAV, DNS

The Bitcoin Piñata - no candy for you

More than three years ago we launched our Bitcoin Piñata as a transparent security bait. It is still up and running!

My 2018 contains robur and starts with re-engineering DNS

Albatross - provisioning, deploying, managing, and monitoring virtual machines

all we need is X.509

Conex, establish trust in community repositories

Conex is a library to verify and attest package release integrity and authenticity through the use of cryptographic signatures.

Who maintains package X?

Written by hannes 2017-01-30

We describe why manual gathering of metadata is out of date, and version control systems are awesome.

Jackline, a secure terminal-based XMPP client

implement it once to know you can do it. implement it a second time and you get readable code. implementing it a third time from scratch may lead to useful libraries.

Exfiltrating log data using syslog

sometimes preservation of data is useful

Re-engineering ARP

If you want it as you like, you've to do it yourself

Minimising the virtual machine monitor

MirageOS solo5 multiboot native on bhyve

Counting Bytes

looking into dependencies and their sizes

Configuration DSL step-by-step

Written by hannes 2016-05-03

how to actually configure the system

Catch the bug, walking through the stack

10BTC could've been yours

Fitting the things together

building a simple website

Why OCaml

a gentle introduction into OCaml

Operating systems

Operating systems and MirageOS

About

Written by hannes 2017-01-30

introduction (myself, this site)

\ No newline at end of file diff --git a/static/css/highlight.css b/static/css/highlight.css new file mode 100644 index 0000000..5376f34 --- /dev/null +++ b/static/css/highlight.css @@ -0,0 +1,101 @@ +/* + +grayscale style (c) MY Sun + +*/ + +.hljs { + display: block; + overflow-x: auto; + padding: 0.5em; + color: #333; + background: #fff; +} + +.hljs-comment, +.hljs-quote { + color: #777; + font-style: italic; +} + +.hljs-keyword, +.hljs-selector-tag, +.hljs-subst { + color: #333; + font-weight: bold; +} + +.hljs-number, +.hljs-literal { + color: #777; +} + +.hljs-string, +.hljs-doctag, +.hljs-formula { + color: #333; + background: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAQAAAAECAYAAACp8Z5+AAAAJ0lEQVQIW2O8e/fufwYGBgZBQUEQxcCIIfDu3Tuwivfv30NUoAsAALHpFMMLqZlPAAAAAElFTkSuQmCC) repeat; +} + +.hljs-title, +.hljs-section, +.hljs-selector-id { + color: #000; + font-weight: bold; +} + +.hljs-subst { + font-weight: normal; +} + +.hljs-class .hljs-title, +.hljs-type, +.hljs-name { + color: #333; + font-weight: bold; +} + +.hljs-tag { + color: #333; +} + +.hljs-regexp { + color: #333; + background: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAoAAAAICAYAAADA+m62AAAAPUlEQVQYV2NkQAN37979r6yszIgujiIAU4RNMVwhuiQ6H6wQl3XI4oy4FMHcCJPHcDS6J2A2EqUQpJhohQDexSef15DBCwAAAABJRU5ErkJggg==) repeat; +} + +.hljs-symbol, +.hljs-bullet, +.hljs-link { + color: #000; + background: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAKElEQVQIW2NkQAO7d+/+z4gsBhJwdXVlhAvCBECKwIIwAbhKZBUwBQA6hBpm5efZsgAAAABJRU5ErkJggg==) repeat; +} + +.hljs-built_in, +.hljs-builtin-name { + color: #000; + text-decoration: underline; +} + +.hljs-meta { + color: #999; + font-weight: bold; +} + +.hljs-deletion { + color: #fff; + background:url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAADCAYAAABS3WWCAAAAE0lEQVQIW2MMDQ39zzhz5kwIAQAyxweWgUHd1AAAAABJRU5ErkJggg==) repeat; +} + +.hljs-addition { + color: #000; + background: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAkAAAAJCAYAAADgkQYQAAAALUlEQVQYV2N89+7dfwYk8P79ewZBQUFkIQZGOiu6e/cuiptQHAPl0NtNxAQBAM97Oejj3Dg7AAAAAElFTkSuQmCC) repeat; +} + +.hljs-emphasis { + font-style: italic; +} + +.hljs-strong { + font-weight: bold; +} diff --git a/static/css/style.css b/static/css/style.css new file mode 100644 index 0000000..1c10220 --- /dev/null +++ b/static/css/style.css @@ -0,0 +1,152 @@ +html { + background-color: #fafafa; + font-family: medium-content-serif-font,Georgia,Cambria,"Times New Roman",Times,serif; + font-size: 21px; +} + +html a { + text-decoration-line: underline; + text-decoration-style: dotted; + text-decoration-color: #1a1a1a; + color: black; +} + +html a:visited { + text-decoration-line: underline; + text-decoration-style: dotted; + text-decoration-color: #1a1a1a; + color: black; +} + +li { + margin: 0.5em 0; + line-height: 1.6; +} + +p { + line-height: 1.6; +} + +.navbar { + box-sizing: border-box; + box-shadow: 0 2px 2px -2px rgba(0,0,0,.15); + position: fixed; + top: 0; + right: 0; + left: 0; + z-index: 1030; + background-color: white; +} + +.container { + margin: 0 auto; + max-width: 800px; +} + +blockquote { + font-style: italic; + padding: 0px 20px; + margin: 0 0 20px; + border-left: 5px solid #eee; +} + +main { + margin-top: 100px; +} + +.flex-container { + display: flex; + width: 100%; + justify-content: center; +} + +article { + margin-top: 30px; +} + +footer { + margin-top: 20px; +} + +pre { + padding: 0px; + line-height: 1.3; +} + +body h2 { + margin-bottom: 3px; + font-weight: 700; + font-size: 40px; + line-height: 1.04; + letter-spacing: -.028em; + font-family: medium-content-sans-serif-font,"Lucida Grande","Lucida Sans Unicode","Lucida Sans",Geneva,Arial,sans-serif; +} + +p > code { + word-wrap: break-word; +} + +.post-title { +} +.author { + font-size: 13px; +} +.date { + font-size: 13px; +} +time { + font-size: 13px; +} +footer { + font-size: 13px; +} +.tags { + font-size: 13px; +} +.post, +.listing { + width: 90%; + max-width: 800px; +} +a.list-group-item { + border: 0; +} +.extract { + margin-top: 10px; +} +.tag { + font-size: 13px; + margin-right: 4px; +} + +.navbar-nav { + clear:both; + margin-left: 0px; + padding-left: 0px; + font-family: medium-content-sans-serif-font,"Lucida Grande","Lucida Sans Unicode","Lucida Sans",Geneva,Arial,sans-serif; + font-size: 15px; +} + +.navbar-default li a, .navbar-default li a:visited { + color: #777; +} +.navbar-default li a:hover { + color: black; +} +.navbar-default li { + list-style-type: none; + font-size: 21px; + color: #777; + display: inline-block; + padding-right: 15px; +} + +.navbar-header { + background-color: #9B111E; +} +.navbar-brand { + font-family: "Helvetica Neue",Helvetica,Arial,sans-serif; + font-weight: 700; + font-size: 40px; + background-color: #9B111E; +} diff --git a/static/img/conex.png b/static/img/conex.png new file mode 100644 index 0000000..49b9937 Binary files /dev/null and b/static/img/conex.png differ diff --git a/static/img/crobur-june-2019-unikernel.png b/static/img/crobur-june-2019-unikernel.png new file mode 100644 index 0000000..226093f Binary files /dev/null and b/static/img/crobur-june-2019-unikernel.png differ diff --git a/static/img/crobur-june-2019.png b/static/img/crobur-june-2019.png new file mode 100644 index 0000000..63acaa5 Binary files /dev/null and b/static/img/crobur-june-2019.png differ diff --git a/static/img/encrypted-alert.png b/static/img/encrypted-alert.png new file mode 100644 index 0000000..d5e3e40 Binary files /dev/null and b/static/img/encrypted-alert.png differ diff --git a/static/img/jackline.png b/static/img/jackline.png new file mode 100644 index 0000000..1d19a6e Binary files /dev/null and b/static/img/jackline.png differ diff --git a/static/img/jackline2.png b/static/img/jackline2.png new file mode 100644 index 0000000..283e3a8 Binary files /dev/null and b/static/img/jackline2.png differ diff --git a/static/img/mirage-console-bytes.svg b/static/img/mirage-console-bytes.svg new file mode 100644 index 0000000..258be2e --- /dev/null +++ b/static/img/mirage-console-bytes.svg @@ -0,0 +1,40 @@ + diff --git a/static/img/mirage-console-xen-bytes-full.svg b/static/img/mirage-console-xen-bytes-full.svg new file mode 100644 index 0000000..1f5f87b --- /dev/null +++ b/static/img/mirage-console-xen-bytes-full.svg @@ -0,0 +1,55 @@ + diff --git a/static/img/mirage-console-xen.svg b/static/img/mirage-console-xen.svg new file mode 100644 index 0000000..b39bfb7 --- /dev/null +++ b/static/img/mirage-console-xen.svg @@ -0,0 +1,669 @@ + + + + + diff --git a/static/img/mirage-console.svg b/static/img/mirage-console.svg new file mode 100644 index 0000000..7c79d9b --- /dev/null +++ b/static/img/mirage-console.svg @@ -0,0 +1,407 @@ + + + + + diff --git a/static/img/performance-nqsbio.png b/static/img/performance-nqsbio.png new file mode 100644 index 0000000..cc5e8db Binary files /dev/null and b/static/img/performance-nqsbio.png differ diff --git a/static/img/pinata-bytes.svg b/static/img/pinata-bytes.svg new file mode 100644 index 0000000..9b7ed49 --- /dev/null +++ b/static/img/pinata-bytes.svg @@ -0,0 +1,95 @@ + diff --git a/static/img/pinata-deps.svg b/static/img/pinata-deps.svg new file mode 100644 index 0000000..495faa9 --- /dev/null +++ b/static/img/pinata-deps.svg @@ -0,0 +1,1341 @@ + + + + + diff --git a/static/img/pinata_access_20180403.png b/static/img/pinata_access_20180403.png new file mode 100644 index 0000000..bbae86b Binary files /dev/null and b/static/img/pinata_access_20180403.png differ diff --git a/static/img/pinata_access_cumulative_20180403.png b/static/img/pinata_access_cumulative_20180403.png new file mode 100644 index 0000000..74acd63 Binary files /dev/null and b/static/img/pinata_access_cumulative_20180403.png differ diff --git a/static/img/tcp-frame-client.png b/static/img/tcp-frame-client.png new file mode 100644 index 0000000..8abe1a2 Binary files /dev/null and b/static/img/tcp-frame-client.png differ diff --git a/static/img/tcp-frame-server.png b/static/img/tcp-frame-server.png new file mode 100644 index 0000000..c2595ed Binary files /dev/null and b/static/img/tcp-frame-server.png differ diff --git a/static/js/highlight.pack.js b/static/js/highlight.pack.js new file mode 100644 index 0000000..5b2fdab --- /dev/null +++ b/static/js/highlight.pack.js @@ -0,0 +1,2 @@ +/*! highlight.js v9.8.0 | BSD3 License | git.io/hljslicense */ +!function(e){var n="object"==typeof window&&window||"object"==typeof self&&self;"undefined"!=typeof exports?e(exports):n&&(n.hljs=e({}),"function"==typeof define&&define.amd&&define([],function(){return n.hljs}))}(function(e){function n(e){return e.replace(/[&<>]/gm,function(e){return I[e]})}function t(e){return e.nodeName.toLowerCase()}function r(e,n){var t=e&&e.exec(n);return t&&0===t.index}function a(e){return k.test(e)}function i(e){var n,t,r,i,o=e.className+" ";if(o+=e.parentNode?e.parentNode.className:"",t=B.exec(o))return R(t[1])?t[1]:"no-highlight";for(o=o.split(/\s+/),n=0,r=o.length;r>n;n++)if(i=o[n],a(i)||R(i))return i}function o(e,n){var t,r={};for(t in e)r[t]=e[t];if(n)for(t in n)r[t]=n[t];return r}function u(e){var n=[];return function r(e,a){for(var i=e.firstChild;i;i=i.nextSibling)3===i.nodeType?a+=i.nodeValue.length:1===i.nodeType&&(n.push({event:"start",offset:a,node:i}),a=r(i,a),t(i).match(/br|hr|img|input/)||n.push({event:"stop",offset:a,node:i}));return a}(e,0),n}function c(e,r,a){function i(){return e.length&&r.length?e[0].offset!==r[0].offset?e[0].offset"}function u(e){l+=""}function c(e){("start"===e.event?o:u)(e.node)}for(var s=0,l="",f=[];e.length||r.length;){var g=i();if(l+=n(a.substr(s,g[0].offset-s)),s=g[0].offset,g===e){f.reverse().forEach(u);do c(g.splice(0,1)[0]),g=i();while(g===e&&g.length&&g[0].offset===s);f.reverse().forEach(o)}else"start"===g[0].event?f.push(g[0].node):f.pop(),c(g.splice(0,1)[0])}return l+n(a.substr(s))}function s(e){function n(e){return e&&e.source||e}function t(t,r){return new RegExp(n(t),"m"+(e.cI?"i":"")+(r?"g":""))}function r(a,i){if(!a.compiled){if(a.compiled=!0,a.k=a.k||a.bK,a.k){var u={},c=function(n,t){e.cI&&(t=t.toLowerCase()),t.split(" ").forEach(function(e){var t=e.split("|");u[t[0]]=[n,t[1]?Number(t[1]):1]})};"string"==typeof a.k?c("keyword",a.k):E(a.k).forEach(function(e){c(e,a.k[e])}),a.k=u}a.lR=t(a.l||/\w+/,!0),i&&(a.bK&&(a.b="\\b("+a.bK.split(" ").join("|")+")\\b"),a.b||(a.b=/\B|\b/),a.bR=t(a.b),a.e||a.eW||(a.e=/\B|\b/),a.e&&(a.eR=t(a.e)),a.tE=n(a.e)||"",a.eW&&i.tE&&(a.tE+=(a.e?"|":"")+i.tE)),a.i&&(a.iR=t(a.i)),null==a.r&&(a.r=1),a.c||(a.c=[]);var s=[];a.c.forEach(function(e){e.v?e.v.forEach(function(n){s.push(o(e,n))}):s.push("self"===e?a:e)}),a.c=s,a.c.forEach(function(e){r(e,a)}),a.starts&&r(a.starts,i);var l=a.c.map(function(e){return e.bK?"\\.?("+e.b+")\\.?":e.b}).concat([a.tE,a.i]).map(n).filter(Boolean);a.t=l.length?t(l.join("|"),!0):{exec:function(){return null}}}}r(e)}function l(e,t,a,i){function o(e,n){var t,a;for(t=0,a=n.c.length;a>t;t++)if(r(n.c[t].bR,e))return n.c[t]}function u(e,n){if(r(e.eR,n)){for(;e.endsParent&&e.parent;)e=e.parent;return e}return e.eW?u(e.parent,n):void 0}function c(e,n){return!a&&r(n.iR,e)}function g(e,n){var t=N.cI?n[0].toLowerCase():n[0];return e.k.hasOwnProperty(t)&&e.k[t]}function h(e,n,t,r){var a=r?"":y.classPrefix,i='',i+n+o}function p(){var e,t,r,a;if(!E.k)return n(B);for(a="",t=0,E.lR.lastIndex=0,r=E.lR.exec(B);r;)a+=n(B.substr(t,r.index-t)),e=g(E,r),e?(M+=e[1],a+=h(e[0],n(r[0]))):a+=n(r[0]),t=E.lR.lastIndex,r=E.lR.exec(B);return a+n(B.substr(t))}function d(){var e="string"==typeof E.sL;if(e&&!x[E.sL])return n(B);var t=e?l(E.sL,B,!0,L[E.sL]):f(B,E.sL.length?E.sL:void 0);return E.r>0&&(M+=t.r),e&&(L[E.sL]=t.top),h(t.language,t.value,!1,!0)}function b(){k+=null!=E.sL?d():p(),B=""}function v(e){k+=e.cN?h(e.cN,"",!0):"",E=Object.create(e,{parent:{value:E}})}function m(e,n){if(B+=e,null==n)return b(),0;var t=o(n,E);if(t)return t.skip?B+=n:(t.eB&&(B+=n),b(),t.rB||t.eB||(B=n)),v(t,n),t.rB?0:n.length;var r=u(E,n);if(r){var a=E;a.skip?B+=n:(a.rE||a.eE||(B+=n),b(),a.eE&&(B=n));do E.cN&&(k+=C),E.skip||(M+=E.r),E=E.parent;while(E!==r.parent);return r.starts&&v(r.starts,""),a.rE?0:n.length}if(c(n,E))throw new Error('Illegal lexeme "'+n+'" for mode "'+(E.cN||"")+'"');return B+=n,n.length||1}var N=R(e);if(!N)throw new Error('Unknown language: "'+e+'"');s(N);var w,E=i||N,L={},k="";for(w=E;w!==N;w=w.parent)w.cN&&(k=h(w.cN,"",!0)+k);var B="",M=0;try{for(var I,j,O=0;;){if(E.t.lastIndex=O,I=E.t.exec(t),!I)break;j=m(t.substr(O,I.index-O),I[0]),O=I.index+j}for(m(t.substr(O)),w=E;w.parent;w=w.parent)w.cN&&(k+=C);return{r:M,value:k,language:e,top:E}}catch(T){if(T.message&&-1!==T.message.indexOf("Illegal"))return{r:0,value:n(t)};throw T}}function f(e,t){t=t||y.languages||E(x);var r={r:0,value:n(e)},a=r;return t.filter(R).forEach(function(n){var t=l(n,e,!1);t.language=n,t.r>a.r&&(a=t),t.r>r.r&&(a=r,r=t)}),a.language&&(r.second_best=a),r}function g(e){return y.tabReplace||y.useBR?e.replace(M,function(e,n){return y.useBR&&"\n"===e?"
":y.tabReplace?n.replace(/\t/g,y.tabReplace):void 0}):e}function h(e,n,t){var r=n?L[n]:t,a=[e.trim()];return e.match(/\bhljs\b/)||a.push("hljs"),-1===e.indexOf(r)&&a.push(r),a.join(" ").trim()}function p(e){var n,t,r,o,s,p=i(e);a(p)||(y.useBR?(n=document.createElementNS("http://www.w3.org/1999/xhtml","div"),n.innerHTML=e.innerHTML.replace(/\n/g,"").replace(//g,"\n")):n=e,s=n.textContent,r=p?l(p,s,!0):f(s),t=u(n),t.length&&(o=document.createElementNS("http://www.w3.org/1999/xhtml","div"),o.innerHTML=r.value,r.value=c(t,u(o),s)),r.value=g(r.value),e.innerHTML=r.value,e.className=h(e.className,p,r.language),e.result={language:r.language,re:r.r},r.second_best&&(e.second_best={language:r.second_best.language,re:r.second_best.r}))}function d(e){y=o(y,e)}function b(){if(!b.called){b.called=!0;var e=document.querySelectorAll("pre code");w.forEach.call(e,p)}}function v(){addEventListener("DOMContentLoaded",b,!1),addEventListener("load",b,!1)}function m(n,t){var r=x[n]=t(e);r.aliases&&r.aliases.forEach(function(e){L[e]=n})}function N(){return E(x)}function R(e){return e=(e||"").toLowerCase(),x[e]||x[L[e]]}var w=[],E=Object.keys,x={},L={},k=/^(no-?highlight|plain|text)$/i,B=/\blang(?:uage)?-([\w-]+)\b/i,M=/((^(<[^>]+>|\t|)+|(?:\n)))/gm,C="",y={classPrefix:"hljs-",tabReplace:null,useBR:!1,languages:void 0},I={"&":"&","<":"<",">":">"};return e.highlight=l,e.highlightAuto=f,e.fixMarkup=g,e.highlightBlock=p,e.configure=d,e.initHighlighting=b,e.initHighlightingOnLoad=v,e.registerLanguage=m,e.listLanguages=N,e.getLanguage=R,e.inherit=o,e.IR="[a-zA-Z]\\w*",e.UIR="[a-zA-Z_]\\w*",e.NR="\\b\\d+(\\.\\d+)?",e.CNR="(-?)(\\b0[xX][a-fA-F0-9]+|(\\b\\d+(\\.\\d*)?|\\.\\d+)([eE][-+]?\\d+)?)",e.BNR="\\b(0b[01]+)",e.RSR="!|!=|!==|%|%=|&|&&|&=|\\*|\\*=|\\+|\\+=|,|-|-=|/=|/|:|;|<<|<<=|<=|<|===|==|=|>>>=|>>=|>=|>>>|>>|>|\\?|\\[|\\{|\\(|\\^|\\^=|\\||\\|=|\\|\\||~",e.BE={b:"\\\\[\\s\\S]",r:0},e.ASM={cN:"string",b:"'",e:"'",i:"\\n",c:[e.BE]},e.QSM={cN:"string",b:'"',e:'"',i:"\\n",c:[e.BE]},e.PWM={b:/\b(a|an|the|are|I'm|isn't|don't|doesn't|won't|but|just|should|pretty|simply|enough|gonna|going|wtf|so|such|will|you|your|like)\b/},e.C=function(n,t,r){var a=e.inherit({cN:"comment",b:n,e:t,c:[]},r||{});return a.c.push(e.PWM),a.c.push({cN:"doctag",b:"(?:TODO|FIXME|NOTE|BUG|XXX):",r:0}),a},e.CLCM=e.C("//","$"),e.CBCM=e.C("/\\*","\\*/"),e.HCM=e.C("#","$"),e.NM={cN:"number",b:e.NR,r:0},e.CNM={cN:"number",b:e.CNR,r:0},e.BNM={cN:"number",b:e.BNR,r:0},e.CSSNM={cN:"number",b:e.NR+"(%|em|ex|ch|rem|vw|vh|vmin|vmax|cm|mm|in|pt|pc|px|deg|grad|rad|turn|s|ms|Hz|kHz|dpi|dpcm|dppx)?",r:0},e.RM={cN:"regexp",b:/\//,e:/\/[gimuy]*/,i:/\n/,c:[e.BE,{b:/\[/,e:/\]/,r:0,c:[e.BE]}]},e.TM={cN:"title",b:e.IR,r:0},e.UTM={cN:"title",b:e.UIR,r:0},e.METHOD_GUARD={b:"\\.\\s*"+e.UIR,r:0},e});hljs.registerLanguage("bash",function(e){var t={cN:"variable",v:[{b:/\$[\w\d#@][\w\d_]*/},{b:/\$\{(.*?)}/}]},s={cN:"string",b:/"/,e:/"/,c:[e.BE,t,{cN:"variable",b:/\$$/,e:/$/,c:[e.BE]}]},a={cN:"string",b:/'/,e:/'/};return{aliases:["sh","zsh"],l:/-?[a-z\._]+/,k:{keyword:"if then else elif fi for while in do done case esac function",literal:"true false",built_in:"break cd continue eval exec exit export getopts hash pwd readonly return shift test times trap umask unset alias bind builtin caller command declare echo enable help let local logout mapfile printf read readarray source type typeset ulimit unalias set shopt autoload bg bindkey bye cap chdir clone comparguments compcall compctl compdescribe compfiles compgroups compquote comptags comptry compvalues dirs disable disown echotc echoti emulate fc fg float functions getcap getln history integer jobs kill limit log noglob popd print pushd pushln rehash sched setcap setopt stat suspend ttyctl unfunction unhash unlimit unsetopt vared wait whence where which zcompile zformat zftp zle zmodload zparseopts zprof zpty zregexparse zsocket zstyle ztcp",_:"-ne -eq -lt -gt -f -d -e -s -l -a"},c:[{cN:"meta",b:/^#![^\n]+sh\s*$/,r:10},{cN:"function",b:/\w[\w\d_]*\s*$\s*$\s*\{/,rB:!0,c:[e.inherit(e.TM,{b:/\w[\w\d_]*/})],r:0},e.HCM,s,a,t]}});hljs.registerLanguage("ocaml",function(e){return{aliases:["ml"],k:{keyword:"and as assert asr begin class constraint do done downto else end exception external for fun function functor if in include inherit! inherit initializer land lazy let lor lsl lsr lxor match method!|10 method mod module mutable new object of open! open or private rec sig struct then to try type val! val virtual when while with parser value",built_in:"array bool bytes char exn|5 float int int32 int64 list lazy_t|5 nativeint|5 string unit in_channel out_channel ref",literal:"true false"},i:/\/\/|>>/,l:"[a-z_]\\w*!?",c:[{cN:"literal",b:"\\[(\\|\\|)?\\]|\$\$",r:0},e.C("\$\\*","\\*\$",{c:["self"]}),{cN:"symbol",b:"'[A-Za-z_](?!')[\\w']*"},{cN:"type",b:"`[A-Z][\\w']*"},{cN:"type",b:"\\b[A-Z][\\w']*",r:0},{b:"[a-z_]\\w*'[\\w']*",r:0},e.inherit(e.ASM,{cN:"string",r:0}),e.inherit(e.QSM,{i:null}),{cN:"number",b:"\\b(0[xX][a-fA-F0-9_]+[Lln]?|0[oO][0-7_]+[Lln]?|0[bB][01_]+[Lln]?|[0-9][0-9_]*([Lln]|(\\.[0-9_]*)?([eE][-+]?[0-9_]+)?)?)",r:0},{b:/[-=]>/}]}}); \ No newline at end of file diff --git a/tags/UI b/tags/UI new file mode 100644 index 0000000..bc415db --- /dev/null +++ b/tags/UI @@ -0,0 +1,3 @@ + +full stack engineer

Jackline, a secure terminal-based XMPP client

implement it once to know you can do it. implement it a second time and you get readable code. implementing it a third time from scratch may lead to useful libraries.

\ No newline at end of file diff --git a/tags/background b/tags/background new file mode 100644 index 0000000..6dd0491 --- /dev/null +++ b/tags/background @@ -0,0 +1,6 @@ + +full stack engineer

Counting Bytes

looking into dependencies and their sizes

Configuration DSL step-by-step

how to actually configure the system

Why OCaml

a gentle introduction into OCaml

About

introduction (myself, this site)

\ No newline at end of file diff --git a/tags/bitcoin b/tags/bitcoin new file mode 100644 index 0000000..2a0a0d2 --- /dev/null +++ b/tags/bitcoin @@ -0,0 +1,3 @@ + +full stack engineer

The Bitcoin Piñata - no candy for you

More than three years ago we launched our Bitcoin Piñata as a transparent security bait. It is still up and running!

\ No newline at end of file diff --git a/tags/deployment b/tags/deployment new file mode 100644 index 0000000..3d44f25 --- /dev/null +++ b/tags/deployment @@ -0,0 +1,8 @@ + +full stack engineer

Mirroring the opam repository and all tarballs

Re-developing an opam cache from scratch, as a MirageOS unikernel

All your metrics belong to influx

How to monitor your MirageOS unikernel with albatross and monitoring-experiments

Deploying binary MirageOS unikernels

Finally, we provide reproducible binary MirageOS unikernels together with packages to reproduce them and setup your own builder

Deploying authoritative OCaml-DNS servers as MirageOS unikernels

A tutorial how to deploy authoritative name servers, let's encrypt, and updating entries from unix services.

Summer 2019

Bringing MirageOS into production, take IV monitoring, CalDAV, DNS

Albatross - provisioning, deploying, managing, and monitoring virtual machines

all we need is X.509

\ No newline at end of file diff --git a/tags/future b/tags/future new file mode 100644 index 0000000..768b449 --- /dev/null +++ b/tags/future @@ -0,0 +1,3 @@ + +full stack engineer

Minimising the virtual machine monitor

MirageOS solo5 multiboot native on bhyve

\ No newline at end of file diff --git a/tags/http b/tags/http new file mode 100644 index 0000000..0472ed9 --- /dev/null +++ b/tags/http @@ -0,0 +1,3 @@ + +full stack engineer

Fitting the things together

building a simple website

\ No newline at end of file diff --git a/tags/logging b/tags/logging new file mode 100644 index 0000000..4ae91a1 --- /dev/null +++ b/tags/logging @@ -0,0 +1,3 @@ + +full stack engineer

Exfiltrating log data using syslog

sometimes preservation of data is useful

\ No newline at end of file diff --git a/tags/mirageos b/tags/mirageos new file mode 100644 index 0000000..2a501b9 --- /dev/null +++ b/tags/mirageos @@ -0,0 +1,23 @@ + +full stack engineer

Mirroring the opam repository and all tarballs

Re-developing an opam cache from scratch, as a MirageOS unikernel

All your metrics belong to influx

How to monitor your MirageOS unikernel with albatross and monitoring-experiments

Deploying binary MirageOS unikernels

Written by hannes 2021-04-23

Finally, we provide reproducible binary MirageOS unikernels together with packages to reproduce them and setup your own builder

Cryptography updates in OCaml and MirageOS

Elliptic curves (ECDSA/ECDH) are supported in a maintainable and secure way.

The road ahead for MirageOS in 2021

Written by hannes 2021-01-25

Home office, MirageOS unikernels, 2020 recap, 2021 tbd

Traceroute

A MirageOS unikernel which traces the path between itself and a remote host.

Deploying authoritative OCaml-DNS servers as MirageOS unikernels

A tutorial how to deploy authoritative name servers, let's encrypt, and updating entries from unix services.

Reproducible MirageOS unikernel builds

Written by hannes 2019-08-15

MirageOS unikernels are reproducible :)

X509 0.7

Five years since ocaml-x509 initial release, it has been reworked and used more widely

Summer 2019

Bringing MirageOS into production, take IV monitoring, CalDAV, DNS

The Bitcoin Piñata - no candy for you

More than three years ago we launched our Bitcoin Piñata as a transparent security bait. It is still up and running!

My 2018 contains robur and starts with re-engineering DNS

Albatross - provisioning, deploying, managing, and monitoring virtual machines

all we need is X.509

Exfiltrating log data using syslog

sometimes preservation of data is useful

Re-engineering ARP

If you want it as you like, you've to do it yourself

Minimising the virtual machine monitor

MirageOS solo5 multiboot native on bhyve

Counting Bytes

looking into dependencies and their sizes

Configuration DSL step-by-step

Written by hannes 2016-05-03

how to actually configure the system

Catch the bug, walking through the stack

10BTC could've been yours

Fitting the things together

building a simple website

Operating systems

Operating systems and MirageOS

\ No newline at end of file diff --git a/tags/monitoring b/tags/monitoring new file mode 100644 index 0000000..dae7490 --- /dev/null +++ b/tags/monitoring @@ -0,0 +1,4 @@ + +full stack engineer

All your metrics belong to influx

How to monitor your MirageOS unikernel with albatross and monitoring-experiments

Summer 2019

Bringing MirageOS into production, take IV monitoring, CalDAV, DNS

\ No newline at end of file diff --git a/tags/myself b/tags/myself new file mode 100644 index 0000000..e838f15 --- /dev/null +++ b/tags/myself @@ -0,0 +1,3 @@ + +full stack engineer

About

introduction (myself, this site)

\ No newline at end of file diff --git a/tags/opam b/tags/opam new file mode 100644 index 0000000..947c6e8 --- /dev/null +++ b/tags/opam @@ -0,0 +1,3 @@ + +full stack engineer

Mirroring the opam repository and all tarballs

Re-developing an opam cache from scratch, as a MirageOS unikernel

\ No newline at end of file diff --git a/tags/operating system b/tags/operating system new file mode 100644 index 0000000..1b7a6b0 --- /dev/null +++ b/tags/operating system @@ -0,0 +1,3 @@ + +full stack engineer

Operating systems

Operating systems and MirageOS

\ No newline at end of file diff --git a/tags/overview b/tags/overview new file mode 100644 index 0000000..3f49c41 --- /dev/null +++ b/tags/overview @@ -0,0 +1,6 @@ + +full stack engineer

Conex, establish trust in community repositories

Conex is a library to verify and attest package release integrity and authenticity through the use of cryptographic signatures.

Why OCaml

a gentle introduction into OCaml

Operating systems

Operating systems and MirageOS

About

introduction (myself, this site)

\ No newline at end of file diff --git a/tags/package signing b/tags/package signing new file mode 100644 index 0000000..2dc2230 --- /dev/null +++ b/tags/package signing @@ -0,0 +1,6 @@ + +full stack engineer

Reproducible MirageOS unikernel builds

MirageOS unikernels are reproducible :)

Summer 2019

Bringing MirageOS into production, take IV monitoring, CalDAV, DNS

Conex, establish trust in community repositories

Conex is a library to verify and attest package release integrity and authenticity through the use of cryptographic signatures.

Who maintains package X?

We describe why manual gathering of metadata is out of date, and version control systems are awesome.

\ No newline at end of file diff --git a/tags/protocol b/tags/protocol new file mode 100644 index 0000000..23984a8 --- /dev/null +++ b/tags/protocol @@ -0,0 +1,8 @@ + +full stack engineer

Traceroute

A MirageOS unikernel which traces the path between itself and a remote host.

Deploying authoritative OCaml-DNS servers as MirageOS unikernels

A tutorial how to deploy authoritative name servers, let's encrypt, and updating entries from unix services.

My 2018 contains robur and starts with re-engineering DNS

Exfiltrating log data using syslog

sometimes preservation of data is useful

Re-engineering ARP

If you want it as you like, you've to do it yourself

Fitting the things together

building a simple website

\ No newline at end of file diff --git a/tags/provisioning b/tags/provisioning new file mode 100644 index 0000000..5c492c0 --- /dev/null +++ b/tags/provisioning @@ -0,0 +1,3 @@ + +full stack engineer

Albatross - provisioning, deploying, managing, and monitoring virtual machines