11–20 of 81 posts
> This IPC often has a performance impact, which is a big part of why microkernels have remained relatively unpopular. Somewhat comforting to see deeply technical people still misconstruing why approaches/projects don't get adopted.
Earlier quoted context omitted.
> if an unprivileged task is unsafe, it's still unprivileged. Meanwhile the unsafe code that requires extra verification... I am sorry that the doc is a kind of misleading. I wrote that... The statement need to be interpreted in the context of framekernel. An entire Rust-based framekernel runs in the kernel space but is logically partitioned into the two halves: the privileged OS framework and the de-privileged OS se…
I had the same reaction that this sounded all very backwards, but reading the introduction in the paper[1] made it more clear: The kernel is logically divided into two parts: the privileged OS framework (akin to a microkernel) and the de-privileged OS services. Only the privileged framework is allowed to use unsafe, while the de-privileged services must be written in safe Rust completely. As the TCB, the privileged f…
> 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…
SeL4 is a microkernel like this. They’ve apparently aggressively optimized IPC far more than Linux ever has. Sending a message via sel4 ipc is apparently an order of magnitude or two faster than syscalls under Linux. I wouldn’t be surprised if most programs performed better under sel4 than they do under Linux - but I’d love to know for real.
> This IPC often has a performance impact, which is a big part of why microkernels have remained relatively unpopular. Somewhat comforting to see deeply technical people still misconstruing why approaches/projects don't get adopted.
It would help everyone if you'd actually tell us in which way they're doing that.
> 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…
> I thought newer microkernels... Reduced that? Fixed it? I forget, I just had the impression it wasn't actually that bad SeL4 is a microkernel like this. They’ve apparently aggressively optimized IPC far more than Linux ever has. Sending a message via sel4 ipc is apparently an order of magnitude or two faster than syscalls under Linux. I wouldn’t be surprised if most programs performed better under sel4 than they do…
> 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…
> 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.
Designing a modern and secure kernel in 2025 as a monolith is a laughable proposition. Microkernels are the way to go.
This is an awesome effort, thank you, knowing that one of the authors is in the thread. How far is this from usability, at least in some reduced context? Would love to be able to build server images based on this kernel and play around with it.
We're actively implementing key features like Linux namespaces and cgroups, and we're also working on the first Asterinas-based distribution. Our initial focus is to use Asterinas as the guest OS inside Confidential VMs. This use case prioritizes security, where Asterinas has clear advantages over Linux thanks to its memory safety guarantee and small TCB.