Enter Maestro, a unix-like monolithic kernel that aims to be compatible with Linux in order to ensure wide compatibility. Interestingly, it is written in Rust. It includes Solfége, a boot system and daemon manager, maestro-utils, which is a collection of system utility commands, and blimp, a package manager. According to Luc, it’s creator, the following third-party software has been tested and is working on the OS: musl (C standard library), bash, Some GNU coreutils commands such as ls, cat, mkdir, rm, rmdir, uname, whoami, etc… neofetch (a patched version, since the original neofetch does not know about the OS). If you want to test it out, fire up a VM with at least 1 GB of ram.
This sounds cool, but troubling because of its license. Trying to write a linux compatible kernel and licensing as MIT is basically asking to get railroaded by gigantic organizations. I hope they reconsider in the future.
because of its* license
Thanks :)
deleted by creator
According to Luc, its* creator
Keep fighting the good fight. Syntax is important.
Yes. Thank you, “It’s no tits”!
Username checks out
N O T I T S
Username checks out?
I think that’d be sugar chest
BUT WHAT WE MAKE
It snot its
Ok, I’m out of the loop and I’ve seen this often enough that I have to ask; why do people always bring up “written in rust”? No one points out that a given project is written in C++/C#/python/ruby etc, yet we keep seeing it for rust.
If you want a real answer, it’s mostly advocacy, the same reason Linux enthusiasts show up to every negative-sounding Windows thread to tell you to install Linux instead. And if it is less obnoxious, it’s only because there’s fewer Rust enthusiasts.
There are, also, advantages to a Rust implementation that you can claim simply by virtue of something being implemented in Rust, as entire categories of problem that cause C projects to hemorrhage security vulnerabilities simply don’t exist for Rust.
But mostly it’s people wanting you to be excited about and interested in Rust.
Is there something inherently safer with how rust does things, or is it just a case of it being new, so the vulnerabilities haven’t been found yet?
Yes, it is inherently safer than C. Unless you write code in an
unsafeblock, Rust will handle many aspects of memory allocation and management for you, and ensure their safety. It is memory safe and thread safe by default.C doesn’t have any of these safety checking features, so it would be equivalent to unsafe Rust, but all the time. It lets you do whatever you want with pointers for example, including making them point outside of the memory bounds. In program code, this will cause an illegal memory access exception, but in kernel code, all memory access is legal. Therefore, you could write a driver that accidentally overwrites the kernel’s own code in memory. That would likely cause a kernel panic and bring the whole system down. Whereas, in Rust, you can only do that within an
unsafecode block.Here’s the summary for the wikipedia article you mentioned in your comment:
Thread safety is a computer programming concept applicable to multi-threaded code. Thread-safe code only manipulates shared data structures in a manner that ensures that all threads behave properly and fulfill their design specifications without unintended interaction. There are various strategies for making thread-safe data structures.A program may execute code in several threads simultaneously in a shared address space where each of those threads has access to virtually all of the memory of every other thread. Thread safety is a property that allows code to run in multithreaded environments by re-establishing some of the correspondences between the actual flow of control and the text of the program, by means of synchronization.
Rust has many safeguards against some common errors that may cause security vulnerabilities. It’s by no means bulletproof against all vulnerabilities, but it’s something.
I only know the hype. But the hype says that Rust’s ownership system makes memory usage much safer by forcing the coder to deal with data. Your values will eventually go out of scope, and you have to dictate when that will happen or else it won’t compile.
…or something like that.
deleted by creator
Well rust has a borrow checker which does make some memory bugs harder to create but to say that rust solved any of the known open problems in computer security. The answer is clearly no. It just copied some good ideas from ocaml into C++ and got some good marketing.
borrow checkers also already exist for C/C++/etc [just most people don’t use them]
so, slightly safer defaults than C/C++ but doesn’t contain any new/unique security magic.
But it also has a cool name. You forgot to mention that very important aspect.
Programmers are hyped about Rust. It’s a programming language that has a legitimate chance to replace C and C++ for performance critical applications. So any new project in Rust increases the possibility of a future where C and C++ are programming languages of the past.
Removed by mod
Yeah the syntax is pretty far from more established languages, which is why I prefer C++ when I use it.
Because rust is the modern low level systems language, which means it gotta go fast without all the freaking problems of the only other real alternative so far that was C. The languages you list don’t even play in the same ballpark.
But a kernel written in Perl would be a real achievement. Something in a whole different league.
Honest question from someone using C++, though not for systems- or embedded stuff, just for object oriented models that gotta go fast: Why is C++ not in the same ballpark, and not an alternative?
Mentioning it’s written in rust should imply this code base will have secure concurrency, better memory handling, be easier to extend, while maintaining near C++ performance. None of these are guarantees, but considering so many rust projects are “C/C++ programs, rewritten” it seems worth calling out as a differential. The language’s advantages extending to the kernel make it an interesting project.
Yes they do? All the time? To the point where github has a bar on every project page showing what percentages of every project is written in which languages?
50MB for a sub POSIX kernel and a shell prompt for a 50MB ISO image that has less functionality than a 4KB kernel (L4SEC) which has actual formal proofs of correctness.
Well, I guess it has Rust as a selling point but that isn’t something that should matter if the goal is real security.
Started as a school project
I wouldn’t take it so seriously, it’s a passion project from a person learning about Rust and OS structure. Don’t compare this project against industry professionals.
Finally, some “exciting” news, 2031 will be the year of the linux desktop(and Maestro)!
A VM with 1GB of RAM but the screenshot shows 50MB in use?
Oh, looks like the install live environment needs it.
You should’ve read the article, ”You should run the ISO with sufficient RAM (1GB should be more than enough). Such an amount of memory is required because packages to be installed are stored in RAM (on the initramsfs) instead of the disk. This is currently the best method since the OS is not yet able to read on a USB stick or CD-ROM by itself, so it relies on the bootloader for this. ”
I guess you could run on lower ram, but package installs require more.
I did read the article, reason of my edit
Why?
He answers that in the project page. Just because there are kernels available, he can’t build his own and learn about kernel and computers in general (the answer for your question)
written in Rust.
And …why?
Contributing to Linux can be extremely daunting. Refactoring can be as well. Rust makes both of those a LOT easier. If a project is written in Rust instead of C there will be many more potential contributors and flexibility.
"In kernel development, debugging is very hard for several reasons:
- Documentation is often hard to find, and BIOS implementations may be flawed (more often than you would think)
- On boot, the kernel has full access to the memory and is allowed to write where it should not (its own code, for example)
- Troubleshooting memory leaks is not easy. Tools such as valgrind cannot be used
- gdb can be used with QEMU and VMWare, but the kernel may have a different behaviour when running on a different emulator or virtual machine. Also, those emulators may not support gdb (example VirtualBox)
- Some features in the support for gdb in QEMU or VMWare are missing and gdb might even crash sometimes
All those issues are reasons for using a memory-safe language, to avoid them as much as possible.
Overall, the use of Rust in the kernel allowed for the implementation of a lot of safeguards. And I believe that it is, to this day, the best decision I have made for this project."
