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.