Rust's std porting, how much work would that represent?

1
How I ended up there

I’ve recently started learning about OSDev and seL4 is really appealing as a foundation on-top of which I could build things to learn about OSDev, seL4 and Rust ecosystem in general.

My long-term goals are to:

  • contribute to seL4’s Rust landscape,
  • become a decent “OS Developer”,
  • PoC to see if seL4 could be used as the foundation of a next-gen OS specially-made for Servers and Infrastructure (disclaimer: I am working for an European CSP but my employer does not support my seL4 initiative, I do it out of business hours),
  • Porting Wasmtime to this eventual OS based on seL4,
  • Eventually make a living of this work :crossed_fingers:.

I am starting this thread just to have feedback from actually experienced (unlike me) Rust developers and seL4 professionals to see which approach could one take to port Rust’s std crate to their system based on seL4.

I think, it is premature to think about a one-size-fits-all approach as it’ll largely depends on the specific userland of one. But this thread is more about general ideas and approaches produced by the community to serve as reference for future works.

2

I post this for reference:

3

Porting std directly to seL4 makes only limited sense, because seL4 alone doesn’t provide a lot of the services that std assumes. That is, std assumes a roughly POSIX-ish OS underneath with file system and network etc, and seL4 is just a microkernel that you might build such an OS on top of, but it does not provide these services itself.

That said, I think there is direct std support for other microkernels, which is achieved by just returning “unsupported” for most of the std features (esp file system and network). One could always do that, but the question is how much one would gain compared to direct no_std development on top of seL4 with the current no_std crates that seL4 provides.

Or, one could of course start building a dynamic OS personality on seL4 that supports what std assumes, but that is a bigger project.

4

Yes, it’s what I assumed, it would probably be the responsibility of some higher-level layer to provide POSIX-ish like behaviour to ease porting efforts.

5

Another project that could ease porting efforts would be GitHub - bytecodealliance/cap-std: Capability-oriented version of the Rust standard library but I think it would still requires some higher-level abstraction.

6

First echoing @gerwin.klein’s comment, any libstd port with any features at all (as opposed to one consisting only of empty stubs) would be specific to a higher-level framework of OS personality sitting on top of the kernel, rather than the kernel itself.

However, while #![no_std] support in the Rust ecosystem is growing stronger every month, some crates like wasmtime are a long way from being #![no_std] compatible. For the Veracruz project, we drafted an ad-hoc operating system personality, along with and accompanying libstd port, specifically to support wasmtime. The OS personality basically just provided mmap() and fault-based lazy page mapping.

For a bit of context, Veracruz is a framework for privacy-preserving collaborative compute using various backends for confidential compute primitives. The IceCap hypervisor, which is based on seL4, was one such backend. I believe Veracruz has dropped support for IceCap, and this code I’m talking about never actually landed in Veracruz, but here are some links to old branches of various repositories to give you a sense of what was going on:

Let me know if there are any aspects of all of this that you’d like to expand on.

1 Like
7

Thanks a lot for these references !

It will surely help me. For now, I am focusing on getting low-level concepts right as I have mostly been involved in high-level projects.

I also read a lot of references to get inspiration and good ideas, then I would like to try producing a prototype OS personality (btw, I am not sure what is the exact meaning of OS Personality, is it an academic concept or is it strictly related to seL4 eco-system? My understanding is that it’s a specific userland running on seL4).

Also, since we speak about Wasmtime specifically I just wanted to share this link in the thread:

8

(btw, I am not sure what is the exact meaning of OS Personality, is it an academic concept or is it strictly related to seL4 eco-system? My understanding is that it’s a specific userland running on seL4)

By OS personality, I mean a subsystem that provides a userspace environment with elements of some familiar OS API. For example, in the case at hand, Veracruz is not a Unix-like system, but the component running Wasmtime is supervised by (i.e. managed by) a more privileged component which provides it with an OS API which includes mmap(). One could say that the more privileged component is, exposes, or provides an OS personality for the Wasmtime component.

(This phrase is not specific to the seL4 ecosystem)