5 ms·

> This IPC often has a performance impact, which is a big part of why microkernels have remained relatively unpopular. I thought newer microkernels... Reduced

> 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 Services must be written exclusively in safe Rust. That feels backwards to me. If an unprivileged task is unsafe, it's still unprivileged. Meanwhile the unsafe code that requires extra verification... Is only allowed in the part where nothing can safeguard it? And from https://asterinas.github.io/book/index.html https://asterinas.github.io/book/index.html (because it was one of my first questions on seeing 'Linux replacement in rust'): > Licensing > Asterinas's source code and documentation primarily use the Mozilla Public License (MPL), Version 2.0. Select components are under more permissive licenses, detailed here. Not GPL, but not BSD either.

tatetian16 1y ago
> 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 services. Here, "privileged" means safe + unsafe Rust kernel code, whereas "de-privileged" means all safe Rust kernel code. And this is all about the kernel code. Framekernels do not put restrictions on the languages of user-space programs.
- magicalhippo 1y ago
  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 framework encapsulates all low-level, hardware-oriented unsafe operations behind safe APIs. Using these safe APIs, the de-privileged OS services can implement all kinds of OS functionalities, including device drivers. Ostd provides a small yet expressive set of safe OS development abstractions, covering safe user-kernel interactions, safe kernel logic, and safe kernel-peripheral interactions. Of particular note is the untyped memory abstraction, which addresses the challenge of safely handling externally-modifiable memory (e.g., MMIO or DMA-capable memory) – a longstanding obstacle in safe driver development. So the privileged part is privileged because it does unsafe stuff. It's also quite minimal, so that the "business logic" of a driver or similar can be implemented using safe code in the de-privileged code, which is de-privileged because it doesn't need privileged unsafe access. At least that's my understanding. [1]: https://arxiv.org/abs/2506.03876 https://arxiv.org/abs/2506.03876
  - tatetian16 1y ago
    Yes, that is correct.
ulrikrasmussen 1y ago
> That feels backwards to me. If an unprivileged task is unsafe, it's still unprivileged. Meanwhile the unsafe code that requires extra verification... Is only allowed in the part where nothing can safeguard it? The unprivileged task is running in the same memory space as the core kernel, and thus there are no runtime checks to ensure that it doesn't do something which it is not allowed to do. The only way you could enforce it at runtime would be to adopt a microkernel architecture. The alternative architecture proposed here is to enforce the privileges statically by requiring that the code doesn't use unsafe features.
kelnos 1y ago
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) to directly use Rust unsafe ("unprivileged"). It's an unfortunate overloading of terminology that you entirely reasonably interpreted according to the more common usage.
- ronjakoi 1y ago
  Perhaps I, as the author of this article, could have also been more careful with the terminology.
- yjftsjthsd-h 1y ago
  Oh, okay, so it's "privileged" in that it has the privilege of using unsafe. I got that it was all kernel mode but assumed they were doing something fancy to nonetheless restrict the unprivileged parts (though since they say it's all one memory space, I wasn't sure what)
josephg 1y ago
> 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 under Linux - but I’d love to know for real.
- winternewt 1y ago
  The trick with L4 is they treat IPC basically like syscalls. Arguments are left on CPU registers instead of serializing them to a message buffer. The only significant work performed is a change of virtual memory map. The called process continues execution within the time slice of the caller, instead of waiting for the thread scheduler or using synchronization primitives. While some of this could possibly be achieved with Linux, a lot of the optimization is ingrained into the calling convention and so would require changes to the user-mode source code.
  - pas 1y ago
    so simple recompilation can speed things up? sounds amazing. (but of course, can it?) also, it sounds a bit like restartable sequences (from Google).
pjmlp 1y ago
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.
- uncircle 1y ago
  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.
  - Joker_vD 1y ago
    > 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.
    - herewulf 1y ago
      Point taken but at that time there was no other free (as in beer and freedom) "UNIX" kernel? Someone may come along and correct me about BSD. Apologies I'm not super familiar with it's history.
      - Joker_vD 1y ago
        There was GNU Hurd in development at the time (which is actually a microkernel), with the first public release in 1990. Needless to say, it never amounted to much.
  - dale_glass 1y ago
    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.
bandrami 1y ago
The parts written in unsafe rust implement the memory and access management that make it possible for the other parts to use safe rust.
rwmj 1y ago
> I thought newer microkernels... Reduced that? Fixed it? They have. Actually the elephant in the room is modern hardware which makes even syscalls into monolithic kernels expensive. That's why io_uring and virtio perform well - they queue requests and replies between the OS and applications (or the hypervisor and the guest for virtio) avoiding transitions between address spaces. Any operating system in the future is going to need some kind of queuing syscall mechanism to perform well, and once you've got it doesn't much matter if you structure the components of your OS as a monolith or microkernel or something else.

tatetian16 1y ago

> 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 services. Here, "privileged" means safe + unsafe Rust kernel code, whereas "de-privileged" means all safe Rust kernel code. And this is all about the kernel code. Framekernels do not put restrictions on the languages of user-space programs.

magicalhippo 1y ago
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 framework encapsulates all low-level, hardware-oriented unsafe operations behind safe APIs. Using these safe APIs, the de-privileged OS services can implement all kinds of OS functionalities, including device drivers. Ostd provides a small yet expressive set of safe OS development abstractions, covering safe user-kernel interactions, safe kernel logic, and safe kernel-peripheral interactions. Of particular note is the untyped memory abstraction, which addresses the challenge of safely handling externally-modifiable memory (e.g., MMIO or DMA-capable memory) – a longstanding obstacle in safe driver development. So the privileged part is privileged because it does unsafe stuff. It's also quite minimal, so that the "business logic" of a driver or similar can be implemented using safe code in the de-privileged code, which is de-privileged because it doesn't need privileged unsafe access. At least that's my understanding. [1]: https://arxiv.org/abs/2506.03876 https://arxiv.org/abs/2506.03876
- tatetian16 1y ago
  Yes, that is correct.

ulrikrasmussen 1y ago

> That feels backwards to me. If an unprivileged task is unsafe, it's still unprivileged. Meanwhile the unsafe code that requires extra verification... Is only allowed in the part where nothing can safeguard it? The unprivileged task is running in the same memory space as the core kernel, and thus there are no runtime checks to ensure that it doesn't do something which it is not allowed to do. The only way you could enforce it at runtime would be to adopt a microkernel architecture. The alternative architecture proposed here is to enforce the privileges statically by requiring that the code doesn't use unsafe features.

kelnos 1y ago

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) to directly use Rust unsafe ("unprivileged"). It's an unfortunate overloading of terminology that you entirely reasonably interpreted according to the more common usage.

ronjakoi 1y ago
Perhaps I, as the author of this article, could have also been more careful with the terminology.
yjftsjthsd-h 1y ago
Oh, okay, so it's "privileged" in that it has the privilege of using unsafe. I got that it was all kernel mode but assumed they were doing something fancy to nonetheless restrict the unprivileged parts (though since they say it's all one memory space, I wasn't sure what)

josephg 1y ago

> 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 under Linux - but I’d love to know for real.

winternewt 1y ago
The trick with L4 is they treat IPC basically like syscalls. Arguments are left on CPU registers instead of serializing them to a message buffer. The only significant work performed is a change of virtual memory map. The called process continues execution within the time slice of the caller, instead of waiting for the thread scheduler or using synchronization primitives. While some of this could possibly be achieved with Linux, a lot of the optimization is ingrained into the calling convention and so would require changes to the user-mode source code.
- pas 1y ago
  so simple recompilation can speed things up? sounds amazing. (but of course, can it?) also, it sounds a bit like restartable sequences (from Google).

pjmlp 1y ago

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.

uncircle 1y ago
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.
- Joker_vD 1y ago
  > 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.
  - herewulf 1y ago
    Point taken but at that time there was no other free (as in beer and freedom) "UNIX" kernel? Someone may come along and correct me about BSD. Apologies I'm not super familiar with it's history.
    - Joker_vD 1y ago
      There was GNU Hurd in development at the time (which is actually a microkernel), with the first public release in 1990. Needless to say, it never amounted to much.
- dale_glass 1y ago
  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.

bandrami 1y ago

The parts written in unsafe rust implement the memory and access management that make it possible for the other parts to use safe rust.

rwmj 1y ago

> I thought newer microkernels... Reduced that? Fixed it? They have. Actually the elephant in the room is modern hardware which makes even syscalls into monolithic kernels expensive. That's why io_uring and virtio perform well - they queue requests and replies between the OS and applications (or the hypervisor and the guest for virtio) avoiding transitions between address spaces. Any operating system in the future is going to need some kind of queuing syscall mechanism to perform well, and once you've got it doesn't much matter if you structure the components of your OS as a monolith or microkernel or something else.