Writing an OS in Rust(github.com)
github.com
Writing an OS in Rust
https://github.com/phil-opp/blog_os
48 comments
He's giving a talk at next month's GOSIM conference.
https://china2024.gosim.org/speakers#philipp-oppermann
It would be nice to be able to talk to him in person.
(not a professional coder) "writing an X on Y" brings in my mind the meme of Ryan Reynolds "But why?" [0]. If it is for training purposes, then by all means, go nuts!! The more one codes, the better.
[0]: https://screenrant.com/ryan-reynolds-but-why-gif-harold-kuma...
Sidenote on "MOROS" - cool project/page!
[0]: https://screenrant.com/ryan-reynolds-but-why-gif-harold-kuma...
Sidenote on "MOROS" - cool project/page!
Is this project about writing a kernel or an entire OS including graphical shell, etc.?
We shouldn't write an OS in rust. We should create a data platform on which we can run DML/DDL with an SSMS++ automatic frontend.
We really should, if for no other reason than to silence those who think that every Linux/BSD box connected to a network is being rooted every 5 mins because they are written in C.
That's if they ever get around to bringing such a Rust-based OS up to enterprise level rather than spouting off about this belief on HN all day every day.
That's if they ever get around to bringing such a Rust-based OS up to enterprise level rather than spouting off about this belief on HN all day every day.
Makes sense but what if there are bugs in llvm? U r still exposed. So need a rust version of llvm and then rust can be self hosted
It doesn't really matter whether the compiler is memory safe. What you run is the result of the compiler. A perfectly memory safe compiler can have a correctness bug that generates unsafe assembly from a safe rust program.
I don't think that's something to be pedantic about. Even so, cranelift exists.
This source got me started with Rust back in 2021, and I'm very grateful that this exists.
Nice job !
Phil's writing on OS development is always a wonderful read.
I just came back from Rustconf and it seems there’s about five or so major OS releases, particularly focused around real time. Not all are open source though.
Tock-OS, Oxid-OS (the safety version of Tock-OS, like freertos/safertos), and Hubris (from Oxide Computers) are the main three RTOSs, Embassy and RTIC are common frameworks (but not classic RTOSs) used for scheduling and resource management on bare metal systems. There are some more niche or non-public ones as well.
For more classic OSs (not real time), Redox is the main one, as well as a lot of research/experimental/teaching ones, including the Blog OS from this guide/submission.
For more classic OSs (not real time), Redox is the main one, as well as a lot of research/experimental/teaching ones, including the Blog OS from this guide/submission.
You lost me at branch per post
This is just the source code for the blog. It is readable in normal fashion at os.phil-opp.com.
I started working on MOROS[1][2] after completing the tutorial 5 years ago, and I cannot recommend it enough for anyone interested in Rust and osdev. Phil put a lot of work into it, and it shows! The project covers a lot, and after that there's the osdev wiki[3] to keep going.
[1]: http://moros.cc
[2]: https://github.com/vinc/moros
[3]: https://wiki.osdev.org
[1]: http://moros.cc
[2]: https://github.com/vinc/moros
[3]: https://wiki.osdev.org
Whoa, looks very cool.
So far, my favourite project is xv6, because:
- codebase is reasonably compact, can be understood in a few weeks
- can be built with standard GCC provided by package manager, no need to built a custom GCC from source
- has user space, too
Seems like your project also have those points checked. Bookmarked!
- codebase is reasonably compact, can be understood in a few weeks
- can be built with standard GCC provided by package manager, no need to built a custom GCC from source
- has user space, too
Seems like your project also have those points checked. Bookmarked!
Thanks! Compared to xv6, you will find some important pieces missing. For example, there's no multiprocessor support and no scheduler, only one process can run at any time.
I should also note that user space programs can do memory allocation via syscall, but I currently have an issue with the kernel memory that I probably need to remap higher in memory. So, most commands inside the OS are still executed from kernel space, although they use syscalls and everything as if they were user space programs. I'm having a lot of fun creating device files inspired by Plan9 to communicate with the kernel.
There's a lot of work yet to arrive at something that feels truly complete as an educational OS, but I'm hoping to get there eventually. I really like this project because I'm learning along the way all the time!
Your first point is one of my main goals: I want the whole OS, including user space programs, to fit inside one brain. I'm always trying to find ways to keep complexity low without compromising too much on performance.
I should also note that user space programs can do memory allocation via syscall, but I currently have an issue with the kernel memory that I probably need to remap higher in memory. So, most commands inside the OS are still executed from kernel space, although they use syscalls and everything as if they were user space programs. I'm having a lot of fun creating device files inspired by Plan9 to communicate with the kernel.
There's a lot of work yet to arrive at something that feels truly complete as an educational OS, but I'm hoping to get there eventually. I really like this project because I'm learning along the way all the time!
Your first point is one of my main goals: I want the whole OS, including user space programs, to fit inside one brain. I'm always trying to find ways to keep complexity low without compromising too much on performance.
Re [1]: No TLS? :(
Good question, there's no TLS support inside MOROS so its website must be available over HTTP, especially when I self-host it. That's not the case currently so I could also have HTTPS but I'm using Dokku and last time I tried the Let's Encrypt plugin would redirect HTTP to HTTPS automatically, which is annoying.
Edit: I set up CloudFlare in front of the server and there's now a working HTTPS version along with the HTTP version accessible from inside MOROS. This should also work when I'll use again the web server inside the OS. Thanks for prompting me to look into it!
Edit: I set up CloudFlare in front of the server and there's now a working HTTPS version along with the HTTP version accessible from inside MOROS. This should also work when I'll use again the web server inside the OS. Thanks for prompting me to look into it!
There's nothing sensitive, therefore there is no reason to use TLS.
No! Stop! Why won’t this one die!
MITMing is a two way street. I could intercept sensitive data, or I could shove something in that tricks the user (phishing, etc), exploits the user agent, and more!.
“You only need encryption for the sensitive stuff” is what we did, poorly, in the late ‘00s / early ‘10s, and it was rightfully proven to be a bad idea. There’s a reason why browsers treat HTTP the way they currently do, and it isn’t because they’ve been co-opted by Big Certificate Authority.
EDIT: and as the other commenter says, there are download links.
“You only need encryption for the sensitive stuff” is what we did, poorly, in the late ‘00s / early ‘10s, and it was rightfully proven to be a bad idea. There’s a reason why browsers treat HTTP the way they currently do, and it isn’t because they’ve been co-opted by Big Certificate Authority.
EDIT: and as the other commenter says, there are download links.
You don't need encryption to prevent something shoved into it without detection
No, but you do need authentication, and TLS does both.
No but we have no "httpv" protocol scheme to require signatures but not encryption
Which IMO has been a huge mistake since breaking caching proxies for networks because we want to prove authenticity and have to do secrecy as well has been quite silly.
Which IMO has been a huge mistake since breaking caching proxies for networks because we want to prove authenticity and have to do secrecy as well has been quite silly.
Other than the build and download links?
im subscribed to your RSS feed since a while back, MOROS seems like a really cool project! sadly haven’t been able to try it since it wouldn’t start on QEMU for some reason, though i think that’s an issue on my side rather than the OS itself.
Thanks! If you try again and still have it don't hesitate to create an issue on GitHub and I'll look into it!
I especially recommend the original edition of these posts. For me the current edition does way too much hand holding, taking care of the entire bootloading process with a specialized crate.
I like that there’s a way to skip all that boot loading stuff, your comment made me want to actually try this. I want to build a fun little OS for myself but I hate the part where you have to do magical incantations to get to a decent machine state to do stuff in. Not that it’s a bad thing, everybody likes different stuff. Thanks for mentioning this!
The pool of operating system penetration testers will be absolutely devastated if a rust OS becomes mainstream.
Most, if not all, vulnerabilities are related to lack of memory safety.
Well, guess there’s always the application/user space.
Most, if not all, vulnerabilities are related to lack of memory safety.
Well, guess there’s always the application/user space.
Definitely not all. Our current best estimates put the figure of (amount of security vulnerabilities due to memory safety errors) / (total amount of security vulnerabilities) at 50-70%.
People will still be making logic errors & authentication errors (e.g. insecure direct object reference) in Rust code for decades to come, to name just a few. Why? Because people make mistakes.
People will still be making logic errors & authentication errors (e.g. insecure direct object reference) in Rust code for decades to come, to name just a few. Why? Because people make mistakes.
Regarding your last sentence, if they move on to AI imposed security vulnerabilities there is probably a lot of bread and butter to be made there.
Another good resource is Making a RISC-V OS using Rust
https://osblog.stephenmarz.com/
https://osblog.stephenmarz.com/
Funny, I found this today after doing a deep dive on Rust and OS development. I was in awe at the quality of this content. You come out of it not only learning so much about the history and design of operating systems, but you start to pick up elements of Rust as well. Phil did an incredible job on this.
[deleted]
[deleted]
Jokingly thought it was another one of those “I rewrote it in Rust” moments. Cool post
[deleted]
[deleted]
I completed the second edition years ago and found it illuminating. It's very well done! The explanations pertaining to OS dev are nice but it was also a useful artifact for learning more Rust after having gone through the Rust book. The author had a good grasp of the idiom of the language, so seeing how he expressed certain things in code vis a vis how I would have done was educational. The blog's explanation of how futures are implemented in Rust was especially a highlight[0], and I think it's the best I've seen on that topic anywhere.
I hope Phil will find the inspiration to come back and work on the EFI-based third edition again. AFAICT, (based on commits to the git branches) that has stalled. I was a GitHub sponsor for about a year until my CC expired and was always bummed to see it left out of the "This Month In Rust OSDev" posts.
Anyway, the second edition is still a great way to spend a weekend's dev time and I appreciate all the hard work that clearly went into it. Thanks Phil!
[0]: https://os.phil-opp.com/async-await/#async-await-in-rust
I hope Phil will find the inspiration to come back and work on the EFI-based third edition again. AFAICT, (based on commits to the git branches) that has stalled. I was a GitHub sponsor for about a year until my CC expired and was always bummed to see it left out of the "This Month In Rust OSDev" posts.
Anyway, the second edition is still a great way to spend a weekend's dev time and I appreciate all the hard work that clearly went into it. Thanks Phil!
[0]: https://os.phil-opp.com/async-await/#async-await-in-rust
[deleted]
[deleted]
[deleted]
https://harvey-os.org/ (Retired)
The team now works on this: https://github.com/r9os/r9