To understand where the gaps are, it helps to separate the two halves of the stack. Bus software (attitude control, power, thermal) runs on qualified RTOSes and is the satellite manufacturer's domain. Payload software (imaging, communications, data processing) increasingly runs on COTS (commercial off-the-shelf) processors with memory management units (MMUs) perfectly capable of enforcing memory isolation. For LEO missions on COTS hardware, the hardware is there. The software running on it does not use it.

I think three things are missing for anyone wanting to run hosted payloads or patch software in orbit safely:

1. Hardware-enforced memory isolation between payloads and flight software, either through a hypervisor (like Xen or KVM) or a separation kernel (seL4 has a formal proof of functional correctness on specific hardware configurations). Both use the MMU to ensure a compromised payload cannot reach the bus.

2. A standard OTA deployment format so "install this application" means the same thing across different satellites: cryptographically signed, designed for 10-minute LEO pass windows and partial transfers.

3. A metered runtime that enforces resource quotas (CPU, memory, storage, bus bandwidth) so one payload cannot starve the others. Resource requirements should be declarative, embedded in the deployment image, and verified before installation.

The tools to address much of this exist in the terrestrial world: memory-safe languages (roughly 70% of CVEs in large C/C++ codebases are memory-safety issues, a figure consistent across Microsoft, Google, and Android since 2019), verified cryptography, minimal single-purpose OS images. These are not theoretical: Google cut Android memory-safety vulnerabilities by 76% in six years by writing new code in memory-safe languages, and AWS runs millions of serverless workloads on Firecracker, a 50,000-line Rust VMM that boots in under 125 ms. None of these have made it into flight software yet, even as the number of spacecraft in orbit (and the attack surface) has grown sharply. Space Odyssey examined three satellites and found vulnerabilities in all of them, and those are only the ones someone bothered to look for.

Mass launched to orbit (blue) versus publicly disclosed satellite software vulnerabilities (red bars, from CVE/NVD and conference disclosures; data and sources). The gap between the curves is the problem: launch volume has exploded, security scrutiny has barely started.

The evidence is mounting. None of the Space Odyssey satellites had ASLR, stack canaries, or DEP; one had no authentication on its telecommand interface. The Viasat/KA-SAT attack in February 2022 disrupted Ukrainian communications and 5,800 German wind turbines, making the threat operational (Boschetti, Gordon and Falco, ASCEND 2022). At Black Hat 2025, a vulnerability assessment of NASA's core Flight System (cFS) found remote code execution, path traversal, and denial-of-service, all from textbook C memory bugs. NASA's own CryptoLib, the reference implementation of CCSDS encryption, has had recurring buffer overflows in its parsing code (CVE-2025-29909, CVSS 9.8). A memory-safe language eliminates these classes of bug by construction.

The pattern across all of these is consistent: space software engineering has a safety-versus-security bias (Pavur and Martinovic, J. Cybersecur. 2022; Falco, JAIS 2019). Systems are designed for availability and determinism (watchdogs, radiation tolerance, FDIR). Integrity and confidentiality are secondary. This is not irrational: a satellite that loses attitude control is a more immediate problem than one that leaks telemetry. But it leaves software stacks undefended against adversarial threats. Jero et al. (NDSS SpaceSec 2024) proposed a defence-in-depth taxonomy -- secure boot, memory protection, authenticated updates, compartmentalisation -- that overlaps substantially with the three gaps above.

So why does the current stack not provide the three things above? Most small-sat payload software runs on VxWorks, RTEMS, embedded Linux (Yocto, Buildroot), or bare metal. The RTOS path typically runs everything in a single address space: the hardware has an MMU, but most CubeSat missions do not enable memory protection because it requires rethinking memory management, interrupt handling, and DMA buffer allocation. This is exactly the architecture Space Odyssey found vulnerable. Embedded Linux gives you process isolation, but hardening it for multi-tenancy and certifying it for flight remains a substantial undertaking. ESA's OPS-SAT demonstrated deploying new applications before its re-entry in 2024, but it remains the exception.

The isolation and metering techniques are not new. Cloud infrastructure solved analogous problems years ago, and avionics systems (ARINC 653, DO-178C) have their own qualified solutions. The gap is in LEO payload software, where neither stack fits: the cloud stack assumes abundant resources, the avionics stack assumes a single operator and a multi-year qualification budget. I am not going to minimise how much work qualification (under ECSS-Q-ST-80C or equivalent) requires. Calabrese, Kavallieratos and Falco (SCITECH 2024) emulated a cyberattack from a hosted payload on OPS-SAT that compromised the bus, demonstrating why isolation matters. But a real multi-tenant satellite also needs FDIR (Fault Detection, Isolation, and Recovery) integration, thermal management, power budgeting, and link budget allocation. I am focusing on the software infrastructure, but I do not want to pretend the problem ends there.

The regulatory pressure is new. The EU Cyber Resilience Act is pushing toward stronger isolation and update mechanisms. ENISA is calling out the space sector. The White House called for memory-safe languages in critical infrastructure in 2024, a recommendation that applies to flight software as much as to anything on the ground. OCaml, the language Parsimoni and Tarides use, is memory-safe in its default fragment. And the hardware is finally there: radiation-tolerant processors with enough compute for on-board processing are commercially available at CubeSat price points. The missing piece is the software infrastructure.

These are the problems I co-founded Parsimoni to work on. Our payload software platform, SpaceOS, builds on the OCaml ecosystem that Tarides maintains. Our first payload reached orbit on SpaceX Transporter-13 in March 2025. If you are building payload software and running into these constraints, or if you are an operator considering hosted payloads, we would like to hear from you: get in touch.

Five properties fell out of that architecture. None of them are unique to unikernels (a careful Yocto configuration can achieve most of them), but unikernels make them the default. I think they hold up better now than they did in the cloud:

1. Sealed images. The binary is fixed at compile time. No runtime package installation, no configuration files, no shell to log into.
2. Dead code elimination. If the application does not use the filesystem, the filesystem is not in the binary.
3. Single address space. One application, one address space (no internal process isolation, the hypervisor provides isolation between unikernels).
4. Configuration is compilation. Network addresses, TLS certificates, and firewall rules are baked in at build time. No configuration parser at runtime means no configuration parser to exploit.
5. Small trusted computing base. The TCB is the hypervisor plus the application. No general-purpose kernel, no init system, no sshd.

Anil, Balraj and I co-founded Unikernel Systems to bring this to production. Docker acquired us three months later. At Docker, we built Docker Desktop from scratch, adding MirageOS unikernel components to the networking stack via vpnkit (we wrote an ICFP paper about how that works). Millions of developers use it daily. Meanwhile, containers won the cloud and Unikraft took the unikernel deployment model in a POSIX-compatible direction for serverless. The unikernel-as-product did not take over (yet!), but the libraries shipped further than we ever expected.

In 2021, when Tarides joined Cyber@Station F, I pitched unikernels to over thirty internal teams at Thales: cyber, compliance, transport, defence, ... Most were politely interested. The one that clicked was Régis de Ferluc at Thales Alenia Space. His reaction was not "that is interesting" but "that is how we already build embedded systems, but done in a principled way (and where you can safely introduce dynamic behaviour)."

He was right. Satellite flight software ships as fixed binaries, qualified on the ground, no shell access in orbit, no runtime configuration changes. The five properties above are not innovations in space, they are requirements. What satellite software does not have is the type safety, the tooling, and the library ecosystem that OCaml and MirageOS provide.

Régis pushed us to look deeper, introduced us to EU programmes (ORCHIDE via Horizon Europe, CEOS), and SpaceOS was born. Miklos and I co-founded Parsimoni to build it.

The ASPLOS paper asked whether sealed, single-purpose images could improve cloud infrastructure. Twelve years later, I think the more interesting question is whether those same properties matter more in constrained environments (satellites, hardware security modules, embedded controllers) where every kilobyte counts, you cannot ssh in after deployment, and "no unused code" is not an optimisation but a qualification requirement.

F Prime (GitHub) is NASA's open-source framework for building reusable flight software. Before it, most missions started from scratch or copy-pasted code from previous ones. It already flies on Ingenuity (Mars Helicopter), CADRE (autonomous lunar rovers), and Europa Clipper. It is trying to bring standard software engineering practices (modularity, unit testing, reusability, continuous integration) to a domain that has historically resisted them.

The framework has its own modelling language called FPP (F Prime Prime). You describe your system in FPP (components, ports, state machines, topologies) and the toolchain generates thousands of lines of C++ for you (plus a fair amount of CMake glue to wire the build together). That is the point: you write the architecture, not the boilerplate. If you have ever worked with MirageOS, all of this should sound oddly familiar.

For those who do not know, MirageOS (GitHub) is a library operating system where the entire application, from the network stack to the storage layer, is built from OCaml modules wired together by functors. The runtime is minimal (Solo5 provides about ten hypercalls), no general-purpose OS, no libc, just typed interfaces all the way down. Our ASPLOS 2013 paper received the Influential Paper Award in 2025. I think F Prime and MirageOS share a surprising number of ideas. Here is how I see the two relate.

Components are module types. In F Prime, you define a component by declaring its ports, typed interfaces that connect it to the rest of the system. The FPP paper puts it nicely: a port "has a type and a kind; the type is like a function signature." Components have no compile- or link-time dependencies on each other: each component depends only on the types of the ports that it uses.

FPP distinguishes three kinds of components: passive (called synchronously by the caller), queued (has an internal message queue but no thread of its own), and active (has its own thread that drains its queue). This is a concurrency model baked into the component types:

passive component Thermometer {
  sync input port cmdIn: Fw.Cmd
  output port tlmOut: Fw.Tlm
  telemetry Temperature: F32
}

module type THERMOMETER = sig
  type t
  val cmd_in : t -> Cmd.t -> unit
  val tlm_out : t -> Tlm.t
  val temperature : t -> float
end

Both say the same thing: anything that calls itself a thermometer must accept commands, emit telemetry, and report a temperature. The ports are the function signatures. The component type is the module type.

The mapping is suggestive, not exact. FPP ports have directionality (input vs output) and invocation kinds (sync, async, guarded) that a flat OCaml signature does not enforce. In MirageOS we used phantom types on device connectors to recover some of this structure (see Radanne, Gazagnaire et al., 2019) but the parallel is clear enough to be useful.

The concurrency story is interesting too. F Prime's active/passive/queued distinction maps loosely to what OCaml has been working through for years. A passive component is a plain function call. An active component has its own thread that drains a message queue. Compare:

active component Logger {
  async input port logIn: Fw.Log
}

module type LOGGER = sig
  type t
  val log_in : t -> Log.t -> unit Lwt.t
end

In FPP, a component is either passive, queued, or active. In OCaml, you can mix synchronous and asynchronous functions in the same module signature: some values return unit, others return unit Lwt.t. The concurrency model is per-function, not per-component. Queued components sit in between, an event loop without a dedicated thread. OCaml has been moving from monadic concurrency (Lwt.t) to effect handlers in OCaml 5, which delegate scheduling to a library like Eio without colouring every type signature. F Prime bakes the concurrency model into the component kind; OCaml delegates it to the application scheduler.

State machines are GADTs. This one is not specific to MirageOS, it is about OCaml's type system more broadly. FPP has built-in state machine support (states, signals, guards, and transitions). Here is a door controller (from the FPP User's Guide):

state machine Door {
  signal open
  signal close
  guard isLocked

  initial enter Closed

  state Closed {
    on open if isLocked enter Closed
    on open enter Open
  }

  state Open {
    on close enter Closed
  }
}

FPP: a door with two states and a guard.

The generated state machine diagram.

In OCaml, you can encode the same transitions as a GADT. The type parameters track which state you are in and which state a signal takes you to:

type closed
type opened

type _ state =
  | Closed : closed state
  | Open : opened state

type (_, _) signal =
  | Open  : (closed, opened) signal
  | Close : (opened, closed) signal

type guard = Locked | Unlocked

let step : type a b. a state -> (a, b) signal -> guard
    -> (b state, a state) result =
  fun state signal guard ->
    match state, signal, guard with
    | Closed, Open, Locked   -> Error state
    | Closed, Open, Unlocked -> Ok Open
    | Open, Close, _         -> Ok Closed

The type (closed, opened) signal means: this signal is only valid from the closed state, and it produces the opened state. Try to close an already-closed door and the compiler rejects it. The guard is a runtime check (just like in FPP), but the result type makes the self-loop explicit: Error state means the guard blocked and you stayed where you were. FPP's state machine compiler does the same checks at the FPP level; the GADT pushes them into OCaml's own type system.

The wiring is where they diverge. How you describe the way all these components connect into a running system is where the two frameworks take different paths.

In F Prime, you define a topology: a wiring diagram that connects component instances through their ports, the way an engineer connects chips on a board. Sub-topologies let you group and reuse partial wirings (think of them as sub-circuits). The FPP compiler checks that port types match, then the autocoder generates C++ and a fair amount of CMake glue. For the final assembly, users customise init sequences, thread priorities, and buffer sizes through C++ templates and build rules. There are many knobs to turn.

topology Mission {
  instance sensor: Sensors.Thermometer
  instance dispatcher: Svc.CmdDispatcher

  connections command {
    dispatcher.compCmdSend -> sensor.cmdIn
  }
}

module Mission
    (Sensor : THERMOMETER)
    (Dispatcher : CMD_DISPATCHER) = struct
  let dispatch sensor cmd =
    Sensor.cmd_in sensor cmd
  let init sensor =
    Dispatcher.register (dispatch sensor)
end

In MirageOS, a functor is a function from modules to modules: you pass a module satisfying some signature, and you get a new module back. The functor is the sub-topology. People write functor applications by hand all the time in OCaml, and it works fine. But in MirageOS we wanted to automate redeployment across different hypervisors and driver sets (Xen, KVM, Solo5, each with their own network and storage stacks), so we built Functoria, an eDSL that describes the assemblage and generates the build rules and functor applications for each target. That is structurally closer to what F Prime's autocoder does: both take a high-level wiring description and produce glue code for a specific target.

Both check that the wiring is type-correct, but in different places: FPP in its own compiler, OCaml in the host language's type system. FPP gives you a graph-oriented model that maps naturally to how electronic engineers think. Functoria gives you composability (functors are first-class language constructs), but the resulting code can get... involved. (Who said Irmin in the back? :p)

The unit of compute seems settled: small typed components, explicit async I/O, function types as interfaces. The global wiring is not. I have seen it spawn build system rules (Makefile spaghetti), domain-specific languages (FPP, Functoria), and language-specific support (functors). Parnas (1972) told us to hide information behind interfaces. Nobody told us how to wire a thousand of them together ;-)

The last couple of weeks have been pretty intense as I've been moving to LA with my family. I am spending six months here, working on Parsimoni and getting closer to the US space industry.

Last week I visited NASA's Jet Propulsion Laboratory (JPL) and saw Voyager 2's control room -- still running after 48 years. Optimism, Perseverance's ground twin, was rolling over Pasadena sand in a test enclosure next door. I also attended the F Prime workshop and completed two workshops on flight software engineering. F Prime is NASA's open-source flight software framework. Over 100 people attended -- university and student teams, internal JPL product teams, and large projects like HPSC. Only a small bunch of us were not from the US.

The recurring theme in every conversation: flying a helicopter on Mars is now routine, but deploying shared payload software to a satellite is still real science fiction (no pressure!).

On the Tarides side, the team continues to maintain and develop the OCaml platform -- opam, Dune, Merlin, odoc -- while I am on a different timezone. Lots of things are happening (see the Tarides blog) and many more are planned for 2026. In a world where people write apps by chatting with AI bots, core language tools are even more important to make sure we keep trust in our software systems (more on this later in this blog, hopefully).

I intend to write here more regularly this year -- about SpaceOS, the OCaml platform, and what happens when you try to put unikernels in orbit. Stay tuned.