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.
> 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.
> I think he was already well aware at that time that keeping the driver interface unstable is his moat.
Does Linus have/want a moat? He's not a tech startup founder. He's a kernel hacker who has had success beyond his wildest dreams, and whose needs will be met for the rest of his working life no matter what happens.
It seems like projection to talk about this aspect of the kernel as if it's some intentional strategy for preventing certain kinds of competition.
Prior art includes SPIN OS (Modula 3), JX OS (Java), House OS' H-Layer (Haskell), and Verve. Each one had a type-safe, memory-safe language for implementing the features. They usually wall off the unsafe stuff behind checked, function calls. Some use VM's, too.
Ignoring performance or adoption, the main weaknesses are: abstraction, gap attacks; unsafe code bypassing the whole thing; compiler or JIT-induced breakage of safety model; common, hardware failures like cosmic rays. This is still far safer than kernels and user apps in unsafe languages.
One can further improve on it by using static analysis of unsafe code, ensuring all unsafe functions respect type-safe/memory-safe interfaces, compilers that preserve abstraction safety during integration, and certified compilers for individual components. We have production tools for all except secure, abstract compilation which (a) is being researched and (b) can be checked manually for now.
> 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.
On the other hand, running on real hardware is less important if none of your hardware is real!
98% of Linux I interact with is running virtualized: on my desktop/laptop systems it’s either Virtualbox full-screened so I can use Windows for drivers, or a headless VM managed by Docker.app on my Mac. All my employer’s production workloads are AWS virtual machines.
My only Linux bare metal hardware is a home server, which I’m planning to retire soon-ish, replaced by a VM on an ebay Mac mini to reduce power bill & fan noise.
If someone can make a Linux compatible kernel that’s more secure and just as performant, it’s much easier these days to imagine a large new user base adopting it despite a dearth of drivers.
I have written device drivers for, literally, decades now.
Its the old guys who write the best drivers, naturally.
For me, Asterinas represents a refreshing way to approach some thorny problems in the embedded space, in which embedded-Linux on ARM, RISC-V and MIPS is a viable, economically-speaking, platform for a great deal of industry.
While Asterinas is really sexy, if this same approach were taken for, say, FreeRTOS as well along the way .. then there could at least, also, be "on one hands" worth of operating systems, abstracted, in the "lets just use rust' camp ..
> 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?
> 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.
> 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.
> 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.
> 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.
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.
> 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.
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.
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.
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.
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|8 months ago
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.
tatetian16|8 months ago
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...
pxc|8 months ago
Does Linus have/want a moat? He's not a tech startup founder. He's a kernel hacker who has had success beyond his wildest dreams, and whose needs will be met for the rest of his working life no matter what happens.
It seems like projection to talk about this aspect of the kernel as if it's some intentional strategy for preventing certain kinds of competition.
nickpsecurity|8 months ago
Ignoring performance or adoption, the main weaknesses are: abstraction, gap attacks; unsafe code bypassing the whole thing; compiler or JIT-induced breakage of safety model; common, hardware failures like cosmic rays. This is still far safer than kernels and user apps in unsafe languages.
One can further improve on it by using static analysis of unsafe code, ensuring all unsafe functions respect type-safe/memory-safe interfaces, compilers that preserve abstraction safety during integration, and certified compilers for individual components. We have production tools for all except secure, abstract compilation which (a) is being researched and (b) can be checked manually for now.
leeter|8 months ago
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.
jitl|8 months ago
98% of Linux I interact with is running virtualized: on my desktop/laptop systems it’s either Virtualbox full-screened so I can use Windows for drivers, or a headless VM managed by Docker.app on my Mac. All my employer’s production workloads are AWS virtual machines.
My only Linux bare metal hardware is a home server, which I’m planning to retire soon-ish, replaced by a VM on an ebay Mac mini to reduce power bill & fan noise.
If someone can make a Linux compatible kernel that’s more secure and just as performant, it’s much easier these days to imagine a large new user base adopting it despite a dearth of drivers.
helpfulContrib|8 months ago
Its the old guys who write the best drivers, naturally.
For me, Asterinas represents a refreshing way to approach some thorny problems in the embedded space, in which embedded-Linux on ARM, RISC-V and MIPS is a viable, economically-speaking, platform for a great deal of industry.
While Asterinas is really sexy, if this same approach were taken for, say, FreeRTOS as well along the way .. then there could at least, also, be "on one hands" worth of operating systems, abstracted, in the "lets just use rust' camp ..
exe34|8 months ago
It's basically like npm update, at the kernel level.
digdugdirk|8 months ago
yjftsjthsd-h|8 months ago
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.
tatetian16|8 months ago
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.
josephg|8 months ago
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.
rwmj|8 months ago
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.
kelnos|8 months ago
It's an unfortunate overloading of terminology that you entirely reasonably interpreted according to the more common usage.
ulrikrasmussen|8 months ago
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.
bandrami|8 months ago
pjmlp|8 months ago
vbezhenar|8 months ago
plingbang|8 months ago
[1]: https://www.destroyallsoftware.com/talks/the-birth-and-death...
lubsch|8 months ago
lifty|8 months ago
tatetian16|8 months ago
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.
hardwaresofton|8 months ago
Somewhat comforting to see deeply technical people still misconstruing why approaches/projects don't get adopted.
mariusor|8 months ago
mdtrooper|8 months ago
miniBill|8 months ago
karmakaze|8 months ago
Toritori12|8 months ago
unknown|8 months ago
[deleted]
adwawdawd|8 months ago
[deleted]
DinoNuggies45|8 months ago
[deleted]
defrost|8 months ago
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.
alt187|8 months ago
guilhas|8 months ago