21 ms·
Moss: a Rust Linux-compatible kernel in 26,000 lines of code
- hexagonal-sun 10mo agoHello! For the past 8 months, or so, I've been working on a project to create a Linux-compatible kernel in nothing but Rust and assembly. I finally feel as though I have enough written that I'd like to share it with the community! I'm currently targeting the ARM64 arch, as that's what I know best. It runs on qemu as well as various dev boards that I've got lying around (pi4, jetson nano, AMD Kria, imx8, etc). It has enough implemented to run most BusyBox commands on the console. Major things that are missing at the moment: decent FS driver (only fat32 RO at the moment), and no networking support. More info is on the github readme. https://github.com/hexagonal-sun/moss https://github.com/hexagonal-sun/moss Comments & contributions welcome!
- bramadityaw 10mo agoshouldn't this be a ShowHN?
- Rochus 10mo agoCool project, congrats. I like the idea with libkernel which makes debugging easier before going to "hardware". It's like the advantages of a microkernel achievable in a monolithic kernel, without the huge size of LKL, UML or rump kernels. Isn't Rust async/awat depending on runtime and OS features? Using it in the kernel sounds like an complex bootstrap challenge.
- kaoD 10mo agoRust's async-await is executor-agnostic and runs entirely in userspace. It is just syntax-sugar for Futures as state machines, where "await points" are your states. An executor (I think this is what you meant by runtime) is nothing special and doesn't need to be tied to OS features at all. You can poll and run futures in a single thread. It's just something that holds and runs futures to completion. Not very different from an OS scheduler, except it is cooperative instead of preemptive. It's a drop in the ocean of kernel complexities.
- rcxdude 10mo agoYeah, for example embassy-rs is an RTOS that uses rust async on tiny microcontrollers. You can hook task execution up to a main loop and interrupts pretty easily. (And RTIC is another, more radically simple version which also uses async but just runs everything in interrupt handlers and uses the interrupt priority and nesting capability of most micros to do the scheduling)
- Rochus 10mo agoInteresting references, thanks. Moss seems to be doing the same thing as Embassy.
- boguscoder 10mo agoSorry for nit but embassy is not a RTOS (or any OS), its a framework
- rcxdude 10mo agoThe difference becomes a bit murky at this level. For example embassy comes with a lot more things I would consider OS-related than FreeRTOS does.
- Rochus 10mo agoOk, I see. I spent a lot of time with .Net VMs, where you cannot simply separate await from the heavy machinery that runs it. I now understand that in a kernel context, you don't need a complex runtime like Tokio. But you still need a way to wake the executor up when hardware does something (like a disk interrupt); but this indeed is not a runtime dependency. EDIT: just found this source which explains in detail how it works: https://os.phil-opp.com/async-await/ https://os.phil-opp.com/async-await/
- vlovich123 10mo agoThere’s got to be some complexity within the executor implementation though I imagine as I believe you have to suspend and resume execution of the calling thread which can be non-trivial.
- hexagonal-sun 10mo agoThis has been a real help! The ability to easily verify the behavior of certain pieces of code (especially mem management code) must have saved me hours of debugging. Regarding the async code, sibling posts have addressed this. However, if you want to get a taste of how this is implemented in Moss look at src/sched/waker.rs, src/sched/mod.rs, src/sched/uspc_ret.rs. These files cover the majority of the executor implementation.
- IshKebab 10mo agoImpressive work! Do you have any goals, other than learning and having fun? Also how does it's design compare with Redox and Asterinas?
- cies 10mo agoAre the collaborations possible/foreseeable?
- F3nd0 10mo agoCongratulations on the progress. If I may ask, I'm curious what considerations have motivated your choice of licence (especially since pushover licences seem extremely popular with all kinds of different Rust projects, as opposed to copyleft).
- dymk 10mo agoI’ve pretty much only seen MIT and to a lesser extent GPL on most open source projects. Would you expect a different license?
- tingletech 10mo agoWhat is a "pushover" license?
- WD-42 10mo agoIt’s a play on “permissive” license.
- nmz 10mo agoA derogatory term for copyfree licenses
- SAI_Peregrinus 10mo agoPermissive license + complaining when companies don't contribute back from their forks.
- cryptonector 10mo agoI've worked on plenty of BSD and MIT licensed code. I've never complained about lack of contribution. You're projecting. Please stop.
- SAI_Peregrinus 10mo agoI'm not the person who used the term "pushover license". I just explained why some people use the term.
- andrewl-hn 10mo ago> no networking support Would something like Smoltcp be of help here? https://github.com/smoltcp-rs/smoltcp https://github.com/smoltcp-rs/smoltcp Great project either way! How do you decide which sys calls to work on? Is is based on what the user space binaries demand?
- hexagonal-sun 10mo agoYip, I panic whenever I encounter a syscall that I can't handle and that prompts me to implement it. Yeah, I was thinking of integrating that at some point. They've done a really nice job of keeping it no_std-friendly.
- whitequark_ 10mo agoOriginal author of smoltcp here! I couldn't have imagined how much of a cornerstone of the Rust ecosystem it would become. Very excited to see it get used like this, and yeah, #![no_std] use cases were the original and primary motivation to build the stack in the first place.
- phkahler 10mo agoLove the MIT license. If this were further along we could use this as the foundation of our business without having to "give back" device drivers and other things.
- cryptonector 10mo agoI take this as an oblique critique of TFA's choice of license. What's it to you? Why must we all use the GPL always in order to satisfy busybodies?
- phkahler 10mo ago>> I take this as an oblique critique of TFA's choice of license. What's it to you? Why must we all use the GPL always in order to satisfy busybodies? Thank you for reading it correctly. I originally had a </sarcasm> to make sure nobody thought I liked the license choice. What's it to me? Well someone posted it to HN here so we could comment on it, so I did. I think the MIT license has its place, but IMHO it does not belong on an OS like that. Reason is indicated in my original comment.
- cryptonector 10mo agoGlad the author disagrees with you. So do I.
- bfrog 10mo agoThis should be the sort of red flag to take note of. There’s an LLVM fork for every esoteric architecture now and this sort of thinking will lead to never being able to run your own software on your own hardware again. A reversion to the dark ages of computing.
- 533474 10mo agoGreat, an MIT license to accelerate planned obsolescence and hardware junk. Truly a brilliant move
- Onavo 10mo agoHow does android compatibility look? Can this be compiled to WebAssembly and run in browser?
- sheepscreek 10mo agoVery impressive and I like how accessible the codebase is. Plus safe Rust makes it very hard to shoot yourself on the foot, which is good for outside contributions. Great work! After you got the busybox shell running, how long did it take to add vim support? What challenges did you face? Did you cross-compile it?
- fortran77 10mo agoBUt it's not "safe" because it's mixed with assembly
- scottlamb 10mo agoThere are no programs written in 100% safe Rust—the std library is written with unsafe as needed. But typically the majority of lines in the program—sometimes even all outside std or some well-audited foundational creates—are safe. Those lines can not directly cause any unsoundness, which has tremendous value.
- loeg 10mo agoThis has been discussed ad nauseam and this adds nothing new. There's value in the memory safety for the majority of the code even if there are some escape valves ("unsafe" keyword, assembly).
- kennykartman 10mo agoAh, nice. I wish this was licensed GPL instead of MIT. I'll avoid contribution, sorry!
- drnick1 10mo agoWhy Rust and not C however, given that is meant to be Linux-compatible?
- maxloh 10mo agoIn what extent is this compatible with Linux? Could I swap Ubuntu's or Android's kernel with this, while keeping those OSes bootable?
- tuyiown 10mo agoWhile it's very legitimate question, the answer is between the lines in the README, and it mostly means that there is a user space binary compatibility for everything that is implemented. It might seem obscure, but syscalls to get access to kernel requires a tight integration on compilation and linking. So this is their approach and this is where the compatibility really means something : since you can cross compile on another machine, they don't need the full toolchain right away. Just compile your code on a linux machine, and run it there. You're at the mercy of all missing kernel API implementations, but it looks like a very good strategy if you aim is to code a kernel, as you only have to focus on actual syscalls implementation without getting distracted by toolchain.
- HackerThemAll 10mo agoAt this stage you'd need to contribute to it, not treat it as a finished product.
- marty-oehme 10mo agoVery cool project! I do have to admit - looking far, far into the future - I am a bit scared of a Linux ABI-compatible kernel with an MIT license.
- stingraycharles 10mo agoWhy?
- p0w3n3d 10mo agobecause otherwise big tech companies will take it and modify and release hardware with it without releasing patches etc? Basically being selfish and greedy?
- sneak 10mo agoIt is neither selfish nor greedy to accept and use a gift freely given to you. Receiving a gift does not confer obligations on the recipient.
- Hendrikto 10mo agoTrue, but you would probably still be pissed if somebody took your gift and hit you over the head with it.
- mordae 10mo agoIt does. There is an implied expectation that the recipient will will not be selfish. They can pay it back, pay it forward, possibly later when they can afford it, etc., but they are expected not to be selfish and also give someone something eventually.
- lumb63 10mo agoGifts definitely confer obligations on the recipient. You can experience this firsthand: take the next gift a loved one gives you, and then sell it, and let them know. Please report back on how you selling their gift impacts your relationship with that person. People can license their code however they please, but comparing open source software to a gift is not an argument for permissive licenses.
- meisel 10mo agoReally neat. Do you have any specific long term goals for it? Eg, provide an OS distro (using Linux drivers?) to provide memory safety for security-critical contexts? Also, are there any opportunities to make this kernel significantly faster than Linux’s?
- hexagonal-sun 10mo agoEventually, It'd be amazing to use Moss as my daily driver OS. That means targeting the specific hardware that I have, but in doing so, I hope to build up enough of the abstractions to allow easier porting of hardware. A more concrete mid-term goal is for it to be 'self-hosting'. By that I mean you could edit the code, download dependencies and compile the kernel from within Moss.
- meisel 10mo agoAre you interested in beating Linux performance-wise? Eg: - Moving away from the too-small 4kb default page size (while having a good strategy for dealing with fragmentation)? - Make it easy to minimize/track interrupts on a core, for low-latency contexts
- nikanj 10mo agoJust a hobby, won’t be big and professional like Linux?
- noumenon1111 10mo agoI see what you did there, fair human.
- hexagonal-sun 10mo ago;-)
- tony-john12 10mo ago[dead]
- cedws 10mo agoI don't know much about Linux internals - how difficult would it be to reimplement KVM? I'm guessing a big undertaking.
- erichocean 10mo agoThis plus using Fil-C for the BusyBox commands is a nice combination (once Fil-C supports ARM64).
- forgotpwd16 10mo agoOr... rewrite BusyBox in Rust. (And most certainly such a project already exists.)
- estebank 10mo agoIsn't that https://uutils.github.io/ https://uutils.github.io/?
- gslepak 10mo agoHow does this compare to https://github.com/nuta/kerla https://github.com/nuta/kerla ?
- scns 10mo ago> This software is no longer maintained.
- cryptonector 10mo agoThe question is still relevant.
- leo_e 10mo agoThe choice of MIT for a kernel feels like setting up the project to be cannibalized rather than contributed to. We've seen this movie before with the BSDs. Hardware vendors love permissive licenses because they can fork, add their proprietary HAL/drivers, and ship a closed binary blob without ever upstreaming a single fix. Linux won specifically because the GPL forced the "greedy" actors to collaborate. In the embedded space, an MIT kernel is just free R&D for a vendor who will lock the bootloader anyway.
- KerrAvon 10mo agoNot meaning to single you out specifically, but this entire discussion — all of this license gatekeeping is ridiculous. This is a very cool project, but if the license ruins it for you, there are zillions of open source GPL3 kernels. I mean, this is not different from bitching about someone writing their custom kernel in C++ instead of Rust, or Zig. It’s not your project! Let people do their own thing! MIT is a perfectly fine license; maybe the lack of zealotry associated with it would even be a positive thing for whatever community might be built around this eventually, if the author is even interested in having other contributions.
- LeFantome 10mo agoNot sure why am getting in the middle of this but I need to point out that you are not even correct for Linux. Linux rather famously has avoided the GPL3 and is distributed under a modified GPL2. This license allows binary blob modules. We are all very familiar with this. As a result, the kernel that matches your description above that ships in the highest volume is Linux by a massive margin. Can you run a fully open source Linux kernel on your Android phone? Probably not. You do not have the drivers. You may not pass the security checks. Do companies like Broadcomm “collaborate” on Linux even in the PC or Mac space? Not really. On the other side, companies that use FreeBSD do actually contribute a lot of code. This includes Netflix most famously but even Sony gives back. The vast majority of vendors that use Linux embedded never contribute a single line of code (like 80% or more at least - maybe 98%). Very few of them even make the kernel code they use available. I worked in video surveillance where every video recorder and camera in the entire industry is Linux based at this point. Almost none of them distribute source code. But even the story behind the GPL or not is wrong in the real world. You get great industry players like Valve that contribute a lot of code. And guess what, a lot of that code is licensed permissively. And a lot of other companies continue to Mesa, Wayland, Xorg, pipewire, and other parts of the stack that are permissively licensed. The level of contribution has nothing to do with the GPL. How about other important projects? There are more big companies contributing to LLVM/Clang (permissive) than there are to GCC (GPL). In fact, the GPL often discourages collaboration. Apple is a great example of a company that will not contribute to even the GPL projects that they rely on. But they do contribute a fair bit of Open Source code permisssively. And they are not even one of the “good guys” in Open Source. This comment is pure ideological mythology.
- randyfox 10mo ago[flagged]
- Towaway69 10mo agoJust shows how little we have achieved since then. In both hardware architecture and software based on that hardware.
- CharlesW 10mo agoI understand that you've only been on HN for 7 days, but please don't do this. It's gross.
- eterps 10mo agoWait until they get to the networking layer; you're going to hate what Vint Cerf did in the 70s :)
- netbsdusers 10mo agoJust about everything of worth in operating systems (and in software in general) was already invented in those decades.
- theoldgreybeard 10mo ago> MIT license What have you done?!
- nektro 10mo agovery impressive! i think this is a far better approach to bringing rust's advantages to linux rather than trying to squeeze rust into the existing linux kernel. best of luck!