Interesting, didn't hear from this system so far. Seems to be funded by the EU. Apparently it is written in pure Rust since 2020, and Andrew "bunnie" Huang seems to be involved.
From the talk linked above, they went to considerable effort to design a system with a cheap processor which nevertheless contains an mmu, and so most other embedded kernels, which assume the lack of one, are not applicable. So the point of writing in rust is that they can ensure that some of the guarantees of rust are enforced by the hardware. (It's been a while since I watched that talk, so I don't recall exactly which ones). And this is a microkernel, not a monolithic kernel, so they will be using hardware guarantees even between kernel components.
It's not really about infrastructure but yes kernels and firmwares have to do a lot of stuff the compiler can't verify as safe, eg writing to a magic memory address you obtained from the datasheet that enables some feature of the chip. And that will need to happen in unsafe code blocks. I wouldn't call that a problem but it is a reality.
Are you one of the authors? Concerning the "infrastructure": Rust assumes a runtime, the standard library assumes a stack exists, a heap exists, and that main() is called by an OS; in a kernel, none of this is true. And the borrow checker cannot reason about things like e.g. DMA controllers mutating memory the CPU believes it owns, Memory-mapped I/O where a "read" has side effects (violating functional purity), context switches that require saving register state to arbitrary memory locations, or interrupt handlers that violate the call stack model. That's what I mean by "infrastructure". It's essentially the same issue with every programming language to some degree, but for Rust it is relevant to understand that the "safety guarantees" don't apply to all parts of an operating system, even if written in Rust.
Rust's safety model only applies to code you write in your program, and there's a lot that's unsafe (cannot be verified by the compiler) about writing a kernel or a firmware, agreed. You could have similar problems when doing FFI as well.
Use of "unsafe" is unavoidable. Various pieces of hardware are directly writing into the address space. Concepts of "ownership" and "mutability" go beyond code semantics.
Key aspects from the talk iirc (I was in the audience :)):
* Real time embedded CPUs are usually without an MMU -> kernels such as FreeRTOS lack secure memory due to the lack of MMUs in those CPUs
* A kernel targeting embedded CPUs with MMUs that supports secure memory management
* Secure memory communication a there called server/client method to communicate leveraging Rust borrow checker build time for later having "user-land processes" to communicate via pages.
These things combined allow a very small kernel, with user-space implementation of usually kernel-level functionality, such as the system clock timer (presented in the talk).
All of this is meant to provide a complete trustworthy processing chain, from CPU dies that can be inspected through infrared microscopy through the CPU epoxy package/cover to the entire build/software tool chain.
The Xous OS project both takes care of the Kernel, but also the CPU/RISC-V runtime with an MMU, something that is usually quite difficult to obtain - but due to synergy effects with another chip consumer/organization they managed getting their custom processor manufactured.
> Every Xous Server contains a central loop that receives a Message, matches the Message Opcode, and runs the corresponding rust code
They lost me here. An OS has no business dictating implementation language. Inside my isolated microservice, I should be able to run anything I damn well please.
I'm a fan of microkernels and microservice models in general, but not if they sacrifice one of their core advantages: arms-length decoupling of implementation strategies through having isolated services communicate only through stable, versioned interfaces.
Is there a PDF version of the book (https://betrusted.io/xous-book/)?
I assume the "kernel" makes heavy use of "unsafe", because all the infrastructure assumed by Rust is not available. Or how was this solved?
The standard library requires a heap and such, but you can enable the no_std attribute to work in environments where they don't exist. https://docs.rust-embedded.org/book/intro/no-std.html
Rust's safety model only applies to code you write in your program, and there's a lot that's unsafe (cannot be verified by the compiler) about writing a kernel or a firmware, agreed. You could have similar problems when doing FFI as well.
* Real time embedded CPUs are usually without an MMU -> kernels such as FreeRTOS lack secure memory due to the lack of MMUs in those CPUs
* A kernel targeting embedded CPUs with MMUs that supports secure memory management
* Secure memory communication a there called server/client method to communicate leveraging Rust borrow checker build time for later having "user-land processes" to communicate via pages.
These things combined allow a very small kernel, with user-space implementation of usually kernel-level functionality, such as the system clock timer (presented in the talk).
All of this is meant to provide a complete trustworthy processing chain, from CPU dies that can be inspected through infrared microscopy through the CPU epoxy package/cover to the entire build/software tool chain.
The Xous OS project both takes care of the Kernel, but also the CPU/RISC-V runtime with an MMU, something that is usually quite difficult to obtain - but due to synergy effects with another chip consumer/organization they managed getting their custom processor manufactured.
They lost me here. An OS has no business dictating implementation language. Inside my isolated microservice, I should be able to run anything I damn well please.
I'm a fan of microkernels and microservice models in general, but not if they sacrifice one of their core advantages: arms-length decoupling of implementation strategies through having isolated services communicate only through stable, versioned interfaces.