alt Hacker NewsMoss: a Rust Linux-compatible kernel in 26,000 lines of code
Comments
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!
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.
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?
I don't know much about Linux internals - how difficult would it be to reimplement KVM? I'm guessing a big undertaking.
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?
> MIT license
What have you done?!
[dead]
The 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.