8 ms·
Moss: a Rust Linux-compatible kernel in 26,000 lines of code
- hexagonal-sun 1y 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 1y agoshouldn't this be a ShowHN?
- Rochus 1y 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 1y 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 1y 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 1y agoInteresting references, thanks. Moss seems to be doing the same thing as Embassy.
- boguscoder 1y agoSorry for nit but embassy is not a RTOS (or any OS), its a framework
- rcxdude 1y 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 1y 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 1y 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 1y 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 1y 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 1y agoAre the collaborations possible/foreseeable?
- F3nd0 1y 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 1y 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 1y agoWhat is a "pushover" license?
- WD-42 1y agoIt’s a play on “permissive” license.
- nmz 1y agoA derogatory term for copyfree licenses
- SAI_Peregrinus 1y agoPermissive license + complaining when companies don't contribute back from their forks.
- cryptonector 1y 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 1y agoI'm not the person who used the term "pushover license". I just explained why some people use the term.
- andrewl-hn 1y 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 1y 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_ 1y 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 1y 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.
- bfrog 1y 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.
- imiric 1y agoSeriously. To the author: kudos for the interesting project, but please strongly consider a copyleft license moving forward.
- cryptonector 1y agoSeriously: stop it. It's none of your business what the author's license choice is. You don't know what the author is trying to accomplish by their choice of license. It could be a mindless choice, or it could be an informed choice. Perhaps the author wants to build interest and later plans to switch licenses (it's not like others are likely to fork _and_ do an excellent job of evolving and maintaining the fork). Perhaps the author is looking to get hired. Perhaps the author believes that BSD/MIT licensing is more free than the GPL. You really don't need to be shaming the author for not making the choice you made.
- 533474 1y agoGreat, an MIT license to accelerate planned obsolescence and hardware junk. Truly a brilliant move
- surajrmal 1y agoLinux magically solves this problem how? GPL isn't magic. It doesn't compel contributing upstream. And half of modern driver stacks live in userspace anyways.
- Onavo 1y agoHow does android compatibility look? Can this be compiled to WebAssembly and run in browser?
- sheepscreek 1y 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 1y agoBUt it's not "safe" because it's mixed with assembly
- scottlamb 1y 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 1y 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 1y agoAh, nice. I wish this was licensed GPL instead of MIT. I'll avoid contribution, sorry!
- maxloh 1y 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 1y 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 1y agoAt this stage you'd need to contribute to it, not treat it as a finished product.
- marty-oehme 1y 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 1y agoWhy?
- p0w3n3d 1y 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 1y 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 1y agoTrue, but you would probably still be pissed if somebody took your gift and hit you over the head with it.
- mordae 1y 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 1y 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 1y 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 1y 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 1y 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 1y agoJust a hobby, won’t be big and professional like Linux?
- hexagonal-sun 1y ago;-)
- noumenon1111 1y agoI see what you did there, fair human.
- tony-john12 1y ago[dead]
- cedws 1y agoI don't know much about Linux internals - how difficult would it be to reimplement KVM? I'm guessing a big undertaking.
- erichocean 1y agoThis plus using Fil-C for the BusyBox commands is a nice combination (once Fil-C supports ARM64).
- forgotpwd16 1y agoOr... rewrite BusyBox in Rust. (And most certainly such a project already exists.)
- estebank 1y agoIsn't that https://uutils.github.io/ https://uutils.github.io/?
- gslepak 1y agoHow does this compare to https://github.com/nuta/kerla https://github.com/nuta/kerla ?
- scns 1y ago> This software is no longer maintained.
- cryptonector 1y agoThe question is still relevant.
- leo_e 1y 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 1y 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 1y 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 1y ago[flagged]
- Towaway69 1y agoJust shows how little we have achieved since then. In both hardware architecture and software based on that hardware.
- CharlesW 1y agoI understand that you've only been on HN for 7 days, but please don't do this. It's gross.
- eterps 1y agoWait until they get to the networking layer; you're going to hate what Vint Cerf did in the 70s :)
- netbsdusers 1y agoJust about everything of worth in operating systems (and in software in general) was already invented in those decades.
- theoldgreybeard 1y ago> MIT license What have you done?!
- drnick1 1y agoWhy Rust and not C however, given that is meant to be Linux-compatible?
- nektro 1y 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!