Thomas Gazagnaire gets OCaml into orbit with Parsimoni's Borealis

Why it matters

Hosted-payload satellites are multi-tenant, but kernel isolation fails often and patching in orbit is slow. Parsimoni's OCaml-based CCSDS stack moves the trust boundary into cryptography and protocol design, pointing to a safer default for space software.

Thomas Gazagnaire said Parsimoni's pure-OCaml CCSDS stack booted in low Earth orbit on April 23, writing in a blog post that the project, codenamed Borealis, is running inside DPhi Space's ClusterGate-2 payload module. The team says it is the first time a pure-OCaml CCSDS stack has run in space, complete with end-to-end-encrypted command and control and post-quantum key rotation implemented in OCaml.

Gazagnaire frames the work as a security bet: satellites increasingly host multiple tenants, and untrusted code in orbit is a real risk. In a prior write-up on hosted-payload satellite software, he argued container isolation is not enough when kernel-level CVEs regularly break isolation. In the new post, he points to a string of recent Linux vulnerabilities like Dirty Frag, Fragnesia, Copy Fail, Dirty Pipe, and CVE-2024-1086 as examples of why patching in orbit is hard and why cryptographic isolation has to be the durable guarantee.

From a winter hack to first boot

Gazagnaire writes that he and collaborator Virgile Robles hacked on Borealis over the Christmas break, and the first orbital boot landed on DPhi Space's mission-ops dashboard on April 23 with a healthy telemetry report. The software comes as a daemon that speaks a familiar request-response shape (telemetry queries, commands, responses, and rekey requests) on both ground and satellite. What is unusual is the wire underneath: a pure-OCaml implementation of the CCSDS protocol family, from radio framing through Bundle Protocol v7 with BPSec on top, with binary formats described using the team's ocaml-wire codecs. Gazagnaire also published a deeper note on the CCSDS stack design.

On ClusterGate-2, Borealis does not touch external networks. Instead, it treats DPhi's uplink/downlink filesystem as a delay-tolerant network: a file written to an uplink directory is forwarded on the next pass, and downlink works the same way. Every command, response, telemetry sample, and image chunk is serialized into a BPv7 bundle and written to disk. BPSec wraps each bundle with authenticated encryption and sequence numbers to reject replays. Pre-shared keys sit outside the routing path and are rotated with OTAR (Over-The-Air Rekeying), delivering end-to-end confidentiality and authenticity even when the payload shares a bus with other tenants. As Gazagnaire puts it, the satellite operator sees only opaque bundle bytes.

Why OCaml, and why now

The choice of OCaml is not incidental. Gazagnaire argues a safe, high-performance language is a better fit for untrusted code in space than a large, patch-hungry kernel boundary. He nods to KC Sivaramakrishnan's ICFP 2022 keynote on the decade-long effort to ship OCaml 5 with multicore support, quipping that Parsimoni took KC's slide about taking OCaml 5.0 to the moon literally. In Borealis, that bet shows up as a full control stack implemented in a memory-safe language with strong typing and modern concurrency.

The bigger picture

Parsimoni is not trying to rebuild mission ops from scratch so much as slot a hardened, end-to-end envelope into existing workflows. On DPhi's hosted payload, there is no kernel patch sprint in the loop and no exposed network surface for tenant code. Instead, there is a minimal, verifiable wire format and cryptographic policy that travels with the payload. If that pattern generalizes, future hosted-payload tenants may be able to ship faster without betting their missions on the next CVE cycle.