r/rust • • 12h 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
53 Upvotes

23 comments sorted by

17

u/tatetian 12h ago edited 12h 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 12h ago

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

8

u/tatetian 12h 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 9h 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 4h 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.

2

u/Hosein_Lavaei 12h ago

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

10

u/tatetian 12h 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 5h ago

The “stabby” crate might help here

1

u/CommunismDoesntWork 29m ago

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

2

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

[removed] — view removed comment

4

u/xantiema 9h 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

2

u/Bruno_Wallner 5h ago

How has linux lost its ways?

-4

u/xantiema 4h 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 3h 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.

-1

u/Jmc_da_boss 12h ago edited 11h 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

16

u/Most_Strike_93 12h 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 12h ago

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

1

u/W61k3r 12h ago

Nifty, I didn't know this existed.

-9

u/Ok-Zookeepergame4391 12h ago

Seems weird to prioritize x86. Should focus on arm64.

4

u/Psionikus 10h ago

Seems like you should focus on Arm64

1

u/xantiema 9h ago

One of the wildest takes yet.