r/rust • • 21h ago

🛠️ project Asterinas 0.19.0: a Linux-compatible kernel in Rust, now with a type-checked device model, a hypervisor in safe Rust, and an AI reviewer that cites Rust guidelines

https://asterinas.github.io/2026/10/13/announcing-asterinas-0.19.0.html
71 Upvotes

23 comments sorted by

19

u/tatetian 21h ago edited 21h ago

Maintainer here. Asterinas is a Linux-ABI-compatible kernel in Rust. The architecture we call a framekernel: a small framework crate, OSTD, holds all the unsafe code, and the kernel above it is #![deny(unsafe_code)]. Each release tries to push more kernel work into the safe half. Three examples from 0.19.0:

  1. A device model with the rules in the types. A kernel tracks every device, its driver, and what it exposes to user space. Linux does this in C with a generic struct device and enforces the rules by review. The new aster-device crate does it in safe Rust: buses, drivers, classes and attributes are generic over what they belong to, so a driver on the wrong bus or an attribute on the wrong kind of device is a compile error. No downcasting anywhere.
  2. An OSTD extension for writing a hypervisor in safe Rust. OSTD now owns the Intel VMX mechanism: VMCS, EPT-backed guest memory and the guest-host switch——which may involve unsafe Rust. Everything above that is policy in safe Rust. The Asterinas Book gives an example of writing a minimal hypervisor in about 100 lines of safe Rust. We plan to add in the next release a full KVM-compatible hypervisor in safe Rust on top of the new OSTD hypervisor API.
  3. An AI reviewer that cites Rust guidelines. We reorganized our coding guidelines into 81 with stable short names, many Rust-specific (rust-type-invariants, enum-over-dyn, narrow-visibility, justify-unsafe-use). The aster-code-review skill cites one for every subjective comment, tries to refute each comment before keeping it, and is tuned against a benchmark of 138 defects mined from our own PR history.

Also new: a DRM subsystem (Xorg and Mesa, with two 3D games on video), AArch64 as the fourth architecture, and Asterinas building and booting Asterinas. The repo passed 100 contributors and 250K lines this cycle, about 200K of them Rust.

Happy to answer questions about the project, its type-level tricks or the unsafe boundary in OSTD.

2

u/SupermarketAntique32 20h ago

I don’t see any benchmarks on the README, curious about the performance.

8

u/tatetian 20h ago

Asterinas runs various performance benchmarks every night. You can find it here: https://asterinas.github.io/benchmark/x86-64/. On LMbench, the average performance of Asterinas relative to Linux is 0.86 (the higher, the better). Compared to Linux, Asterinas still has some performance gaps, but they are due to relatively immature implementation, not Rust or the framekernel architecture.

5

u/Psionikus 18h ago

I'm sure a lot of people will ask, but as a general rule, I think performance is a question from people who don't understand that a "high performance kernel" is missing a ton of correctness guardrails and security features that slow things down. Not just turned off, unsupported.

A young project doesn't owe us maturity. A user who doesn't understand how features and correctness cost speed doesn't deserve to judge the author or the project.

Nonetheless, I think mentioning that speed is the cost of correctness is an important framing to any answers. At least the honest user might say, "oh yeah" when they realize that turning off all the guard rails or not implementing them tends to result in a "faster" kernel, so the question, while seeking speed, is probably instead motivating a lack of correctness in near proportions.

1

u/theAndrewWiggins 12h ago

I wonder if it's possible to have performance security via something like theseus, though I imagine it's vulnerable to spectre style attacks.

I would be very curious to see if os/compiler/program co-design could solve that problem. Imagine something like the Mill processor (which is fully statically scheduled) alongside something like theseus.

4

u/Hosein_Lavaei 20h ago

Does kernel modules work? If they do, in theory we can bring all linux drivers as a module and add them

12

u/tatetian 20h ago

Asterinas has a component system: a component is basically a Linux kernel module, but it can only be turned on/off statically at build time, rather than loaded dynamically. One key blocker for loading them dynamically is that Rust does not have a stable ABI.

2

u/seftontycho 13h ago

The “stabby” crate might help here

1

u/CommunismDoesntWork 8h ago

Fyrox figured out hot reloading, could y'all do something like that?

2

u/[deleted] 20h ago edited 20h ago

[removed] — view removed comment

6

u/xantiema 17h ago

People hate on AI-assisted development, but I genuinely hope this project is a success. Not only because it would attract future programmers to a Rust-oriented operating ecosystem, but also because Linux is long in the tooth and lost in its ways

4

u/Bruno_Wallner 13h ago

How has linux lost its ways?

-11

u/xantiema 13h ago

They have quite an agressive attitude towards eager developers due to the ever-increasing stress the maintainers are under - this begun a few years prior to the AI patchapocalypse. Experience comes with age, but the corrolation isn't always as strong as some would argue. At least they came around to Rust so there is that I guess.

3

u/jking13 12h ago

Yes, but the syscall layer being the effective ABI was always a bad design choice and a result of Linux being a kernel and not a kernel + base userland. There's decades of cruft in there (go look at all the options of futex, look at how many are actually useful in practice, and how many were poorly thought out ideas that are still around because there's some random version of some libc somewhere still using it), and the result is rather bloated syscall interface because you can't break userland.

Other OSes (including Windows) that require you to use libc (or some other userland library as it's ABI) means you move bits to userland for sanity or better design without breaking things.

Keeping that is perpetuating one of the worst aspects of Linux.

-2

u/Jmc_da_boss 20h ago edited 20h ago

Mod approvals queue PLEASE

I don't want this slop shit to enter my eyeballs

Edit: apparently not slop? That title is still horrific tho

19

u/Most_Strike_93 20h ago

No, it is an old project, started two years ago. Just the post is written in wrong way. I also mistake at the first time. Then I enter and read the project. It is a good project.

-10

u/Sha1rholder 20h ago

What kind of hilarious project did you write that made you think the project was slop?

1

u/W61k3r 20h ago

Nifty, I didn't know this existed.

-12

u/Ok-Zookeepergame4391 20h ago

Seems weird to prioritize x86. Should focus on arm64.

5

u/Psionikus 18h ago

Seems like you should focus on Arm64

2

u/xantiema 18h ago

One of the wildest takes yet.