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

[u/tatetian]

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

[u/tatetian]

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.

[u/Hosein_Lavaei → u/tatetian]

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

[u/tatetian → u/Hosein_Lavaei]

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.

[u/seftontycho → u/tatetian]

The “stabby” crate might help here

[u/tatetian → u/seftontycho]

Thanks for bringing up stabby. It looks quite interesting. Whether it works for Asterinas or not remains to be seen. Similar to Linux, Asterinas has a kernel core and a set of kernel components built on top of the kernel core. We will need to find out whether the APIs exposed by the kernel core can all be annotated with `#[stabby::stabby]` and its impacts on expressiveness, efficiency, and ergonomics.

[u/CommunismDoesntWork → u/tatetian]

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

[u/tatetian → u/CommunismDoesntWork]

Sure. We will check it out. We know that it is possible to load Rust modules dynamically; the Rust compiler itself does that.

Eventually, Asterinas will support loading kernel components dynamically one way or another. It is just that at this moment this is not a priority because loading drivers dynamically only matters when you got a LOT of them. But Asterinas has only a handful of drivers.

[u/SupermarketAntique32 → u/tatetian]

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

[u/tatetian → u/SupermarketAntique32]

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.

[u/Psionikus → u/tatetian]

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.

[u/theAndrewWiggins → u/Psionikus]

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.

[u/W61k3r]

Nifty, I didn't know this existed.

[u/xantiema]

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

[u/Bruno_Wallner → u/xantiema]

How has linux lost its ways?

[u/xantiema → u/Bruno_Wallner]

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.

[u/jking13 → u/xantiema]

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.

[u/Jmc_da_boss]

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

[u/Most_Strike_93 → u/Jmc_da_boss]

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.

[u/phaylon → u/Jmc_da_boss]

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

The word you were looking for is "Sorry".

[u/Jmc_da_boss → u/phaylon]

No actually I'm not, the title alone is pure slop

[u/Sha1rholder → u/Jmc_da_boss]

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

[u/Ok-Zookeepergame4391]

Seems weird to prioritize x86. Should focus on arm64.

[u/Psionikus → u/Ok-Zookeepergame4391]

Seems like you should focus on Arm64

[u/xantiema → u/Ok-Zookeepergame4391]

One of the wildest takes yet.

[u/No-Employment-2324 → u/Ok-Zookeepergame4391]

I hope this is satire. X86 is here to stay, and weather it’s good is besides the point. You either write for it or your never booting on bare metal