Rust: Who, What and Why for ESA SW PA Workshop

Do you need help with coding?

We are attending the European Space Agency's bi-ennial Software Product Assurance Conference in September, at the European Space Research and Technology Centre in Noordwijk, The Netherlands. At the event, we have been invited to present a 4-hour workshop on Developing Embedded Software in Rust, as well as to present a poster on Rust - the Who, the What, and the Why. This blog post acts as a background to our poster and provides additional references for the content.

Introduction

We commonly hear the question "Is Rust being used in production?", which given it very much is being used in production, speaks to a lack of collected documentation and evidence of this. We worked with our friend James Munns at OneVariable on his blog post Embedded Rust in Production 2025 [1], but here we wanted to add some additional details and updates, and provide a particular focus on the kind of activities that ESA undertakes.

Cloud Systems

Rust's combination of Safety, Performance and Productivity arguably found its earliest adopters amongst the hyper-scalers. These are the cloud companies operating at such scales that chipping a few percent off the operating costs would more than pay back a substantial up-front investment in technology.

Google [2], Amazon Web Services [3], Meta [4], Cloudflare [5], Fastly [6] and Dropbox [7] have all talked about their Rust adoption and the success they have seen. In fact, most people asking is anyone using Rust in production? are likely to be using a production web service written in Rust to do so. The scale of the adoption combined with the normal flows of engineers between companies mean that the experience earned here is now flowing into other companies and other areas - similar to how the original Rust project at Mozilla (Servo) led to engineers moving to each of the hyper-scalers and kick-starting this whole process. We are also grateful to engineers at these companies finding the time (and permission!) to blog about their experiences using Rust. In these blogs we commonly hear about the combination of Safety, Performance and Productivity - that is, they get more secure software, that runs faster, completed in less time.

The companies in this space have also been active in providing the tools they develop as open-source for others to study and build-upon. Examples include firecracker (the AWS Hypervisor) [8], zerocopy (a Google library for buffer manipulation) [9] and buck2 (a build system from Meta) [10].

Personal Computers

Rust isn't just found in the cloud. Increasingly Rust is finding its way into the root-of-trust of personal computing devices - the chip at the very core of the system that ensures that the rest of the system is as it should be and hasn't been tampered with by malware. Microsoft Surface devices now use the Microsoft Pluton Security Processor [11], which is programmed in Embedded Rust [12] and uses the Tock Operating System [13]. Similarly, Google Chromebooks have Titan [14], a security processor which also runs Tock OS [15]. We also see movement from Arm, looking to transition their reference Trusted Firmware-A system software from C to Rust (which is called Rusted Firmware-A, naturally), noting that "eventually, Rusted Firmware-A will become the default for new development" [16].

It's not just the low-level security processors that benefit from Rust. Microsoft are beginning to re-write Windows kernel components in Rust, starting with the GDI Region sub-system [17]. Any files in your C:\Windows folder that end in _rs.sys will have been written in Rust. Google too are using Rust as part of Android, and reporting great success in improving the quality of Android as a result. Google note that "the percentage of memory safety vulnerabilities in Android dropped from 76% to 24% over 6 years as development shifted to memory safe languages." [18] Even the Linux kernel is experimenting with allowing developers to write kernel modules in Rust (making it the third supporteded language, after Assembly Language and C). Developers have said that being able to use Rust for kernel modules has allowed drivers to be developed that would otherwise have been impossibly complex to debug.

Connected Devices

Connected Devices usually have a difficult combination of very limited resources (leading to the use of bare-metal systems programming in a language like C), Internet connectivity (meaning they have to process untrusted input), and access to personal data (like the key for the user's home Wi-Fi, or details about presence and location). Rust is often a good option to replace C, offering not only Safety, Performance and Productivity, but also cross-compatibility with libraries across Windows, macOS, Linux and bare-metal systems.

Samsung's SmartThings platform is used to provide connectivity to many Samsung products. They adopted Rust in their back-end in 2017 [19], and now various SmartThings Hub firmware components are also written in Rust (and shared with the back-end). In a 2021 blog post, Samsung note that "We decided to use a Rust based solution because it is memory efficient, reduced code duplication across surfaces, and easily integrated with our existing experience and Release Engineering infrastructure." [20]

Sonos also use Rust for some firmware, including their Sonos Voice Control platform. As part of this, they have released a number of open-source tools [21], including ffi-convert-rs, which they use to interface with native software on embedded devices.

Safety-Critical Applications

Several companies are working towards releasing the first safety-critical certified products, using firmware written in Rust. This has been made possible by a number of Qualified Rust Toolchains coming to the market, including Ferrocene from Ferrous Systems [22]. These toolchains include the necessary documentation to prove that the toolchain has been assessed to work correctly (when operated in accordance with the given instructions) and can therefore be used as part of a safety-critical software development without the user needing to show the toolchain's correctness (that is, allowing the demonstration of correctness of the toolchain's source-code input rather than its machine-code output). These toolchains are typically qualified [23] for use with IEC 61508 (for industrial systems) ISO 26262 (for road vehicles), and/or ISO 62304 (for medical products). Some may also offer support for use with DO-178C (for airborne systems).

Safety-critical products being developed in Rust at the moment include the Sonair 3D Ultrasonic ADAR sensor [24] and the OxyPrem NOAH newborn tissue oximetry system [25]. The Kite Shield Ultra-Wide Band mining safety system is also "leveraging languages like Rust, to ensure extreme reliability and robustness" [67].

Automotive

One of Rust's first toolchain qualifications was for the ISO 26262 standard. It is therefore unsurprising to hear about Rust's usage in a number of automotive companies. Whilst we have not yet heard about shipping safety-critical firmware written in Rust, Volvo are shipping multiple vehicles today which have certain non-safety-rated components programmed in Rust and RTIC [26]. Renault too have talked about their usage of Rust in vehicles launching in 2026 [27], and that they are looking to use it for safety-critical applications as well. Automotive suppliers Elektrobit have announced Rust support for their AUTOSAR stack [28], as have Vector [29].

Tool Vendors

A number of tool vendors have announced support for Rust within their products. For debuggers, this includes SEGGER's Ozone and Lauterbach's TRACE32 debugger [29]. Indeed, Rolf Segger noted that "With first-class tool support, it has the potential to overtake C and C++" [30].

In terms of static analysis, we see support in TrustInSoft's Analyzer [31], Sonarcube [32] and Deepsource [33]. This indicates that the vendors of tools focussed on earlier languages like C and C++ are seeing the value in adding support for Rust, providing a migration path for existing customers, and opening the product up to new audiences.

Silicon Vendors

Rust is generally operating at the architecture level, with optional support for a particular Operating System on that target. For bare-metal systems however, additional support is required in terms of start-up code and drivers for the peripherals with the SoC or MCU of interest. The start-up code for Arm AArch32, Arm AArch64 and RISC-V is developed by the Rust Project's Embedded Devices Working Group [34]. However, open-source community-developed drivers naturally come without a warranty or professional support. This is where Silicon Vendors (or their partners) can come in, providing those basic layers of start-up and driver code, in a tested package, with a warranty.

Espressif have an in-house Rust team, maintaining support for both their Cadence Xtensa and their RISC-V based wireless-enabled microcontrollers [35]. They provide support for both bare-metal Rust and for running Rust applications on top of their IoT Development Framework (ESP-IDF). Infineon also have a Rust team, offering support for both Arm-based Traveo SoCs and TriCore-based Aurix SoCs [36]. STmicroelectronics too have put out press releases about future Rust support for their ASIL D rated Stellar MCUs [37].

Operating Systems

Rust offers two levels of operating system support for its targets: std and core. A target with std support offers standardised Rust APIs for filesystems (std::fs), multi-threading (std::thread), networking (std::net) and more. A target which has only core support, however, is limited to functionality where the implementation is not operating system specific (core::str for UTF-8 string handling, for example). That is not to say that a target using core can only run bare-metal, however. Because Rust can both bind to and export C-compatible APIs, users can write their own bespoke OS interface libraries. Indeed, for safety-critical applications, this is often preferable to porting the full std library to that OS, as it massively reduces the amount of code that needs to be certified. Low-level Rust bindings can also be auto-generated from C header files using tools such as bindgen [50].

In this table, we present a list of common Real-Time Operating Systems (RTOS), the architectures they run on, and the level of support offered by the Rust Toolchain. The support levels noted here are:

Rust Project offers suitable std
First-party OS interface library exists (using Rust Project's bare-metal core)
Third-party OS interface library exists (using Rust Project's bare-metal core)

RTOS	Architecture	Support Level
ESP-IDF [38]	Xtensa, RISC-V	1
NuttX [39]	Arm, RISC-V	1
QNX Neutrino [40]	Arm, x86	1
RTEMS [41]	Arm	1
VxWorks [42]	Arm, x86, PPC, RISC-V	1
RTEMS [43]	SPARC, RISC-V	2
Zephyr [44]	Arm, RISC-V	2
Amazon FreeRTOS [45]	Arm	3
Eclipse ThreadX [46]	Arm	3

In addition to the 'classic' C-language RTOSes listed above there are a number of novel Rust-based RTOSes which are worth noting here.

TockOS is a classic pre-emptive multi-tasking scheduler, written in Rust, using the MPU to provide hardware isolation between mutually-untrusted tasks [13]. One novel feature of TockOS is that the kernel uses only static memory allocation - any resources required to service a user-space task are provided by the user-space task, and if those resources are unavailable, the user-space task can be restarted without affecting the kernel or any other task. TockOS is used in the Microsoft and Google security processors mentioned earlier, and is also available as a commercial product for the safety-critical market under the name OxidOS.

Hubris is another pre-emptive multi-tasking scheduler, written in Rust - this time specifically for running the System Management Controller in the Oxide Cloud Computer [52]. Again, it uses the MPU to provide hardware isolation between tasks.

Despite so many options being available, for many Embedded Rust applications an RTOS may not even be required. Rust has first-class support for async/await, which provides for concurrency through asynchronous co-routines at a language level. Rust also offers procedural-macros, which provide for build-time code generation using functions written in Rust. Combining these two features, embassy [49] is a library for embedded async. It offers concurrent programming and resource sharing, but using async/await and hardware interrupts as opposed to a full pre-emptive multi-tasking kernel. This makes it much more lightweight (examples run on MCUs with 32K Flash and 4K RAM) and faster to develop. ArielOS is a project that combines embassy with other open-source Rust libraries, aiming to provide a more batteries-included experience [51].

As a kind of half-way house between these two approaches, RTIC [53] is a Hardware-Accelerated RTOS for Arm Cortex-M and RISC-V, developed at Luleå University of Technology in Sweden. RTIC uses the Stack Resource Policy approach to program an Arm Cortex-M Interrupt Controller (or RISC-V equivalent) to provide context-switching, whilst guaranteeing the absence of race hazards and deadlocks at compile-time using procedural macros. The latest version, RTICv2, even added support for async/await tasks (in addition to the co-operative interrupt-driven tasking from RTIC v1). RTIC has been the subject of a number of papers from its authors, regarding its approach to resource sharing and its applicability to high-integrity and safety-critical systems [47] [48]. Ferrous Systems have also used RTIC v1 on multiple safety-critical projects, to great success.

Academic Research for Space Flight

Several institutions have produced papers looking at the use of Rust in space applications, including the University of Stuttgart Institute of Space Systems (IRS), the Deutsches Zentrum für Luft- und Raumfahrt (DLR) and TU Berlin .

IRS developed a Rust library called sat-rs [54] which ran on ESA OPS-SAT [57], noting that "it was possible to write a basic software based on the sat-rs example in around two weeks which is able to drive the payload camera, and has the same ECSS PUS command infrastructure as the example application" [55].

A group at TU Berlin have also demonstrated gradually replacing C functions in a library with their Rust equivalents [56], and the use of Rust with the PowerPC e500mc processor (as used in the rad-hardened Teledyne P2020 SoC [58]). This paper built on work at Ferrous Systems to demonstrate Rust code running on the LEON3 and LEON5 [59] from Gaisler.

DLR presented at ADCSS 2024 on the outcome of their ESA funded package "cRustacea in Space" which noted success in porting Rust's std library to RTEMS, and that Rust provides necessary tools for ECSS qualification [60].

NASA are also running an IRAD to re-write their Core Flight Software in Rust [61]. Details are limited but there was a recent update presentation on Rethinking the Core: Incorporating Rust and Data Distribution Service in cFS at Flight Software Workshop 2025 by Rich Landau [62]. In his opening statement he says "this stuff is years away from being mainstream, but we think this is the direction things are going".

Code coverage is a standard mechanism for showing that a test suite has exercised every relevant line of source code in a program. For the highest levels of criticality (such as DO-178C DAL A), it is often necessary to show Modified Condition/Decision Coverage (MC/DC) - that is, to show that both every decision a program makes, and every condition that went into that decision, is covered. Rust has novel language features (such as pattern-matching) that don't map well to the existing MC/DC specifications, however a recent paper [68] proposes a mapping that will allow the development of MC/DC tools for Rust in the future. This provides a path for Rust to be used in products requiring the highest levels of safety.

Ferrous Systems

The Rust Toolchain itself is a large, complex application, written in Rust, and demonstrated to have very high levels of quality - enough to be a Qualified Toolchain for use with ISO 26262 ASIL D and IEC 61508 SIL 3 applications.

Ferrous Systems obtained this qualification (and continue to renew it with each release) by running test cases against the toolchain, and noting which test cases cover which parts of the Ferrocene Language Specification (FLS). This then produces a Traceability Matrix [63], showing what fraction of the FLS has been covered by the test cases. Further, tools such as mantra [64] can be used to produce requirements coverage reports for arbitrary applications written in Rust - an approach that we have used with clients building safety-certified projects in Ferrocene.

Not only this, but as of the Ferrocene 25.08 release, it also includes a subset of core that has been certified to IEC 61508 SIL 2 [65]. Doing this involves obtaining code coverage metrics and demonstrating that the existing core tests from the Rust Project cover all the necessary components. These tests are executed in CI, and generate the coverage information fully automatically.

In future releases, we expect that libraries built with Ferrocene can be tested with code coverage on the target processor architecture. This is possible using a combination of QEMU user-mode emulation, and special Linux targets which even work on non-MMU platforms like Arm Cortex-M [66]. This provides a considerable step-forward for coverage analysis, compared to the usual approach for re-compiling the libraries for the host architecture and missing out on any target-specific branches or modules.

Conclusions

Rust is being widely used - in the cloud, and on your personal computing device. It is also increasingly being used in automotive, industrial and other quality-managed and safety-critical applications, and the availability of multiple Qualified Rust Toolchains supports this. Research indicates that Rust is also highly applicable to aviation and space-flight applications, and more work is planned here.

Rust: Who, What and Why for ESA SW PA Workshop

Ferrous Systems is presenting a poster at the European Space Agency's Software Product Assurance Workshop on the commercial uses of Rust