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

21–30 of 81 posts

Re: Asterinas: A new Linux-compatible kernel project

#21

Post by Joker_vD »

uncircle wrote: post #19
pjmlp wrote: post #18

Earlier quoted context omitted.

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.

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.

> Designing a modern and secure kernel in 2025 as a monolith is a laughable proposition.

I've seen this exact opinion before, only the year in it was "1992". And yet Linux was still made and written regardless of it.

Re: Asterinas: A new Linux-compatible kernel project

#22

Post by vbezhenar »

Is it novel development: splitting kernel into small unsafe core and large safe modules? It sounds very interesting and promising. No hardware overhead of microkernel and no safety issues of monolith. Such a project, obviously, depends on a systems language with explicit unsafe/safe separation.

Re: Asterinas: A new Linux-compatible kernel project

#24

Post by weinzierl »

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 keeping the driver interface unstable is his moat. A quarter of a century later kernels that run on virtualized hardware are a dime a dozen but practically useable operating systems in the traditional sense of abstracting away real hardware can still be counted on one hand.

Re: Asterinas: A new Linux-compatible kernel project

#25

Post by dale_glass »

uncircle wrote: post #19
pjmlp wrote: post #18

Earlier quoted context omitted.

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.

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 driver will be successful.

* A monolithic kernel can always clone microkernel functionality wherever it wants, without paying the price elsewhere.

* Processes can't trust each other.

The last one is a point I hadn't realized for a while was an issue, but it seems a tricky one. In a monolithic kernel, you can have implicit trust that things will happen. If part A tells part B "drop your caches, I need more memory", it can expect that to actually happen.

In a microkernel, there can't be such trust. A different process can just ignore your message, or arbitrarily get stuck on something and not act in time. You have less ability to make a coherent whole because there's no coherent whole.

Re: Asterinas: A new Linux-compatible kernel project

#26

Post by leeter »

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…

> but practically useable operating systems in the traditional sense of abstracting away real hardware can still be counted on one hand.

I think this is telling. There are plenty of 'standards' for interfaces in the hardware world. Some (mostly USB) are even 'followed', but the realities of hardware are that it never behaves nominally. So without someone willing to spend the time writing code to handle the quirks that can't be patched out and the errata it's very hard to run on physical hardware with any performance or support.

Re: Asterinas: A new Linux-compatible kernel project

#27

Post by bandrami »

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 parts written in unsafe rust implement the memory and access management that make it possible for the other parts to use safe rust.

Re: Asterinas: A new Linux-compatible kernel project

#28

Post by ronjakoi »

kelnos wrote: post #9
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…

My understanding is they don't mean privileged/unprivileged in the kernel-space/user-space sense. All of it is running at the kernel's privilege level. Just they've logically defined a (smaller) set of core library-like code that is allowed to use Rust unsafe ("privileged"), and then all the code that implements the rest of the kernel (including drivers?) uses that library and is disallowed (by linter rules, I assume…

Perhaps I, as the author of this article, could have also been more careful with the terminology.

Re: Asterinas: A new Linux-compatible kernel project

#29

Post by tatetian16 »

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 to reuse Linux drivers on HongMeng [1]. Asterinas can take a similar approach.

[1] https://www.usenix.org/conference/osdi24/presentation/chen-h...

Post reply on HN