oxidecomputer

hubris

Rust2021–2026

oxidecomputer / hubris

hubris

A lightweight, memory-protected, message-passing kernel for deeply embedded systems.

Systems & Infrastructure Hardware & Embedded

Explore on GitHub Read Hacker News discussions

22Distinct people

39Mentions

1Explicit recommenders

3.6KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

A lightweight, memory-protected, message-passing kernel for deeply embedded systems.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

Hubris is really, really nice. I've spent half an hour reading some of the kernel code and it’s exceptionally clear and well written - a far cry from ifdef macro soup, two…

orf used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

oxidecomputer/humility · linked in 5 of the same discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 9:28:18 AM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year39 dated mentions

Observed mentions: 2021-11-30 15:34:09 UTC to 2026-07-14 17:57:33 UTC.

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	10	10
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	9	9
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	9	9
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	6	6
2025	2025-01-01 00:00:00 UTC	2026-01-01 00:00:00 UTC	2	2
2026 (partial)	2026-01-01 00:00:00 UTC	2027-01-01 00:00:00 UTC	3	3

What Hacker News says

9 sources

bcantrill·Oct 9, 2022

Oh, sorry: "VR" is a "voltage regulator" in this context. You can see our drivers for these parts in Hubris, our all-Rust system that runs on our service processor.[0] All of our drivers are open, but the parts themselves do contain (small) proprietary firmware blobs. [0] https://github.com/oxidecomputer/hubris

In I have come to bury the BIOS, not to open it [video]

mkeeter·Oct 4, 2022

Hubris is a microkernel-ish OS for embedded systems, and has a bunch of documentation about its design: https://hubris.oxide.computer/reference/ It's all open-source on Github: https://github.com/oxidecomputer/hubris (I work at Oxide, mostly using Hubris)

In Ask HN: Examples of Microkernels?

steveklabnik·Jul 12, 2022

Ahh whoops you’re right, lol. Embarrassing. Hubris was designed to be easy to port to RISC-V, so yes! We didn’t end up doing that though. Someone else did though! https://github.com/oxidecomputer/hubris/discussions/365

In GCC Rust Approved by GCC Steering Committee

wyldfire·May 10, 2022

Maybe zephyr [1] is a good option for those ECUs? or hubris [2]? [1] https://docs.zephyrproject.org/latest/introduction/index.htm... [2] https://github.com/oxidecomputer/hubris

In Red Hat in-vehicle operating system in modern and future vehicles

the_duke·Apr 25, 2022

Every (popular) modern operating system sits on decades old foundations written in C that can't just be replaced, so that's not a particularly strong argument. It's noteworthy that Google is financing the effort to bring Rust to the Linux kernel, that Microsoft is also investing in the language and that there are newer, production usage focused operating systems written in Rust. (eg Hubris [1]) [1] https://github.com/oxidecomputer/hubris

In The Hare programming language

bcantrill·Mar 31, 2022

It is indeed a very small risk in the larger scope -- and besides, using I2C isn't optional: all of the devices on the board (from converters/regulators, temp sensors, clock generators and fan controllers to CPUs, DIMMs, NICs, and NVMe drives) have I2C (or I2C-based) management interfaces. If you'd like more concrete detail, take a look at the Hubris app definition for our Gimlet board.[0] [0] https://github.com/oxidecomputer/hubris/blob/master/app/giml...

In Your computer is a distributed system

bcantrill·Mar 28, 2022

Other folks have mentioned this, but it's important to understand the limitations of Rust with respect to safety. In particular: every stack operation is -- at some level -- an unsafe operation as it operates without a bounds check. This isn't Rust's fault per se; non-segmented architectures don't have an architecturally defined way to know the stack base. As a result, even an entirely safe Rust program can make an illegal access to memory that results in fatal program failure. That, of course, assumes memory protection; if you don't have memory protection (or, like many embedded operating systems, you don't make use of it), stack overflows will plow into adjacent memory. But wait, it gets worse: stack overflows are often not due to infinite stack consumption (e.g., recursion) but rather simply going deep on an unusual code path. If

Read the rest

stack consumption just goes slightly beyond the base of the stack and there is no memory protection, this is corrupt-and-run -- and you are left debugging a problem that looks every bit like a gnarly data race in an unsafe programming language. And this problem becomes especially acute when memory is scarce: you really don't want a tiny embedded system to be dedicating a bunch of its memory to stack space that will never ("never") be used, so you make the stacks as tight as possible -- making stack overflows in fact much more likely. Indeed, even with the MPU, these problems were acute in the development of Hubris: we originally put the stack at the top of a task's data space, and its data at the bottom -- and we found that tasks that only slightly exceeded their stack (rather than running all of the way through its data and into the protection boundary) were corrupting themselves with difficult-to-debug failures. We flipped the order to assure that every stack overflow hit the protection boundary[0], which required us to be much more intentional about the stack versus data split -- but had the added benefit of allowing us to add debugging support for it.[1] Stack overflows are still pesky (and still a leading cause of task death!), but without the MPU, each one of these stack overflows would be data corruption -- answering for us viscerally what we "need the MPU for." [0] https://github.com/oxidecomputer/hubris/commit/d75e832931f67... [1] https://github.com/oxidecomputer/humility#humility-stackmarg...

In Oxide on My Wrist: Hubris on PineTime was the best worst idea

est31·Mar 28, 2022

TIL about Hubris, very cool! One could probably also mention the bunch of hypervisors, as they run on the bare metal as well, and maybe Tock, and I'm probably unaware of a bunch. Rust is definitely a hot language when it comes to OS development, which is really great. I've cloned hybris [0], it seems to have 48k lines of Rust source code. Maybe there are other components that I'm missing. Fuchsia [1] on the other hand had 2.1 million lines of Rust in Dec 2020 [2], and according to tokei has 3.3 million as of now (8b51db9e2b809, March 28 2022), more than it has C++ (2.2 million) and C (366k) combined. For comparison, a full check out of the rust-lang/rust repo with all the submodules which contains rustc as well as tools like cargo, rustfmt or clippy, and their test suites, contains 2.1 million lines. But yeah you can come up with several

Read the rest

definitions of "serious". Is an OS that an entire company bases its revenues on more serious than a research project that some call as a way to maintain senior developer retention, but may one day replace components of one of the most deployed end user operating systems in the world? [0]: https://github.com/oxidecomputer/hubris [1]: https://fuchsia.googlesource.com/fuchsia/ [2]: https://www.reddit.com/r/rust/comments/k9djda/expanding_fuch...

In Fuchsia Workstation

mkeeter·Jan 30, 2022

Thanks Steve! It turns out I had misremembered; the cast I was thinking of is https://github.com/oxidecomputer/hubris/blob/master/sys/kern... from &mut MaybeUninit<[T]> to &mut [MaybeUninit<T>], which doesn't construct a reference to something uninitialized.

In Uninitialized memory: Unsafe Rust is too hard