Maestro: A Linux-compatible kernel in Rust • Hacker News Board

Re: Maestro: A Linux-compatible kernel in Rust

#121

Post by yjftsjthsd-h » Wed, Jan 03, 2024, 2:17 PM UTC

insanitybit wrote: post #64

jvanderbot wrote: post #57

Earlier quoted context omitted.

I said "the idea of using memory safe languages is great!" And "using memory safe languages does not eliminate attack surface". (It's pre coffee here so I appreciate your probe) I meant that it's over-reach to say it's completely trustworthy just bc it's written in a GC/borrow checked language.

The premise of my post was "imagine a memory safe kernel". I repeatedly use the word "imagine".

The disagreement is that you wrote "imagine a memory safe kernel" but appear to have meant "imagine a kernel with zero vulnerabilities of any kind", and those things are not equivalent.

Re: Maestro: A Linux-compatible kernel in Rust

#122

Post by mkl » Wed, Jan 03, 2024, 2:17 PM UTC

sylware wrote: post #110

mkl wrote: post #103

Earlier quoted context omitted.

What you are proposing is so terrible in practice that people have invented hundreds of programming languages to escape it. Millions of person-hours have been spent on getting away from what you say is desirable.

You are right in a legacy context where the mess of ISAs required an abstraction of the assembly language. But where you are wrong is, moving forward in a world with a modern worldwide standard ISA (RISC-V) is actually writing a kernel in assembly (without abusing any preprocessing).

People have had the ability to do that for decades, and they have almost always chosen not to when they had the option, because it's terrible. RISC-V is nothing revolutionary on that front, and doesn't magically make it better. Without preprocessing you won't have variable names or jump label names or strings, which is even more terrible.

Please give us some actual evidence, instead of just saying "you're wrong", because the position you're taking seems extreme and, frankly, bonkers.

Re: Maestro: A Linux-compatible kernel in Rust

#123

Post by vanderZwan » Wed, Jan 03, 2024, 2:20 PM UTC

dabedee wrote: post #117

DaveFlater wrote: post #114

[flagged]

If you spend time reading the article, you can agree or disagree with his choices, but he provides several reasons for why he chose to rewrite in Rust over after the initial project was written in C: "At that moment, I decided to switch to Rust (my first project in this language), which represented several advantages: - Restart the project from the beginning, using lessons learned from previous mistakes - Be a bit mo…

Also, there's the implicit "I'm doing this to learn and have fun with a personal project" aspect which seems valid

Re: Maestro: A Linux-compatible kernel in Rust

#124

Post by bluGill » Wed, Jan 03, 2024, 2:21 PM UTC

insanitybit wrote: post #39

K0nserv wrote: post #11

Earlier quoted context omitted.

I largely agree, but this seems quite unfair to Linux. > 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. For its time, it was built with safety in mind, we can't hold it to a standard that wasn't prevalent until ~20 years later

I don't think it's that unfair, but I don't want to get into a whole thing about it, people get really upset about criticisms of the Linux kernel in my experience and I'm not looking to start my morning off with that conversation. We can agree that C was definitely the language to be doing these things in and I don't blame Linus for choosing it. My point wasn't to shit on Linux for its decisions, it was to think abou…

why not ada? Sure rust didn't exist when linux was first being built, but ada did and had a number of memory safety features. (not the same as rust's, but still better than C)

Re: Maestro: A Linux-compatible kernel in Rust

#125

Post by ahmedfromtunis » Wed, Jan 03, 2024, 2:22 PM UTC

peoplefromibiza wrote: post #41

ahmedfromtunis wrote: post #24

Earlier quoted context omitted.

Care to elaborate on this? I clearly understand nothing of this, but it always felt confused about it. Why won't Linux aim for ABI stability? Wouldn't that be a win for everyone involved?

The Linux Kernel Driver Interface (all of your questions answered and then some) https://github.com/torvalds/linux/blob/master/Documentation/...

Great to see that Greg Kroah-Hartman dedicated a whole article to answering my questions. Thanks!

Re: Maestro: A Linux-compatible kernel in Rust

#126

Post by consp » Wed, Jan 03, 2024, 2:23 PM UTC

berkes wrote: post #58

dark-star wrote: post #37

What a cool little project. It's astonishing how far this can boot with less than a third of the syscalls of Linux implemented. However, my guess is that the ones that are missing are the more complicated ones. The TTY layer, for example, looks rather basic at the moment. Getting this right will probably be a lot of work. So don't hold your breath for Maestro running your Linux applications in the next 3 years or so…

Is there maybe a subset of Linux applications that it could run soon? A proxy, nfs, some database server, http server, firewall? I think it doesn't need to run Steam, libreoffice and Firefox to be useful. Many parts in a common server or microservices architecture are relatively simple in what they do and would probably benefit a lot from a safe, simple kernel.

> Is there maybe a subset of Linux applications that it could run soon? A proxy, nfs, some database server, http server, firewall?

You first need to port drivers for your -specific- network and io chipset. And if you want adoption and performance you also need the manufacturer on board. My guess is not quite soon.

Re: Maestro: A Linux-compatible kernel in Rust

#127

Post by MobiusHorizons » Wed, Jan 03, 2024, 2:26 PM UTC

sylware wrote: post #110

mkl wrote: post #103

Earlier quoted context omitted.

What you are proposing is so terrible in practice that people have invented hundreds of programming languages to escape it. Millions of person-hours have been spent on getting away from what you say is desirable.

You are right in a legacy context where the mess of ISAs required an abstraction of the assembly language. But where you are wrong is, moving forward in a world with a modern worldwide standard ISA (RISC-V) is actually writing a kernel in assembly (without abusing any preprocessing).

RISC-v assembly is not substantially easier to write than any other assembly. RISC assemblies in general (aka MIPS, Arm, RV64 etc) require more instructions to accomplish the same tasks. I would argue they are designed with compilers in mind more than human authors. Older assemblies expected the programmer to be programming in assembly directly, which is why they allow you to express your intent more directly than RISC. Humans of course can and do write assembly in all of these, but risc-v has not somehow made assembly programming any safer or more portable than it ever was.

Re: Maestro: A Linux-compatible kernel in Rust

#128

Post by yjftsjthsd-h » Wed, Jan 03, 2024, 2:27 PM UTC

weinzierl wrote: post #13

dottedmag wrote: post #5

Syscalls are easy. Drivers will be tough.

Drivers are the tough part and the lack of a stable interface in Linux makes them hard to reuse.

Doesn't FreeBSD borrow graphics drivers from Linux? If I'm remembering that right, it can't be quite that bad.

Re: Maestro: A Linux-compatible kernel in Rust

#129

Post by dartos » Wed, Jan 03, 2024, 2:27 PM UTC

meltyness wrote: post #50

jvanderbot wrote: post #48

Earlier quoted context omitted.

The culture around memory safe languages is a positive improvement for programmer zeitgeist. Man though the overreach all the way to "always safe forever" needs to be checked.

Just the other day they were full kum ba yah over a holiday-time-released feature that's likely going to greatly increase the likelihood of building race conditions and deadlocks. https://news.ycombinator.com/item?id=38721039

How do you figure?

Is it just because it makes async possible?

Re: Maestro: A Linux-compatible kernel in Rust

#130

Post by vanderZwan » Wed, Jan 03, 2024, 2:28 PM UTC

DaveFlater wrote: post #114

[flagged]

It's not trying to replace the Linux kernel though, it's a personal project trying to be compatible with it. Yes, they're asking if anyone else wants to join near the end, but that doesn't imply anything. Small-scale hobbyist projects with fellow enthusiasts exist.