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.
Congratulations 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).
Cool 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.
Rust'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.
This 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.
Love 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.
This 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.
MIT licensed code is a gift. A gift indeed doesn't require the recipient to give back anything related to the gift.
A "gift" requiring GPL-like conditions isn't really a gift in the common sense. It's more like a contractual agreement with something provided and specific, non-negotiable obligations. They're giving while also asserting control over others' lives, hoping for a specific outcome. That's not just a gift.
People doing MIT license are often generous enough where the code is a gift to everyone. They don't try to control their lives or societal outcomes with extra obligations. They're just giving. So, I'm grateful to them for both OSS and business adaptations of their gifts.
Somewhere there is a dark timeline where the BSDs won, there are 50 commercial and open source variants all with their own kernel and userland. The only promise of interoperability is in extremely ossified layers like POSIX. There is, however, something terrible gathering its strength. A colossus. The great Shade that will eat the net. In boardroom meetings across the land, CTOs whisper its name and tremble... "OS/2."
because otherwise big tech companies will take it and modify and release hardware with it without releasing patches etc? Basically being selfish and greedy?
Because unlike most other functionality, you generally need hw specs or cooperation to write drivers (see Nvidia GSP).
Anyone can write Photoshop (provided reasonable resources). The problem is going to be proprietary file format and compatibility with the ecosystem. It's same with hardware, except several orders of magnitude worse.
Really 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?
Eventually, 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.
While 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.
Hello!
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
Comments & contributions welcome!
Congratulations 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).
I’ve pretty much only seen MIT and to a lesser extent GPL on most open source projects. Would you expect a different license?
What is a "pushover" license?
> no networking support
Would something like Smoltcp be of help here? 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?
Yip, 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.
Cool 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.
Rust'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.
7 replies →
This 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.
Love 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.
This 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.
4 replies →
Do you think soup kitchens and food banks should only serve food to those who volunteer? MIT is a perfectly fine FOSS license.
1 reply →
MIT licensed code is a gift. A gift indeed doesn't require the recipient to give back anything related to the gift.
A "gift" requiring GPL-like conditions isn't really a gift in the common sense. It's more like a contractual agreement with something provided and specific, non-negotiable obligations. They're giving while also asserting control over others' lives, hoping for a specific outcome. That's not just a gift.
People doing MIT license are often generous enough where the code is a gift to everyone. They don't try to control their lives or societal outcomes with extra obligations. They're just giving. So, I'm grateful to them for both OSS and business adaptations of their gifts.
6 replies →
Impressive work! Do you have any goals, other than learning and having fun?
Also how does it's design compare with Redox and Asterinas?
shouldn't this be a ShowHN?
Very 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.
I agree, I know a lot of people aren't huge fans of it but in the long run Linux being GPL2 was a huge factor in its success.
Too late? https://docs.freebsd.org/en/books/handbook/linuxemu/
Somewhere there is a dark timeline where the BSDs won, there are 50 commercial and open source variants all with their own kernel and userland. The only promise of interoperability is in extremely ossified layers like POSIX. There is, however, something terrible gathering its strength. A colossus. The great Shade that will eat the net. In boardroom meetings across the land, CTOs whisper its name and tremble... "OS/2."
1 reply →
Also, AFAIK SmartOS / Ilumos has had a combat layer for it, too.
Why?
because otherwise big tech companies will take it and modify and release hardware with it without releasing patches etc? Basically being selfish and greedy?
4 replies →
Because unlike most other functionality, you generally need hw specs or cooperation to write drivers (see Nvidia GSP).
Anyone can write Photoshop (provided reasonable resources). The problem is going to be proprietary file format and compatibility with the ecosystem. It's same with hardware, except several orders of magnitude worse.
It will be compatible for ~5 minutes:
https://www.kernel.org/doc/html/v4.10/process/stable-api-non...
> [Moss has] binary compatibility with Linux userspace applications (currently capable of running most BusyBox commands).
Per your link
> Note: Please realize that this article describes the in kernel interfaces, not the kernel to userspace interfaces.
How does this compare to https://github.com/nuta/kerla ?
Just a hobby, won’t be big and professional like Linux?
;-)
I don't know much about Linux internals - how difficult would it be to reimplement KVM? I'm guessing a big undertaking.
Really 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?
Eventually, 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.
This plus using Fil-C for the BusyBox commands is a nice combination (once Fil-C supports ARM64).
In what extent is this compatible with Linux?
Could I swap Ubuntu's or Android's kernel with this, while keeping those OSes bootable?
While 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.
At this stage you'd need to contribute to it, not treat it as a finished product.
[dead]