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!
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.
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!
vinc 110 days ago [-]
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.
codethief 110 days ago [-]
Re [1]: No TLS? :(
vinc 110 days ago [-]
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!
bigstrat2003 110 days ago [-]
There's nothing sensitive, therefore there is no reason to use TLS.
appendix-rock 110 days ago [-]
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.
tcfhgj 110 days ago [-]
You don't need encryption to prevent something shoved into it without detection
aaronmdjones 110 days ago [-]
No, but you do need authentication, and TLS does both.
XorNot 110 days ago [-]
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.
0xFF0123 110 days ago [-]
Other than the build and download links?
flatfuzz 110 days ago [-]
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.
vinc 110 days ago [-]
Thanks! If you try again and still have it don't hesitate to create an issue on GitHub and I'll look into it!
jayd3e 110 days ago [-]
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.
nailer 110 days ago [-]
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.
jamesmunns 110 days ago [-]
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.
junon 110 days ago [-]
Working on one over at github.com/oro-os but haven't proven efficacy of the design yet, so haven't announced it. Just if you want something to follow.
lasiotus 110 days ago [-]
Motor OS
Levitating 110 days ago [-]
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.
ok_dad 110 days ago [-]
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!
ramon156 110 days ago [-]
This source got me started with Rust back in 2021, and I'm very grateful that this exists.
jamesmunns 110 days ago [-]
Phil's writing on OS development is always a wonderful read.
(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.
Is this project about writing a kernel or an entire OS including graphical shell, etc.?
assanineass 110 days ago [-]
Jokingly thought it was another one of those “I rewrote it in Rust” moments. Cool post
3rdworldeng 110 days ago [-]
Nice job !
110 days ago [-]
110 days ago [-]
110 days ago [-]
110 days ago [-]
110 days ago [-]
110 days ago [-]
110 days ago [-]
KingOfLechia 110 days ago [-]
[dead]
segasuperstar 110 days ago [-]
You lost me at branch per post
bigstrat2003 110 days ago [-]
This is just the source code for the blog. It is readable in normal fashion at os.phil-opp.com.
gxt 110 days ago [-]
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.
nineteen999 110 days ago [-]
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.
xiaodai 110 days ago [-]
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
recursivecaveat 110 days ago [-]
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.
polyaniline 110 days ago [-]
I don't think that's something to be pedantic about. Even so, cranelift exists.
xyst 110 days ago [-]
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.
aaronmdjones 110 days ago [-]
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.
sureglymop 110 days ago [-]
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.
Rendered at 01:49:46 GMT+0000 (Coordinated Universal Time) with Vercel.
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
[1]: http://moros.cc
[2]: https://github.com/vinc/moros
[3]: https://wiki.osdev.org
- 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!
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.
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!
“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.
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.
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.
[0]: https://screenrant.com/ryan-reynolds-but-why-gif-harold-kuma...
Sidenote on "MOROS" - cool project/page!
https://osblog.stephenmarz.com/
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.
Most, if not all, vulnerabilities are related to lack of memory safety.
Well, guess there’s always the application/user space.
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.