Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Maestro: A Linux-compatible kernel in Rust

blog.lenot.re

Post reply on HN
Print view View original

261–270 of 380 posts

Re: Maestro: A Linux-compatible kernel in Rust

#261

Post by loeg »

claytonwramsey wrote: post #203
llenotre wrote: post #144

Earlier quoted context omitted.

A lot of memory and concurrency issues have been eliminated. It is still a pain to debug, but a lot less than it was before though. As an example, there is not a lot of chances you forget to use a mutex since the compiler would remind it to you by an error. This is not a silver bullet though, things such as deadlocks are still present. Especially with interruptions. To give an example, if you decide to lock a mutex,…

If you’re willing to implement your own mutex, it actually is possible to enforce! You could make disabling interrupts emit a token and then require the mutex to accept that token as a parameter to its locking behavior.

How would you enforce use of (only) the correct kind of mutex in interrupt context?

Re: Maestro: A Linux-compatible kernel in Rust

#263

Post by Arnavion »

panick21_ wrote: post #253
maxloh wrote: post #249

Earlier quoted context omitted.

Seems that the project is dead. The repository does not receive any commit for two years.

No its not. See: https://gitlab.redox-os.org/redox-os/redox/ https://www.redox-os.org/news/development-priorities-2023-09...

They were talking about Kerla but replied to the wrong comment.

Re: Maestro: A Linux-compatible kernel in Rust

#264

Post by phkahler »

yoyohello13 wrote: post #220
phkahler wrote: post #155

MIT license? If by chance this evolves into something big, it will be eaten alive by commercial interests. Look at the conflict between Linux devs and nVidia for example. Look at the IBM/RedHat stuff trying to circumvent the spirit of the GPL, if maybe not the text of it. If it becomes a thing, the most active developers will be paid by corporations and they will not be sharing code with you when it suits them - whic…

The amount of hate for GPL on HN is disturbing.

>> The amount of hate for GPL on HN is disturbing.

I agree. I'm really baffled by the Rust community pretty much standardizing on MIT license. People laugh at "Rewrite it in Rust" which I think is a good thing but completely ignore the whole "strip users of their freedom" that is coming with it one day.

Re: Maestro: A Linux-compatible kernel in Rust

#265

Post by epcoa »

claytonwramsey wrote: post #203
llenotre wrote: post #144

Earlier quoted context omitted.

A lot of memory and concurrency issues have been eliminated. It is still a pain to debug, but a lot less than it was before though. As an example, there is not a lot of chances you forget to use a mutex since the compiler would remind it to you by an error. This is not a silver bullet though, things such as deadlocks are still present. Especially with interruptions. To give an example, if you decide to lock a mutex,…

If you’re willing to implement your own mutex, it actually is possible to enforce! You could make disabling interrupts emit a token and then require the mutex to accept that token as a parameter to its locking behavior.

But what forces you to declare the correct interrupt policy as it may not be the same for all uses of even the same mutex?

Re: Maestro: A Linux-compatible kernel in Rust

#266

Post by drtgh »

samus wrote: post #235
drtgh wrote: post #96

This sounds more than great. Unrelated but at same time related, feel your self absolutelly free to ignore this message, Linux needs a HISP with firewall. I comment it here because this need to be supported by a/the kernel, its needed to limit the functions that allow process injections, and also a way for to canalize all the process executions in a supervised mode. As an [put operative system name here] user, I need…

It already exists: SELinux or AppArmor. They build on infrastructure that allows implementing other solutions to that effect. However, on a typical system there is so much going on that this is unlikely to be of much use to anybody not willing to just spend their time reviewing arcane internals of their applications. The above does not how I'd want to spend my day at the computer. Android and iOS presents a middle gr…

Thanks for your comment. SELinux and AppArmour don't do exactly what I commenting, those tools are more or less homologous to create users with different permissions for each application. RSBAC kernel extension would get closer, but not enough.

I really consider a need the system I commented, remarking process injections active supervision and internet access control, so I've been searching along one year or so for it. And I am afraid it does not exists, kernel modification is necessary for to obtain it, so the derived tools doesn't exist.

I guess the same way it does not exist something like SystemInformer(ProcessHacker) or Sysinternals' ProcessExplorer and Procmon (I talk about the advanced features, libs tracking/search, etc, not just show a process list). I mean, the philosophy about "my system could be infected" lets try to look whats going on.

>users are pretty quickly seduced to just allow everything

Certainly. In my case it requires a routine and a desire to follow it. Maybe I should have used the word advanced desktop user.

Re: Maestro: A Linux-compatible kernel in Rust

#267

Post by RHSeeger »

chatmasta wrote: post #251
RHSeeger wrote: post #66

Earlier quoted context omitted.

I expect it's likely more of "memory safety in a language doesn't make it _safe_, it makes it less vulnerable". It removes _some_ issues, in the same way that a language with static types removes some ways a program can be wrong, it doesn't make it correct.

The problem is the word "safe," which is inherently ambiguous. Safe from what ? A better term would be "correct," because at least that implies there is some spec to which the developer expects the program to conform (assuming the spec itself is "correct" and devoid of design flaws).

While I agree with your point in general, I don't think the choice of wording is "the problem" here. But I do agree your wording is more correct.

It is almost impossible to prove a program is "correct". But things like memory safe languages, static typing, and automated tests allow us to prove the ways in which it is not "incorrect". And the more places it is not incorrect, the more likely it is to be correct (even if we can't prove it).

Re: Maestro: A Linux-compatible kernel in Rust

#268

Post by peoplefromibiza »

bigstrat2003 wrote: post #247
peoplefromibiza wrote: post #81

Earlier quoted context omitted.

> if Linux had been built with safety in mind security would be a lot simpler I'm replying simply because you're getting defensive with your edits, but you're missing a few important points, IMO. First of all, the comment I quoted falls straight into the category of if only we knew back then what we know now . What does it even mean "built with safety in mind" for a project like Linux? No one could predict that Linux…

> Lastly, the strongest Linux safety guarantee is IMO the GPL license, that conveniently all these Rust rewrites are turning into more permissive licenses. Which steers away from what Linux was, and still largely is, a community effort based on the work of thousands of volunteers. There is nothing about permissive licenses which prevents the project from being such a community effort. In fact, most of the Rust ecosys…

> There's no issue here

Tell that to Microsoft.

GPL protected Linux when Linux started to become a threat to the most powerful tech company on Earth of the time, famous for their "embrace and extend" tactic.

Rust had no such problem, it was started by a company that every year takes hundreds of millions (81% of their revenues in 2022) from one of the most powerful tech companies on Earth.

Re: Maestro: A Linux-compatible kernel in Rust

#269

Post by toast0 »

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…

> What a cool little project. It's astonishing how far this can boot with less than a third of the syscalls of Linux implemented.

My hobby OS is more or less a FreeBSD compatible kernel for one specific language VM[1]; it looks like I support 61 syscalls out of 424, and it's been a while since I ran across one I missed (sometimes syscalls are only called in some code paths, or when I target a newer kernel, there may be newer syscalls)

There are a lot of syscalls, and some of them are pretty esoteric; eventually a fully openended replacement will get to most of them, but a third is a good start.

[1] I wanted VM on metal and/or boot to VM, and it became apparent that this is the least effort way to get there, other than probably just having init=/path/to/the/vm; but that doesn't get me what I really want (hardware drivers and tcp stack in the VM language).

Re: Maestro: A Linux-compatible kernel in Rust

#270

Post by renox »

bluGill wrote: post #124
insanitybit wrote: post #39

Earlier quoted context omitted.

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)

Simple, when Linux was created gcc was Free, Ada compilers were expensive..
Post reply on HN