The Asterinas community is happy to announce a new version of Asterinas, 0.19.0!

Two milestones first. More than 100 people have now contributed to the Asterinas repository, and the codebase has passed 250,000 lines, about 200,000 of them Rust. Of those contributors, 55 worked on this release, 31 for the first time. Whether you landed a subsystem or fixed a typo, thank you.

This post covers the seven changes we think matter most. Everything else is in the full changelog.

• Graphics: Xorg and OpenGL games on a new DRM subsystem
• Arm: AArch64 as a target, Arm machines as hosts
• Secure containers: a better guest kernel for Kata-style VMs
• Virtualization: hypervisor support in OSTD
• Drivers: a Rust-native device model
• AI code review: a review skill built on our coding guidelines
• Self-hosting: Asterinas builds and boots Asterinas

Graphics: a DRM subsystem

Asterinas NixOS can now run Xorg on its standard modesetting driver, with Mesa’s software OpenGL on top, instead of the legacy framebuffer (fbdev) interface. Behind this is a new DRM (Direct Rendering Manager) subsystem, the kernel interface that modern Linux graphics stacks are built on. The new aster-drm component provides the DRM core, the device nodes under /dev/dri, GEM dumb buffers (CPU-drawn framebuffers that user space can mmap) and the KMS (kernel mode setting) objects that configure the display (#3787, #3925, #3888, #3941).

The demo video below shows two 3D games running on Asterinas NixOS:

Arm: AArch64 joins as the fourth architecture

Asterinas 0.19.0 adds AArch64 as its fourth CPU architecture, after x86-64, RISC-V and LoongArch (#3737). The port is minimal but usable. On QEMU’s virt machine it brings up the GICv3 interrupt controller, the generic timer, the PL031 RTC, the PL011 UART and virtio-mmio devices, and runs a BusyBox shell, vDSO included (#3884, #3933). AArch64 enters as a Tier 2 platform, with CI coverage still growing.

Arm machines now work as development hosts too. The Docker images are published for linux/arm64 alongside linux/amd64, and the new Nix development shell supports aarch64-linux, so an Arm laptop or server can build and run the kernel without an x86 box.

Secure containers: a better guest kernel

Asterinas can make a great guest kernel for VM-based containers such as Kata Containers and Confidential Containers. A memory-safe guest kernel removes a whole class of exploitable bugs from the sandbox. Asterinas can already serve as that guest kernel, within limits, and 0.19.0 removes several of them.

• Overlayfs, reimplemented. Container images are stacks of layers, and overlayfs presents them as one filesystem. The new implementation (#3795) adds what the old one lacked, doubling the overlayfs cases it passes in xfstests, the standard Linux filesystem test suite.
• Mount propagation and the new mount API. Mounts can now be shared, slave, private or unbindable (#3639), and the fd-based fsopen family of syscalls works (#3492). Container runtimes and newer systemd use both to set up a sandbox’s mounts.
• virtio-fs, matured. virtio-fs shares host directories with the VM. The driver gains mmap, O_DIRECT, rename, symbolic links and faster multi-page I/O, and xfstests now runs against it in CI (#3730, #3509, #3334, #3812, #3886, #3747).
• PVH boot and Firecracker. Asterinas boots via PVH, the direct-boot protocol used by QEMU, Cloud Hypervisor and Firecracker (#3765), and runs as the guest kernel of a Firecracker microVM (#3461).
• Faster TDX boot. In an Intel TDX guest, every page of memory must be accepted before the kernel can use it. Asterinas now splits that work across all vCPUs at boot instead of doing it on one (#3640), speeding up the boot process significantly on TDX.

Virtualization: hypervisor support in OSTD

A bare-metal (Type 1) hypervisor such as Xen keeps its own core small, but leans on a full OS, usually Linux in dom0, for drivers and management. Linux with KVM is convenient but puts a large C kernel in every VM’s trusted base. Asterinas aims to keep the convenience while shrinking what can go wrong: the only code that can break memory safety is OSTD, and the virtualization logic above it is safe Rust.

RFC-0003 sets the design. OSTD, the framework beneath Asterinas, owns the mechanism: virtualization hardware state, second-stage address translation and the guest-host switch. The kernel owns the policy: VM and vCPU lifecycle, memory slots, interrupt chips, device emulation and, eventually, a KVM-compatible /dev/kvm. All the code that needs unsafe lives in OSTD’s virtualization module, about 2,000 lines today, so everything above it, up to a complete hypervisor, can be safe Rust.

Asterinas 0.19.0 delivers the Intel VMX foundation: the VMX lifecycle (#3675), the VMCS (#3833), EPT-backed guest memory (#3825), the guest CPU state (#3697) and guest execution that returns each VM exit to the caller (#3860). The Book shows how to use these APIs to write a minimal hypervisor in about 100 lines of safe Rust.

Drivers: a Rust-native device model

Most of the code in a mature kernel is device drivers, so a kernel architecture has to scale in how it handles devices. User space cares too: systemd, udev and tools such as lsblk learn what hardware exists from /sys and /dev.

Asterinas 0.19.0 puts the core of a device model in place: the new aster-device component, a Rust-native counterpart of Linux’s driver core, written entirely in safe Rust (#3889). It defines buses, classes, drivers and devices as typed abstractions, so that the type system enforces what Linux enforces by convention:

• Buses and drivers. A Driver<B> can only be registered on bus B, and its on_probe receives a BusDevice<B>, which dereferences to the bus’s own device type.
• Classes and class devices. A ClassDevice<C> carries its class in its type, so a ClassObserver<C> hears only about devices of class C. An observer of the block class that scans new disks for partitions can never be handed a terminal.
• Attributes. A sysfs attribute is an Attr<D>, declared against the device type D it belongs to, and its callbacks receive a &D. An attribute of one class cannot be attached to another class’s devices, and no callback has to downcast a generic device pointer.

Registering a device is one call, and the rest follows: the model matches it with a driver and probes it, the right entries appear under /sys/, and the device node appears in /dev, thanks to the new devtmpfs (#3621).

AI code review: the aster-code-review skill

Agents make code cheap. Human review is the bottleneck that stays. To relieve the bottleneck, this release ships aster-code-review, a skill for coding agents to review a Git change or a set of files (#3483). The aster-code-review skill seeks to answer one question: how do you make an AI review like a maintainer? A maintainer makes objective calls, the clear-cut bugs, and subjective calls: does this change follow the project’s conventions? Two features let the skill do both.

• Grounded in guidelines. Every subjective call cites the Coding Guidelines, reorganized in this release around five reviewer personas into 81 guidelines with stable short names (#3416). The skill runs one pass per persona and tries to refute each comment before keeping it.
• Optimized against a benchmark. A suite of 58 review problems with 138 expected defects, almost all mined from Asterinas’s own history, measures recall. Every miss drives a change to the guidelines or the skill.

Self-hosting: Asterinas builds Asterinas

Building itself is a rite of passage for an operating system, and Asterinas 0.19.0 passes it. A new page in the Asterinas Book, Building Asterinas on Asterinas, walks through the steps: boot Asterinas NixOS in a VM, clone the repository inside it, enter the Nix development shell, run make kernel and boot the freshly built kernel in a nested QEMU VM (#3749). Nix, Cargo, rustc and QEMU all run on Asterinas along the way, which makes a self-hosted build one of the largest real-world workloads the kernel has been put through.

The Nix development shell is new in this release too. The repository now ships a Nix flake as an alternative to Docker (#3548), with the toolchain, QEMU and firmware prebuilt on Cachix. With Nix installed, three commands take a fresh clone to a booted kernel:

nix develop
make kernel
make run_kernel

Contributors

This release was made possible by contributions from 55 individuals. Thank you for your amazing work!

• Ruihan Li (145 commits)
• Chen Chengjun (52 commits)
• Jianfeng Jiang (42 commits)
• Qingsong Chen (40 commits)
• Bet4 (38 commits)
• li041 (36 commits)
• zjp (32 commits)
• Ray Lee (31 commits)
• Tao Su (30 commits)
• Linermao (24 commits)
• Marsman1996 (18 commits)
• Ruowen Qin (16 commits)
• Tate, Hongliang Tian (16 commits)
• WaterWhisperer (12 commits)
• Zhang Junyang (10 commits)
• le-monde-bleu (9 commits)
• Ya0rk (9 commits)
• co63oc (8 commits)
• Hsy-Intel (8 commits)
• volca (7 commits)
• zzj-5341 (7 commits)
• Duck Ran (6 commits)
• Endlia (6 commits)
• Halifuda (6 commits)
• harry (6 commits)
• Junrui Luo (6 commits)
• Mohammad Razeghi (6 commits)
• FallingLeavez (5 commits)
• Fan Jie (5 commits)
• Cautreoxit (4 commits)
• androidAppGuard (3 commits)
• Jia Qingtong (3 commits)
• Xinyi Yu (3 commits)
• Zhouqi Jiang (3 commits)
• Bitter127 (2 commits)
• Junjie Cao (2 commits)
• Martin Holovsky (2 commits)
• Mike Solar (2 commits)
• QcN3ep (2 commits)
• TankTechnology (2 commits)
• wangyue789 (2 commits)
• wheatfox (2 commits)
• WX Chen (2 commits)
• Zhihang Shao (2 commits)
• aiqubits (1 commit)
• Boyang Xue (1 commit)
• Haixin Xu (1 commit)
• Philipp Schuster (1 commit)
• rikosellic (1 commit)
• Shen Bowen (1 commit)
• Shi Lei (1 commit)
• Wang Yue (1 commit)
• yanchaomei (1 commit)
• YanLien (1 commit)
• 刘景宇 (1 commit)