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

Asterinas: A new Linux-compatible kernel project

lwn.net

Post reply on HN
Print view View original

31–40 of 81 posts

Re: Asterinas: A new Linux-compatible kernel project

#31

Post by uncircle »

dale_glass wrote: post #25
uncircle wrote: post #19

Earlier quoted context omitted.

There are hordes of developers completely dismissing the idea of microkernels with no serious argument other than "lmao didn't Linus destroy Tanenbaum that one time?" Designing a modern and secure kernel in 2025 as a monolith is a laughable proposition. Microkernels are the way to go.

Well, here's some for you: * In modern times, the practical benefit from a microkernel is minimal. Hardware is cheap, disposable, and virtual machines exist. The use case for "tolerate a chunk of the kernel misbehaving" are minimal. * To properly tolerate a partial crash takes a lot of work. If your desktop crashes, you might as well reboot. * Modern hardware is complex and there's no guarantee that rebooting a drive…

You describe microkernels are if there is only one way to implement them.

> A different process can just ignore your message

> arbitrarily get stuck on something and not act in time

This doesn't make sense. An implementation of a microkernel might suffer from these issues, it's not a problem of the design itself. There are many ways of designing message queues.

Also:

> In a microkernel, there can't be such trust [between processes]

Capabilities have solved this problem in a much better and scalable way than the implicit trust model you have in a monolithic kernel. Using Linux as an example of a monolith is wrong, as it incorporates many ideas (and shortcomings) of a microkernel. For example: how do you deal with implicit trust when you can load third-party modules at run-time? Capabilities offer much greater security guarantees than "oops, now some third-party code is running in kernel mode and can do anything it wants with kernel data". Stuff like the eBPF sandbox is like a poor-man's alternative to the security guarantees of microkernels.

Also, good luck making sure the implicitly trusted perimeter is secure in the first place when the surface area of the kernel is so wide it's practically impossible to verify.

If you allow me an argument from authority, it is no surprise Google's Fuchsia went for a capability-based microkernel design.

Re: Asterinas: A new Linux-compatible kernel project

#34

Post by yjftsjthsd-h »

pjmlp wrote: post #18
yjftsjthsd-h wrote: post #4

> This IPC often has a performance impact, which is a big part of why microkernels have remained relatively unpopular. I thought newer microkernels... Reduced that? Fixed it? I forget, I just had the impression it wasn't actually that bad except that the industry is still traumatized by Mach. From the project website: > Only the privileged Framework is allowed to use unsafe features of Rust, while the unprivileged Se…

The problem is that many microkernel haters keep repeating what used to be true like 30 years ago, while running tons of containers for basic tasks.

> while running tons of containers for basic tasks.

Those containers run on a monolithic kernel; what's your point?

Re: Asterinas: A new Linux-compatible kernel project

#35

Post by helpfulContrib »

weinzierl wrote: post #24

This is an interesting approach, and I wish it will succeed. I am still skeptical. In the late 90s or early 2000s Linus was interviewed on TV and what he said stuck with me to this day. When asked about competitors he roughly said: No one likes writing device drivers and as long no one young and hungry comes along who is good at writing device drivers I am save. I think he was already well aware at that time that kee…

I have written device drivers for, literally, decades now.

Its the old guys who write the best drivers, naturally.

For me, Asterinas represents a refreshing way to approach some thorny problems in the embedded space, in which embedded-Linux on ARM, RISC-V and MIPS is a viable, economically-speaking, platform for a great deal of industry.

While Asterinas is really sexy, if this same approach were taken for, say, FreeRTOS as well along the way .. then there could at least, also, be "on one hands" worth of operating systems, abstracted, in the "lets just use rust' camp ..

Re: Asterinas: A new Linux-compatible kernel project

#36

Post by reactordev »

tatetian16 wrote: post #29
weinzierl wrote: post #24

This is an interesting approach, and I wish it will succeed. I am still skeptical. In the late 90s or early 2000s Linus was interviewed on TV and what he said stuck with me to this day. When asked about competitors he roughly said: No one likes writing device drivers and as long no one young and hungry comes along who is good at writing device drivers I am save. I think he was already well aware at that time that kee…

> keeping the driver interface unstable is his moat Maybe we will have young and hungry AI-for-system researchers who would like to take on the job of developing AI agents that translate Linux drivers in C to Asterinas ones in (safe) Rust. Another feasible approach is to reuse Linux drivers by running a Linux kernel inside some kind of isolated environments. For example, the HongMeng kernel leverages User-Mode Linux…

This is the future. Hardware has already standardized more towards USB HID than in previous decades, Linus interview included. When AI can develop these device drivers based on just probing the HID info, we’ll be on Cloud9. Because maybe then, we’ll get the year of the Linux desktop.

Re: Asterinas: A new Linux-compatible kernel project

#37

Post by lkjdsklf »

uncircle wrote: post #31
dale_glass wrote: post #25

Earlier quoted context omitted.

Well, here's some for you: * In modern times, the practical benefit from a microkernel is minimal. Hardware is cheap, disposable, and virtual machines exist. The use case for "tolerate a chunk of the kernel misbehaving" are minimal. * To properly tolerate a partial crash takes a lot of work. If your desktop crashes, you might as well reboot. * Modern hardware is complex and there's no guarantee that rebooting a drive…

You describe microkernels are if there is only one way to implement them. > A different process can just ignore your message > arbitrarily get stuck on something and not act in time This doesn't make sense. An implementation of a microkernel might suffer from these issues, it's not a problem of the design itself. There are many ways of designing message queues. Also: > In a microkernel, there can't be such trust [bet…

I’m not sure I would consider fuschia an example that supports your point.

It’s design largely failed at being a modern generic operating system and it’s become primarily an os used for embedded devices which is an entirely different set of requirements

It’s also not that widely used. There’s only a handful of devices that ship fuschia today. There’s a reason for that.

Re: Asterinas: A new Linux-compatible kernel project

#38

Post by uncircle »

lkjdsklf wrote: post #37
uncircle wrote: post #31

Earlier quoted context omitted.

You describe microkernels are if there is only one way to implement them. > A different process can just ignore your message > arbitrarily get stuck on something and not act in time This doesn't make sense. An implementation of a microkernel might suffer from these issues, it's not a problem of the design itself. There are many ways of designing message queues. Also: > In a microkernel, there can't be such trust [bet…

I’m not sure I would consider fuschia an example that supports your point. It’s design largely failed at being a modern generic operating system and it’s become primarily an os used for embedded devices which is an entirely different set of requirements It’s also not that widely used. There’s only a handful of devices that ship fuschia today. There’s a reason for that.

Did it fail because of its microkernel design?

It’s quite disingenuous to use “success” as a metric when discussing the advantages microkernel vs monolithic, as the only kernels you can safely say have succeeded in the past 30+ years are three: Linux, NT and Mach, one of which is a microkernel (of arguably dated design), and the other is considered a “hybrid microkernel.”

Did L4 fail? What about QNX?

This topic was considered a flame war in the 90s and I guess it still isn’t possible to have a level-headed argument over the pros and cons of each design to this day.

Re: Asterinas: A new Linux-compatible kernel project

#39

Post by BenjiWiebe »

reactordev wrote: post #36
tatetian16 wrote: post #29

Earlier quoted context omitted.

> keeping the driver interface unstable is his moat Maybe we will have young and hungry AI-for-system researchers who would like to take on the job of developing AI agents that translate Linux drivers in C to Asterinas ones in (safe) Rust. Another feasible approach is to reuse Linux drivers by running a Linux kernel inside some kind of isolated environments. For example, the HongMeng kernel leverages User-Mode Linux…

This is the future. Hardware has already standardized more towards USB HID than in previous decades, Linus interview included. When AI can develop these device drivers based on just probing the HID info, we’ll be on Cloud9. Because maybe then, we’ll get the year of the Linux desktop.

Pretty sure if your device actually just uses USB HID, it already works on Linux without a custom driver.

What requires a custom driver is when your device adds its own non standard features.

Re: Asterinas: A new Linux-compatible kernel project

#40

Post by rcxdude »

tatetian16 wrote: post #29
weinzierl wrote: post #24

This is an interesting approach, and I wish it will succeed. I am still skeptical. In the late 90s or early 2000s Linus was interviewed on TV and what he said stuck with me to this day. When asked about competitors he roughly said: No one likes writing device drivers and as long no one young and hungry comes along who is good at writing device drivers I am save. I think he was already well aware at that time that kee…

> keeping the driver interface unstable is his moat Maybe we will have young and hungry AI-for-system researchers who would like to take on the job of developing AI agents that translate Linux drivers in C to Asterinas ones in (safe) Rust. Another feasible approach is to reuse Linux drivers by running a Linux kernel inside some kind of isolated environments. For example, the HongMeng kernel leverages User-Mode Linux…

The bottleneck, for the most part, is actually being able to test them. Even a translation by a skilled engineer is liable to have issues if they don't actually have the hardware to test things out. Linux's driver support is built out mainly by people doing that, either hobbyists scratching their own itch of hardware they own or manufacturers contributing drivers for their own hardware.

(It's also why regressions are pretty common: it's completely infeasible to test all of linux on each release, some people test some parts of it, but it's all very ad-hoc, very little is automated, and it's not at all unified)

Post reply on HN