Maestro: A Linux-compatible kernel in Rust
blog.lenot.re
Maestro: A Linux-compatible kernel in Rust
1–10 of 380 posts
Re: Maestro: A Linux-compatible kernel in Rust
#2I love it and hope it will catch on.
I reminds me of what Linus Torvalds once said when asked about fearing competition, though.
From my memory his answer was something like: I really like writing device drivers. Few people like that and until someone young and hungry comes along who likes that I'm not afraid of competition.
Re: Maestro: A Linux-compatible kernel in Rust
#3Great. Hope he keeps doing this until he finds enough supporters
Re: Maestro: A Linux-compatible kernel in Rust
#4Small feedback: On mobile the back button (and nav bar) block 1/6th of the page, probably could use a bit less padding
Re: Maestro: A Linux-compatible kernel in Rust
#5Syscalls are easy. Drivers will be tough.
Re: Maestro: A Linux-compatible kernel in Rust
#6A memory safe linux kernel would be a fairly incredible thing. If you could snap your fingers and have it, the wins would be huge.
Consider that right now a docker container can't be relied upon to contain arbitrary malware, exactly because the Linux kernel has so many security issues and they're exposed to containers. The reason why a VM like Firecracker is so much safer is that it removes the kernel as the primary security boundary.
Imagine if containers were actually vm-level safe? The performance and operational simplicity of a container with the security of a VM.
I'm not saying this is practical, at this point the C version of Linux is here to stay for quite a while and I think, if anything, Fuschia is the most likely successor (and is unlikely to give us the memory safety that a Rust kernel would). But damn, if Linux had been built with safety in mind security would be a lot simpler. Being able to trust the kernel would be so nice.
edit: OK OK. Yeesh. I meant this to be a hypothetical, I got annoyed at so many of the replies, and this has spiraled. I'm signing off.
I apologize if I was rude! Not a fun start to the morning.
Re: Maestro: A Linux-compatible kernel in Rust
#7Compatible means "syscall compatible" (I get that from the article). I wonder if it also means kernel module compatible (I dont think so, as the API touch point surface is much larger), but if it strives to be that'd be great (use all hardware that works on Linux).
Re: Maestro: A Linux-compatible kernel in Rust
#8There's also Kerla [1] (Monolithic kernel in Rust, aiming for Linux ABI compatibility), but that seems to have gone dormant for few years.
Re: Maestro: A Linux-compatible kernel in Rust
#9I love it and hope it will catch on. I reminds me of what Linus Torvalds once said when asked about fearing competition, though. From my memory his answer was something like: I really like writing device drivers. Few people like that and until someone young and hungry comes along who likes that I'm not afraid of competition.
But GPU drivers require a fairly big team. We must have a GPU hardware programming "standard" first. And I would favor a risc-v kernel instead to avoid the dependency on a super complex syntax (rust) compiler and do gcc-dependency-like mistake all over again. For this reason, eating the bullet and moving on a modern worldwide standard ISA would actually be the real move forward. We have already linux and others tied to gcc extensions and very recent ISO tantrums (porting to not-inline assembly and back to c89/99 is carefully made not reasonable, not to mention assembly code paths tied to specific stack alignment features from the compiler). Namely there is a serious imbalance between the compiler complexity and what it is actually bringing on the table.
Re: Maestro: A Linux-compatible kernel in Rust
#10A memory safe linux kernel would be a fairly incredible thing. If you could snap your fingers and have it, the wins would be huge. Consider that right now a docker container can't be relied upon to contain arbitrary malware, exactly because the Linux kernel has so many security issues and they're exposed to containers. The reason why a VM like Firecracker is so much safer is that it removes the kernel as the primary…
> a docker container can't be relied upon to contain arbitrary malware
"to not contain"?
Edit to contain (ahem!) the downvotes: I was genuinely confused by the ambiguous use of "contain", but comments below cleared that up.