[nuta]

In addition to its huge contribution to OS development in Rust, as a microkernel enthusiast, it sounds exciting to writing a microkernel in Rust, in the "Everything is a URL" principle. Moreover, it can run a good-looking GUI on a real machines [1]! I know it's very hard to be realized.

Aside from Redox, I'd mention Tock [2], an embedded operating system. It introduces a novel components isolation using Rust's power. I believe this field is where Rust shines and am looking forward to seeing it in production.

[1]: https://www.redox-os.org/screens/ [2]: https://www.tockos.org

[panick21_]

There are more good efforts, the BeTrusted guys are working on Xous, its a microkernel for a phone like device called the Precurser.

https://github.com/betrusted-io/xous-core

As a embedded service processor OS for a big server rack, Oxide Computer is working on 'HubrisOS'. They seem to have not released it yet, but that will be open sourced.

https://github.com/oxidecomputer

Those are two efforts where I know real resources are going into.

[surajrmal]

Is Hubris targeted at BMCs? Or is something different?

[bcantrill]

Hubris is targeted at microcontrollers. Much more information (and, importantly, the source code!) will be available in our talk at the Open Source Firmware Conference[0], the abstract for which elaborates on our motivations and use case:

On Hubris and Humility: when "write your own OS" isn't the worst idea

Hubris is a small open-source operating system for deeply-embedded computer systems, such as our server's replacement for the Baseboard Management Controller. Because our BMC replacement uses a lower-complexity microcontroller with region-based memory protection instead of virtual memory, our options were limited. We were unable to find an off-the-shelf option that met our requirements around safety, security, and correctness, so we wrote one.

Hubris provides preemptive multitasking, memory isolation between separately-compiled components, the ability to isolate crashing drivers and restart them without affecting the rest of the system, and flexible inter-component messaging that eliminates the need for most syscalls -- in about 2000 lines of Rust. The Hubris debugger, Humility, allows us to walk up to a running system and inspect the interaction of all tasks, or capture a dump for offline debugging.

However, Hubris may be more interesting for what it doesn't have. There are no operations for creating or destroying tasks at runtime, no dynamic resource allocation, no driver code running in privileged mode, and no C code in the system. This removes, by construction, a lot of the attack surface normally present in similar systems.

This talk will provide an overview of Hubris's design, the structure of a Hubris application, and some highlights of things we learned along the way.

[0] https://talks.osfc.io/osfc2021/featured/

[panick21_]

I think its an FPGA with a costume Open-Source Titan chip on it (RISC-V). It is not really a traditional BMC, its more like a service processor that does secure boot and gets you in the OS. It does a few other things but I think they really want it to have minimum functionality.

This is a great talk about what they do and why: https://www.youtube.com/watch?v=vvZA9n3e5pc

[bcantrill]

This is a very reasonable inference, as it absolutely was when I gave that talk. ;) Very shortly after that talk, however, we came to the realization that the OpenTitan was not going to be what we needed when we needed it, and moved to a Cortex M7-based microcontroller for our service processor (and a separate M33-based microcontroller for our root of trust); Hubris is the operating system that runs on those two MCUs.

[panick21_]

Not that it matters all that much, but why a Cortex when you can get RISC-V chips form SiFive (or whoever) that do about the same stuff?

Does that mean the product will not have an FPGA? I kind of liked that idea of updating the hardware.

P.S: Twitter spaces about the history of computing are really fun. Love to hear more about all the dead computer companies you researched. There is not enough content about computer history out there.

[bcantrill]

Yeah... a bunch of reasons. We definitely have a couple of FPGAs in the product (Bluespec FTW!), and we anticipate that we will have more over time -- but not for the RoT or SP, or at least not now. The reasons are different for each, but include:

1. ASICs are out of the question for us for a bunch of economic reasons

2. FPGAs by and large do not have a good security story

3. The ones that do (or rather, the one that does) has an entirely proprietary ecosystem and a terrible toolchain -- and seems to rely on security-through-obscurity

4. Once you are away from a softcore, the instruction set is frankly less material than the SoC -- and the RISC-V SoC space is still immature in lots of little ways relative to the Cortex space

5. Frankly, there's a lot to like about ST: good parts, good docs, good eval boards, pretty good availability (!), minimum of proprietary garbage.

We tried really hard (and indeed, I think my colleagues would say that I probably tried a little too hard) to get FPGAs to be viable, and then to get FPGAs + hardcores to be viable, and then multicore hardcores to be viable (one for the SP, one for the RoT). Ultimately, all of these paths proved to be not yet ready. And while we're big believers in FPGAs and RISC-V, we're even bigger believers in our need to ship a product! ;)

[monopoledance]

Thanks for sharing!

I have to say, I feel a bit “dirty” carrying so much unused and legacy code around with Linux, so I like people trying to reinvent the wheel just for the pleasure of a fresh start. For the aesthetics. Even if it’s merely a fantasy and not replacing anything soon, realistically. They are also keeping OS development accessible to new generations of geeks. The unfriendliness of C, the gigantic codebase and seemingly distinct culture make the Linux kernel quite off putting, filtering possible engagement by unfortunate parameters IMO. Novel OS development in Rust takes away at least some of those barriers and some of the gained knowledge may be applicable with the Linux kernel later.