Asterinas: A new Linux-compatible kernel project
13 comments
·June 20, 2025yjftsjthsd-h
tatetian16
> 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
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.
tatetian16
Yes, that is correct.
kelnos
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.
josephg
> 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.
ulrikrasmussen
> 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.
lifty
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.
DinoNuggies45
[flagged]
defrost
A page of written text you mean?
Likely a text editor or some web publishing tool.
All of which raises a real question about your question and all your other recent "questions" - https://news.ycombinator.com/threads?id=DinoNuggies45
is this just AI output generated to apear engaged while launching YetAnother beachhead account to gang upvote submissions, influence voting, etc.
adwawdawd
sustech
hardwaresofton
> 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.
mariusor
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 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 (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.