26 ms·

Asterinas: A new Linux-compatible kernel project

224 points by howtofly 1y ago

DinoNuggies45 1y ago
[flagged]
- defrost 1y ago
  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 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.
  - DinoNuggies45 1y ago
    No I was being genuine…I’m new to code and don’t have a clue on how to make something like that. Was it not coded at all? I use docs and can never get it to look like that. Oh and what’s a “beachhead”?
hardwaresofton 1y ago
> 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 1y ago
  It would help everyone if you'd actually tell us in which way they're doing that.
  - immibis 1y ago
    I think they're referring to the fact that projects mostly get adopted or not based on socio-political processes such as marketing, and only rarely on the actual merits of the project such as performance.
yjftsjthsd-h 1y ago
> 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
adwawdawd 1y ago
[flagged]
lifty 1y ago
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.
- tatetian16 1y ago
  As a relatively new kernel, Asterinas still has a lot of rough edges for general-purpose use. That said, if the goal is to run targeted, real-world services efficiently and reliably, the gap is not that large—I believe we can reach that milestone within a year. 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.
  - GardenLetter27 1y ago
    What about DRM, ALSA, etc.? - I think these are the main blockers for people testing it out on home machines.
lubsch 1y ago
Makes me think of https://drewdevault.com/2024/08/30/2024-08-30-Rust-in-Linux-revisited.html https://drewdevault.com/2024/08/30/2024-08-30-Rust-in-Linux-... (HN discussion: https://news.ycombinator.com/item?id=41404733 https://news.ycombinator.com/item?id=41404733)
vbezhenar 1y ago
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.
- plingbang 1y ago
  A very close idea was jokingly suggested in The Birth & Death of JavaScript[1] at 18:07 (rewind to 14:14 for more context) [1]: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
karmakaze 1y ago
Seems like a great idea. We have so much software invested that alternative substrates could yield great benefits or at least alternatives when needed for less technical reasons. Kinda reminds me of kFreeBSD and of course GNU/Hurd.
weinzierl 1y ago
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.
- leeter 1y ago
  > 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.
- tatetian16 1y ago
  > 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-haibo https://www.usenix.org/conference/osdi24/presentation/chen-h...
  - reactordev 1y ago
    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.
alt187 1y ago
I hope this project succeeds. Rust kernel-level development deserves far better than the current state of affairs.
- guilhas 1y ago
  Maybe c/c++ development deserves a better replacement than rust
Toritori12 1y ago
What should be the name for these kind of things? *nux?
mdtrooper 1y ago
It is licensed under MPL. Well, there is best licenses such as GPLv3.
- miniBill 1y ago
  The have the rationale for why they picked MPL in their documentation. I don't love the choice, but I can see the reasons behind it.
deleted 1y ago
[deleted]

224 points by howtofly 1y ago

DinoNuggies45 1y ago

[flagged]

defrost 1y ago
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 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.
- DinoNuggies45 1y ago
  No I was being genuine…I’m new to code and don’t have a clue on how to make something like that. Was it not coded at all? I use docs and can never get it to look like that. Oh and what’s a “beachhead”?

hardwaresofton 1y ago

> 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 1y ago
It would help everyone if you'd actually tell us in which way they're doing that.
- immibis 1y ago
  I think they're referring to the fact that projects mostly get adopted or not based on socio-political processes such as marketing, and only rarely on the actual merits of the project such as performance.

yjftsjthsd-h 1y ago

> 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

adwawdawd 1y ago

[flagged]

lifty 1y ago

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.

tatetian16 1y ago
As a relatively new kernel, Asterinas still has a lot of rough edges for general-purpose use. That said, if the goal is to run targeted, real-world services efficiently and reliably, the gap is not that large—I believe we can reach that milestone within a year. 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.
- GardenLetter27 1y ago
  What about DRM, ALSA, etc.? - I think these are the main blockers for people testing it out on home machines.

lubsch 1y ago

Makes me think of https://drewdevault.com/2024/08/30/2024-08-30-Rust-in-Linux-revisited.html https://drewdevault.com/2024/08/30/2024-08-30-Rust-in-Linux-... (HN discussion: https://news.ycombinator.com/item?id=41404733 https://news.ycombinator.com/item?id=41404733)

vbezhenar 1y ago

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.

plingbang 1y ago
A very close idea was jokingly suggested in The Birth & Death of JavaScript[1] at 18:07 (rewind to 14:14 for more context) [1]: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...

karmakaze 1y ago

Seems like a great idea. We have so much software invested that alternative substrates could yield great benefits or at least alternatives when needed for less technical reasons. Kinda reminds me of kFreeBSD and of course GNU/Hurd.

weinzierl 1y ago

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.

leeter 1y ago
> 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.
tatetian16 1y ago
> 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-haibo https://www.usenix.org/conference/osdi24/presentation/chen-h...
- reactordev 1y ago
  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.

alt187 1y ago

I hope this project succeeds. Rust kernel-level development deserves far better than the current state of affairs.

guilhas 1y ago
Maybe c/c++ development deserves a better replacement than rust

Toritori12 1y ago

What should be the name for these kind of things? *nux?

mdtrooper 1y ago

It is licensed under MPL. Well, there is best licenses such as GPLv3.

miniBill 1y ago
The have the rationale for why they picked MPL in their documentation. I don't love the choice, but I can see the reasons behind it.

deleted 1y ago

[deleted]