10 ms·

Writing an OS in Rust

202 points by jfreax 11y ago

achanda358 11y ago
https://github.com/flosse/rust-os-comparison https://github.com/flosse/rust-os-comparison
bitdivision 11y ago
I recently found out about Redux: https://github.com/redox-os/redox https://github.com/redox-os/redox It's pretty incredible how quickly it's come together, there's a reasonable looking GUI already! Edit: The author also did an AMA on reddit: https://www.reddit.com/r/rust/comments/3mw67c/i_am_jackpot51_the_writer_of_redox_a_rust/ https://www.reddit.com/r/rust/comments/3mw67c/i_am_jackpot51...
- kibwen 11y ago
  Now with weekly progress reports: http://www.redox-os.org/news/this-week-in-redox-3/ http://www.redox-os.org/news/this-week-in-redox-3/
mtgx 11y ago
Relevant: https://github.com/wbthomason/ironkernel https://github.com/wbthomason/ironkernel
cwzwarich 11y ago
As far as I can tell, Rust OS projects generally use gratuitous amounts of unsafe code and are not substantially different than if they were written in C. I could just be looking in the wrong places. Are there any that take advantage of Rust's type system to provide real guarantees?
- Rusky 11y ago
  That may just be the impression given by tutorials, which spend most of their time dealing with the hardware. In a real OS, you'd wrap that up in safe interfaces and then the core of things like scheduling, file systems, etc. could be in a safe layer on top of the unsafe drivers.
  - cwzwarich 11y ago
    But has anyone actually done that? Can you even express those as safe interfaces in Rust?
    - Jweb_Guru 11y ago
      IMO, the answers to those questions are "no" and "yes" respectively. Redox in particular seems like it has way more unsafe code than it actually has to (though it seems to have gotten a bit better very recently).
    - chadaustin 11y ago
      It's the same thing with Haskell, or any other "real" system that, at some level, has to interface with low-level primitives. The platform gives you a pile of unsafe, low-level primitives ( https://hackage.haskell.org/package/ghc-prim-0.4.0.0/docs/GHC-Prim.html https://hackage.haskell.org/package/ghc-prim-0.4.0.0/docs/GH... ) on top of which you (or a library writer) can provide safe interfaces, e.g. https://hackage.haskell.org/package/buffer-builder https://hackage.haskell.org/package/buffer-builder
      - MaxGabriel 11y ago
        The unsafe low-level stuff gives rise to some great function names like `reallyUnsafePtrEquality` and `accursedUnutterablePerformIO` https://github.com/haskell/bytestring/blob/dd3c07d115840d13482426a0084a39201eb6b6d4/Data/ByteString/Internal.hs#L515-L546 https://github.com/haskell/bytestring/blob/dd3c07d115840d134...
- kibwen 11y ago
  The OP talks about this in the most recent post: "In the previous post we switched from assembly to Rust, a systems programming language that provides great safety. But so far we are using unsafe features like raw pointers whenever we want to print to screen. In this post we will create a Rust module that provides a safe and easy-to-use interface for the VGA text buffer."
  - deleted 11y ago
    [deleted]
- steveklabnik 11y ago
  I expect a lot of this to be like this at first: https://www.reddit.com/r/rust/comments/3mw67c/i_am_jackpot51_the_writer_of_redox_a_rust/cvizko4?context=2 https://www.reddit.com/r/rust/comments/3mw67c/i_am_jackpot51... There's a period of writing only all the usual stuff that you've done before, then slowly discovering what kinds of abstractions you can put over it, and what kinds of stuff needs to remain super-low.
- ntrepid8 11y ago
  There are times that you have to do "unsafe" things when interacting directly with hardware. That's not to say one shouldn't attempt to limit the use of "unsafe" to use cases that absolutely require it.
steveklabnik 11y ago
I've read through what was here, and last night, actually built the first post's code. I really like the depth and style of this particular posts, it really hits a sweet spot.
bulutsuzku 11y ago
What's the value and novelty of writing an OS in Rust?
- steveklabnik 11y ago
  > value Well, Rust is a systems language, and so it should be a good fit for OS development. We're still working on bits of it, but it's a stated goal of the language, so testing that out is valuable. > Novelty Well, Rust is still a fairly young language, so there aren't a ton of people doing things with it yet, relatively speaking. And for OS dev, which is kind of a niche subject anyway (as much as I love it), there's naturally even less. So it's basically novel by definition.
  - bulutsuzku 11y ago
    > Well, Rust is a systems language, and so it should be a good fit for OS development. We're still working on bits of it, but it's a stated goal of the language, so testing that out is valuable. My questions was not well formulated. Let me rephrase it: C is also a system language and there are plenty of OS libraries written in C. C++ could be seen as another system language. Even the syntax of Rust is similar to C/C++ according to Wikipedia article. So, what's the advantage of Rust over other systems language? Better support for autonomous systems? Reflective model? Do you have a paper? It is a research project? Do you plan to replace Linux or something like that?
    - Zarathustra30 11y ago
      (Safe) Rust provides some nice guarantees. It (should be) impossible to have use-after-free, buffer overruns, race conditions, etc. in 100% Safe Rust. A pure Rust OS could provide a safe interface to build safe programs. While mostly a novelty, an OS capable of executing untrusted code risk-free could be a powerful tool indeed.
    - steveklabnik 11y ago
      > what's the advantage of Rust over other systems language? Memory safety without garbage collection is Rust's core feature. > Do you have a paper? It is a research project? I'm not the author.
monocasa 11y ago
No -mno-redzone?
Animats 11y ago
I'd like to see someone re-implement the QNX real-time microkernel in Rust. That would be useful. We need a QNX-like OS for embedded devices. Linux is really the wrong tool for the job. Too much extra stuff which allows attacks.
- walterbell 11y ago
  Could RIM open-source QNX, if the Blackberry Android device is successful?
  - protomyth 11y ago
    I doubt they would give up that money stream in their current condition (automobiles for one market).
  - jacquesm 11y ago
    I asked, both before QS sold it to RIM and after the deal, in both cases I didn't even get an answer (and I would have been in a position to put up a substantial chunk of money in order to get a dual license deal in place). Real pity, but maybe it will still happen. QnX is one of the most elegant OSs out there and having a public domain or GPL'd version of it would be a great thing.
  - Animats 11y ago
    I'm hoping they open source QNX after the Blackberry disappears. The Blackberry is a dead end, but we really need something solid for embedded work.
- nickpsecurity 11y ago
  I agree. That or at least MINIX 3's core components as there's already source available. Plus, that would likely get extended by all the people building servers and stuff. Be two versions like with Linux.
- xj9 11y ago
  What about seL4[1]? It isn't real-time, but it is small, performant, and formally verified. [1]: http://sel4.systems http://sel4.systems
codepie 11y ago
I was looking for something similar in C. Most of the resources I found (eg : os dev-wiki) do not cover the implementation details in such depth. Can anyone give few pointers?
devit 11y ago
If anyone is considering working on an OS in Rust, they could perhaps consider writing a small hypervisor that could replace Xen, Nova and similar hypervisors. This provides the same low-level challenges of writing a kernel, but it's far easier to get practically usable software than attempting to replace Linux and would actually be useful in practice. At the moment, the only way to make a sandbox that has a chance of being perfectly secure (i.e. no security holes, ever) while still running all kinds of useful software is to use VMs to sandbox Linux/Windows kernels, and here the hypervisor is of course the weak point, and current usable hypervisors are written in C or C++.
- steveklabnik 11y ago
  https://internals.rust-lang.org/t/unikernels-in-rust/2494 https://internals.rust-lang.org/t/unikernels-in-rust/2494
  - devit 11y ago
    This seems to be about using Rust for the kernel running inside the virtual machines, not for the hypervisor itself, which is what I was talking about.

202 points by jfreax 11y ago

https://github.com/flosse/rust-os-comparison https://github.com/flosse/rust-os-comparison

I recently found out about Redux: https://github.com/redox-os/redox https://github.com/redox-os/redox It's pretty incredible how quickly it's come together, there's a reasonable looking GUI already! Edit: The author also did an AMA on reddit: https://www.reddit.com/r/rust/comments/3mw67c/i_am_jackpot51_the_writer_of_redox_a_rust/ https://www.reddit.com/r/rust/comments/3mw67c/i_am_jackpot51...

kibwen 11y ago
Now with weekly progress reports: http://www.redox-os.org/news/this-week-in-redox-3/ http://www.redox-os.org/news/this-week-in-redox-3/

mtgx 11y ago

Relevant: https://github.com/wbthomason/ironkernel https://github.com/wbthomason/ironkernel

cwzwarich 11y ago

As far as I can tell, Rust OS projects generally use gratuitous amounts of unsafe code and are not substantially different than if they were written in C. I could just be looking in the wrong places. Are there any that take advantage of Rust's type system to provide real guarantees?

Rusky 11y ago
That may just be the impression given by tutorials, which spend most of their time dealing with the hardware. In a real OS, you'd wrap that up in safe interfaces and then the core of things like scheduling, file systems, etc. could be in a safe layer on top of the unsafe drivers.
- cwzwarich 11y ago
  But has anyone actually done that? Can you even express those as safe interfaces in Rust?
  - Jweb_Guru 11y ago
    IMO, the answers to those questions are "no" and "yes" respectively. Redox in particular seems like it has way more unsafe code than it actually has to (though it seems to have gotten a bit better very recently).
  - chadaustin 11y ago
    It's the same thing with Haskell, or any other "real" system that, at some level, has to interface with low-level primitives. The platform gives you a pile of unsafe, low-level primitives ( https://hackage.haskell.org/package/ghc-prim-0.4.0.0/docs/GHC-Prim.html https://hackage.haskell.org/package/ghc-prim-0.4.0.0/docs/GH... ) on top of which you (or a library writer) can provide safe interfaces, e.g. https://hackage.haskell.org/package/buffer-builder https://hackage.haskell.org/package/buffer-builder
    - MaxGabriel 11y ago
      The unsafe low-level stuff gives rise to some great function names like `reallyUnsafePtrEquality` and `accursedUnutterablePerformIO` https://github.com/haskell/bytestring/blob/dd3c07d115840d13482426a0084a39201eb6b6d4/Data/ByteString/Internal.hs#L515-L546 https://github.com/haskell/bytestring/blob/dd3c07d115840d134...
kibwen 11y ago
The OP talks about this in the most recent post: "In the previous post we switched from assembly to Rust, a systems programming language that provides great safety. But so far we are using unsafe features like raw pointers whenever we want to print to screen. In this post we will create a Rust module that provides a safe and easy-to-use interface for the VGA text buffer."
- deleted 11y ago
  [deleted]
steveklabnik 11y ago
I expect a lot of this to be like this at first: https://www.reddit.com/r/rust/comments/3mw67c/i_am_jackpot51_the_writer_of_redox_a_rust/cvizko4?context=2 https://www.reddit.com/r/rust/comments/3mw67c/i_am_jackpot51... There's a period of writing only all the usual stuff that you've done before, then slowly discovering what kinds of abstractions you can put over it, and what kinds of stuff needs to remain super-low.
ntrepid8 11y ago
There are times that you have to do "unsafe" things when interacting directly with hardware. That's not to say one shouldn't attempt to limit the use of "unsafe" to use cases that absolutely require it.

steveklabnik 11y ago

I've read through what was here, and last night, actually built the first post's code. I really like the depth and style of this particular posts, it really hits a sweet spot.

bulutsuzku 11y ago

What's the value and novelty of writing an OS in Rust?

steveklabnik 11y ago
> value Well, Rust is a systems language, and so it should be a good fit for OS development. We're still working on bits of it, but it's a stated goal of the language, so testing that out is valuable. > Novelty Well, Rust is still a fairly young language, so there aren't a ton of people doing things with it yet, relatively speaking. And for OS dev, which is kind of a niche subject anyway (as much as I love it), there's naturally even less. So it's basically novel by definition.
- bulutsuzku 11y ago
  > Well, Rust is a systems language, and so it should be a good fit for OS development. We're still working on bits of it, but it's a stated goal of the language, so testing that out is valuable. My questions was not well formulated. Let me rephrase it: C is also a system language and there are plenty of OS libraries written in C. C++ could be seen as another system language. Even the syntax of Rust is similar to C/C++ according to Wikipedia article. So, what's the advantage of Rust over other systems language? Better support for autonomous systems? Reflective model? Do you have a paper? It is a research project? Do you plan to replace Linux or something like that?
  - Zarathustra30 11y ago
    (Safe) Rust provides some nice guarantees. It (should be) impossible to have use-after-free, buffer overruns, race conditions, etc. in 100% Safe Rust. A pure Rust OS could provide a safe interface to build safe programs. While mostly a novelty, an OS capable of executing untrusted code risk-free could be a powerful tool indeed.
  - steveklabnik 11y ago
    > what's the advantage of Rust over other systems language? Memory safety without garbage collection is Rust's core feature. > Do you have a paper? It is a research project? I'm not the author.

monocasa 11y ago

No -mno-redzone?

Animats 11y ago

I'd like to see someone re-implement the QNX real-time microkernel in Rust. That would be useful. We need a QNX-like OS for embedded devices. Linux is really the wrong tool for the job. Too much extra stuff which allows attacks.

walterbell 11y ago
Could RIM open-source QNX, if the Blackberry Android device is successful?
- protomyth 11y ago
  I doubt they would give up that money stream in their current condition (automobiles for one market).
- jacquesm 11y ago
  I asked, both before QS sold it to RIM and after the deal, in both cases I didn't even get an answer (and I would have been in a position to put up a substantial chunk of money in order to get a dual license deal in place). Real pity, but maybe it will still happen. QnX is one of the most elegant OSs out there and having a public domain or GPL'd version of it would be a great thing.
- Animats 11y ago
  I'm hoping they open source QNX after the Blackberry disappears. The Blackberry is a dead end, but we really need something solid for embedded work.
nickpsecurity 11y ago
I agree. That or at least MINIX 3's core components as there's already source available. Plus, that would likely get extended by all the people building servers and stuff. Be two versions like with Linux.
xj9 11y ago
What about seL4[1]? It isn't real-time, but it is small, performant, and formally verified. [1]: http://sel4.systems http://sel4.systems

codepie 11y ago

I was looking for something similar in C. Most of the resources I found (eg : os dev-wiki) do not cover the implementation details in such depth. Can anyone give few pointers?

devit 11y ago

If anyone is considering working on an OS in Rust, they could perhaps consider writing a small hypervisor that could replace Xen, Nova and similar hypervisors. This provides the same low-level challenges of writing a kernel, but it's far easier to get practically usable software than attempting to replace Linux and would actually be useful in practice. At the moment, the only way to make a sandbox that has a chance of being perfectly secure (i.e. no security holes, ever) while still running all kinds of useful software is to use VMs to sandbox Linux/Windows kernels, and here the hypervisor is of course the weak point, and current usable hypervisors are written in C or C++.

steveklabnik 11y ago
https://internals.rust-lang.org/t/unikernels-in-rust/2494 https://internals.rust-lang.org/t/unikernels-in-rust/2494
- devit 11y ago
  This seems to be about using Rust for the kernel running inside the virtual machines, not for the hypervisor itself, which is what I was talking about.