Rust OSDev Operating System Development in Rust

This Month in Rust OSDev: September 2026

Published on (edited by @phil-opp)

Welcome to a new issue of "This Month in Rust OSDev". In these posts, we give a regular overview of notable changes in the Rust operating system development ecosystem.

This series is openly developed on GitHub. Feel free to open pull requests there with content you would like to see in the next issue. If you find some issues on this page, please report them by creating an issue or using our comment form at the bottom of this page.

Please submit interesting posts and projects for the next issue by commenting on the draft pull request or via a PR on GitHub.

Disclaimer: Automated scripts and AI assistance were used for collecting and categorizing links. Everything was proofread and checked manually, with many manual tweaks.

Announcements, News, and Blog Posts

Here we collect news, blog posts, etc. related to OS development in Rust.

Infrastructure and Tooling

In this section, we collect recent updates to rustc, cargo, and other tooling that are relevant to Rust OS development.

rust-osdev Projects

In this section, we give an overview of notable changes to the projects hosted under the rust-osdev organization.

uefi-rs

Maintained by @nicholasbishop and @phip1611

uefi makes it easy to develop Rust software that leverages safe, convenient, and performant abstractions for UEFI functionality.

We continued last month's soundness and specification compliance work. The common theme: the crates no longer blindly trust what the firmware reports. For example, boot::memory_map trusted the map size reported by the firmware, so sorting a map larger than its buffer read out of bounds, and several boot and protocol functions turned null pointers returned by the firmware into handles or references. In uefi-raw, we audited the pointer mutability of the protocol definitions against the UEFI and PI specifications. This is breaking for the raw bindings, but it lets the high-level uefi crate hand out &/&mut without lying to the compiler.

Not everything was about fixing things. uefi-raw gained HII Internal Forms Representation (IFR) types and uefi gained the AbsolutePointer protocol, CString16::extend, and allocation-free iteration over the components of a Path.

All of this was released as uefi v0.41.0, uefi-raw v0.17.0, and uefi-macros v0.20.0.

As mentioned last month, Anthropic sponsors @phip1611 with a Max plan as part of their open source program. Much of the auditing above happened under that sponsorship, and we are happy that it helps us improve the security, robustness, and reliability of the ecosystem.

Thanks to @crawfxrd, @cwize1 and @the-shank for their contributions!

We merged the following PRs this month:

acpi

Maintained by @IsaacWoods

The acpi repository contains crates for parsing the ACPI tables – data structures that the firmware of modern computers uses to relay information about the hardware to the OS.

We merged the following changes this month:

Thanks to @dewyatt, @martin-hughes, @mkroening, and @ChocolateLoverRaj for their contributions!

virtio-spec-rs

Maintained by @mkroening

The virtio-spec crate provides definitions from the Virtual I/O Device (VIRTIO) specification. This project aims to be unopinionated regarding actual VIRTIO drivers that are implemented on top of this crate.

This month, the crate was upgraded to version 1.4 of the VIRTIO specification and gained virtio-blk definitions, released as v0.4.0:

x86_64

Maintained by @phil-opp, @josephlr, and @Freax13

The x86_64 crate provides various abstractions for x86_64 systems, including wrappers for CPU instructions, access to processor-specific registers, and abstraction types for architecture-specific structures such as page tables and descriptor tables.

We published a first release candidate for v0.16.0 this month. We merged the following changes:

Thanks to @mkroening for their contributions!

multiboot2

Maintained by @phip1611

Convenient and safe parsing of Multiboot2 Boot Information (MBI) structures and the contained information tags. Usable in no_std environments, such as a kernel. An optional builder feature also allows the construction of the corresponding structures.

The raw_type! macro we announced last month landed. For users, this means that values unknown to the specification - an unknown header tag type, architecture, or memory area type - no longer produce undefined behavior. They now arrive as a Custom variant that can simply be ignored.

On the builder side, structures built on the stack could leak uninitialized padding bytes into the output. Built structures are now byte-wise identical to before, except that the padding between tags is guaranteed to be zeroed - so what a bootloader hands to a kernel no longer depends on whatever was on the stack.

Released as multiboot2 v0.27.0 and v0.28.0, multiboot2-header v0.11.0, and multiboot2-common v0.6.0 and v0.7.0. These come with a few breaking changes, most notably that Header and MaybeDynSized are now unsafe traits, which affects users implementing custom tags.

We merged the following PRs this month:

uart_16550

Maintained by @phip1611

Simple yet highly configurable low-level driver for 16550 UART devices, typically known and used as serial ports or COM ports.

v0.8.1 adds the public method Uart16550::check_present(), which probes for a device through the scratch register. init() now delegates its existing presence check to it, so users can run the same probe on their own before touching the device.

The repository also gained a real-hw-test crate member that builds a bootable EFI image. This makes it much easier to verify the driver on real hardware rather than only in virtual machines - which is exactly what this crate was rewritten for.

We merged the following PRs this month:

Other Projects

In this section, we describe updates to Rust OS projects that are not directly related to the rust-osdev organization. Feel free to create a pull request with the updates of your OS project for the next post.

No project updates were submitted this month.

Join Us?

Are you interested in Rust-based operating system development? Our rust-osdev organization is always open to new members and new projects. Just let us know if you want to join! A good way to get in touch is our Zulip chat.

Comments