Hubris: Oxide Computer's Memory-Protected Embedded OS for Microcontrollers

What Hubris Is and the Problem It Addresses

Hubris is a microcontroller operating environment designed for embedded systems where reliability is a hard requirement. Its core design premise is memory protection between tasks: each task runs in its own isolated region of memory and cannot directly access another task's memory. Communication between tasks happens only through message passing, not shared memory.

This isolation model trades some performance overhead for a degree of fault containment that a flat embedded application cannot provide. A bug in a driver task that corrupts memory stays within that task's region rather than propagating to the application. The operating environment can then restart the offending task without taking down the entire system.

Hubris is the actual firmware kernel used in Oxide Computer Company's rack-scale server hardware, specifically in their service processor (SP) design. The repository contains real production firmware, not a research prototype. The most recent releases, all published on 2026-09-17 and 2026-09-18, are labeled as SP releases.

Repository Layout and How It Is Organized

The repository is a Cargo workspace with several top-level directories that reflect the separation between the OS kernel, device drivers, application code, and build infrastructure.

The sys/ directory contains the kernel (sys/kern), the shared ABI crate (sys/abi), and the user library that tasks link against (sys/userlib). The drv/ directory holds drivers organized by the convention drv/SYSTEM-DEVICE for driver lib crates and drv/SYSTEM-DEVICE-server for server bin crates. The app/ directory contains the top-level binary crates for applications, for example app/gimlet for the Gimlet server firmware.

The idl/ directory holds interface definitions written in Idol, Oxide's interface definition language for Hubris. Idol generates the message serialization and dispatch code for task interfaces. The chips/ directory contains peripheral definitions and debugging support files for specific microcontrollers. The task/ directory holds reusable tasks that are not drivers.

The build/ directory contains the build system crates. The lib/ directory holds general-purpose utility libraries.

Building Firmware with xtask

Hubris does not use cargo build or cargo run directly because those commands are not flexible enough for its multi-architecture build. Instead, the repository includes a Cargo extension called xtask that provides custom build commands.

To build a distribution image for a specific board, pass the corresponding TOML file to xtask dist:

cargo xtask dist app/demo-stm32f4-discovery/app.toml

Other board targets in the repository include:

cargo xtask dist app/demo-stm32h7-nucleo/app-h743.toml
cargo xtask dist app/gimletlet/app.toml

For faster iteration on a single task without rebuilding the entire image, use xtask build with the task name:

cargo xtask build app/gimletlet/app.toml ping

To run clippy against a task in the context of a specific image:

cargo xtask clippy app/gimletlet/app.toml ping pong

The build is complex because different tasks target different CPU architectures within the same image. The xtask dist command handles the multi-architecture linking step. A full image build can take 10 seconds or more.

The Humility Debugger and rust-analyzer Integration

Hubris has a companion debugger called Humility, maintained in a separate repository at oxidecomputer/humility. Humility understands Hubris's task isolation model, message passing protocol, and DWARF debug information layout. It installs via cargo:

cargo install --git https://github.com/oxidecomputer/humility.git --locked humility-bin

Note from the README: this command should be run from a directory other than the Hubris repository root, because the rust-toolchain.toml in the root would otherwise pin the Humility build to Hubris's toolchain version rather than Humility's own.

For rust-analyzer, the Hubris build system cannot be used directly because rust-analyzer requires a standard cargo setup. The repository provides xtask rust-analyzer as a shim that intercepts rust-analyzer setup messages and applies the correct configuration for a specific (manifest, task) tuple. An alternative is to generate a synthetic Cargo workspace using xtask pseudo-workspacify.

On Windows, hardware programming tooling such as OpenOCD can be installed through either choco install openocd or scoop install openocd; the README notes that the scoop variant has been problematic for some users.

Idol: The Interface Definition Language for Task Interfaces

Hubris tasks that expose services to other tasks define their interfaces in Idol (short for Idolatry), a custom IDL maintained at oxidecomputer/idolatry. Idol generates the serialization and dispatch code that turns a Hubris message-passing exchange into a typed function call.

This separates interface definition from implementation. A task that wants to call a driver only needs the Idol interface file, not the driver's implementation. The interface file in idl/ is the contract between caller and server tasks.

This design is relevant for anyone considering Hubris: the toolchain is specific to Oxide's ecosystem. Idol is not a general-purpose IDL like DBUS or Cap'n Proto; it is designed specifically for Hubris's synchronous message-passing model.

Limitations: Build Complexity and Narrow Hardware Target

Hubris targets deeply embedded microcontrollers, primarily ARM Cortex-M. The chips/ directory defines which specific microcontrollers are supported. If a target microcontroller is not present, adding support requires writing peripheral definitions and debugging support files.

Linker behavior differences between Linux, Windows, macOS, and Illumos can cause the produced binaries to differ across platforms. The README recommends designating one official build platform for producing release images. The CI system produces blessed images on Linux.

The build system complexity means onboarding has a higher friction than a standard embedded Rust project. Engineers expecting to use cargo build and cargo flash directly will need to learn xtask's conventions. The rust-analyzer integration requires a manual shim rather than working out of the box.

Hubris has no support for dynamic memory allocation in the general sense. The task isolation model assumes static memory regions. Applications that need runtime heap allocation of variable-size structures will not find Hubris's memory model compatible.

Maintenance, License, and Releases

The last push to the repository was on 2026-09-24. Three releases were published in September 2026: SP v1.80.0 on 2026-09-17, SP v1.79.1 on 2026-09-18, and SP v1.81.0 on 2026-09-18. These are service processor releases for Oxide's hardware.

The license is MPL-2.0 (Mozilla Public License 2.0). MPL-2.0 is a file-level copyleft license: modifications to existing files must be shared under MPL-2.0, but the license allows combining Hubris components with code under other licenses as long as the MPL-2.0 files themselves remain MPL-2.0.

The Cargo.toml at the workspace root uses resolver = '2' and sets release profile options: codegen-units = 1, debug = 2, lto = true, and opt-level = 'z' (optimize for size). The dev profile uses opt-level = 1 because zero optimization was too slow for flash size constraints.

The workspace dependencies are tightly versioned. For example, cargo_metadata is pinned to exactly 0.21.0 via a comment explaining it threads the needle between Rust version support and a specific bug fix. clap is pinned to 3.0.14. These pins reflect the reality of building firmware for a specific hardware target where dependency drift can break the build in subtle ways. A CODEOWNERS file at the root specifies which team members are responsible for which parts of the codebase.

Editorial conclusion

Hubris is appropriate for teams building deeply embedded systems with strict reliability requirements who are using Rust and are comfortable with a non-standard build system. The xtask-based build system, the Idol IDL for inter-task interfaces, and the Humility debugger form a coherent toolchain that only makes sense as a package. Engineers who want a standard Rust embedded project with RTIC or embassy should not use Hubris: those frameworks integrate with standard cargo and have a much smaller adoption cost. Verify that your target microcontroller is in the chips/ directory and that a matching app/ TOML file exists before committing to Hubris as a platform.

Frequently asked questions

Official sources

1. Issues
2. License: MPL-2.0
3. oxidecomputer/hubris on GitHub
4. README
5. Releases