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.
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.
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!
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.
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.
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.
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.
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.
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!
(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.
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.
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.
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.
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