Paper Summary: Choosing a Runtime for Secure Rust Flight Software
This post summarizes my 2025 IEEE SMC-IT paper "Alcyone: A Blueprint for Secure Rust Flight Software" co-authored with Gregory Falco.
When I wrote about the attack surface of cFS and RTEMS, the natural follow-up question was: what would you build instead? Alcyone is our answer, or at least the start of one. It's a blueprint for a cyber-resilient flight software architecture, designed from scratch in Rust, grounded in the secure-by-component methodology from the IEEE P3349 Working Group. The paper lays out a subsystem decomposition, derives cyber requirements from threat models, and evaluates seven Rust-compatible runtime platforms for embedded execution. That runtime evaluation turned out to be the most practically useful part of the work.
The Architecture in Brief
Alcyone decomposes flight software into five secure blocks, each with bounded interfaces and explicit enforcement surfaces for security requirements:
- Real-Time Kernel and Hardware Abstraction -- task scheduling, resource coordination, secure boot, MPU-based memory isolation. This is the root of trust.
- Command and Data Handling (C&DH) -- command reception, validation, authenticated dispatch, telemetry generation, data logging, and health monitoring. Each function operates within a privilege-constrained domain.
- Fault Detection, Isolation, and Recovery (FDIR) -- continuous monitoring of telemetry trends and task heartbeats, rule-based fault attribution, and recovery actions ranging from reconfiguration to safe mode transitions.
- Interprocess Communication and Bus Management -- message routing with queue-based isolation, cryptographic integrity on message payloads, access control on routing, and audit trails. This subsystem enforces a zero-trust communication model at runtime.
- Mission Applications -- payload management and data collection, operating in restricted domains with verified interface access to the rest of the system.
Each subsystem is implemented as a standalone Rust crate. Traits define cross-cutting contracts like command handlers, telemetry producers, and fault reporters, and the compiler enforces interface adherence at build time. Shared mutable state is eliminated. Communication happens through explicit message-passing. The development practices follow Google's Safe Coding Initiative and the NIST Secure Software Development Framework (SSDF).
This is a design paper. Alcyone is a blueprint and roadmap for a notional LEO science mission, not a completed implementation. A software-in-the-loop prototype is under development.
Picking a Runtime: The Practical Question
The part of this paper I expect people to find most useful is the evaluation of Rust runtime platforms. If you're building embedded Rust for a real-time system today, your choice of runtime determines what isolation guarantees you get, what scheduling model you're locked into, and what hardware you can target. We evaluated seven options:
RTIC is a real-time concurrency framework for ARM Cortex-M. It gives you static scheduling and memory safety, but limited dynamic tasking and limited asynchronous support. It's mature and well-understood, which counts for a lot in this domain.
Tock OS provides fine-grained isolation enforced at the kernel level. Strong safety guarantees, but it imposes real constraints on system layout and application structure that may not fit every mission profile.
Embassy is an async embedded runtime with a cooperative task model. It's flexible, supports low-power applications, and integrates well with modern hardware abstraction layers. If you need async in embedded Rust, this is the leading option.
Ariel-OS builds on Embassy and adds policy enforcement and separation of concerns. It's newer and explicitly targets secure embedded systems.
Drone OS is a cooperative multitasking runtime focused on deeply embedded systems. It emphasizes zero-cost concurrency and interrupt safety.
Hubris is the most architecturally interesting option for security work. Oxide Computer developed it as a microkernel with capability-based access control and strict interface boundaries, implemented entirely in Rust. Its design philosophy aligns naturally with secure-by-component decomposition.
seL4 is the outlier -- not Rust-native, but a formally verified microkernel with strong isolation guarantees backed by mathematical proof. For hybrid deployments or missions that need the highest assurance, it remains a serious candidate.
The final platform selection depends on the mission: what hardware you're targeting, what scheduling model you need, and how much isolation you require. There's no single right answer, but having a structured comparison in one place was something I wished existed when I started this work.
Why Rust, Specifically
The paper identifies nine properties of Rust that matter for flight software: memory safety, type safety, concurrency safety, zero-cost abstractions, trait-based interface enforcement, formal verification compatibility, immutable data by default, embedded suitability, and high assurance potential. I won't rehearse all nine -- the first three are well-known. The one worth highlighting is trait-based interface enforcement, because it does something C coding standards cannot.
In a secure-by-component architecture, every subsystem has defined privilege boundaries and interface contracts. In C, you enforce these through discipline, code review, and static analysis tools. In Rust, you encode them as traits, and the compiler rejects code that violates them. The enforcement is structural, not procedural. It doesn't depend on every developer remembering the rules. That's a meaningful difference when you're building systems that operate for years without human intervention.
The limitations are real. Toolchain qualification under DO-178C isn't there yet, though Ferrocene and GNAT Pro for Rust are making progress. The formal verification ecosystem is immature compared to Ada/SPARK. Some embedded targets for space-grade hardware remain unsupported. These are practical obstacles, not hypothetical ones.