Asterinas 星绽 0.19.0 发布：七项重要更新

星绽（Asterinas）社区高兴地宣布，新版本 0.19.0 正式发布！

先说两个里程碑。为星绽代码仓库做出过贡献的人数已经超过 100 位；代码总量突破 25 万行，其中 Rust 代码约 20 万行。本次发布有 55 位贡献者参与，其中 31 位是第一次向星绽提交代码。无论你贡献的是一个新功能，还是修了一个错别字，都向你道一声：感谢！

这篇文章只讲我们认为最重要的七项变化，其余内容请见完整更新日志。

• 图形：全新的 DRM 子系统，Xorg 和 OpenGL 游戏跑起来了

• ARM：AArch64 成为第四个目标架构，ARM 机器也能当开发机

• 安全容器：一个更称职的客户机内核

• 虚拟化：OSTD 加入 hypervisor 支持

• 驱动：Rust 原生的设备模型

• AI 代码评审：一个建立在编码规范之上的评审技能

• 自举：用星绽 NixOS 构建并启动星绽内核

图形：全新的 DRM 子系统

星绽 NixOS 上的 Xorg 现在可以使用标准的 modesetting 驱动，上面再跑 Mesa 的软件 OpenGL，不必再走老旧的 framebuffer（fbdev）接口。背后是新加入的 DRM（Direct Rendering Manager）子系统，也就是现代 Linux 图形栈赖以构建的那一层内核接口。新的 aster-drm 组件提供了 DRM 核心、/dev/dri 下的设备节点、GEM dumb buffer（由 CPU 绘制、可供用户态 mmap 的帧缓冲），以及用来配置显示输出的 KMS（kernel mode setting）对象（#3787、#3925、#3888、#3941）。

下面的演示视频展示了两款 3D 游戏在星绽 NixOS 上的运行效果：
https://asterinas.github.io/assets/videos/2026-10-10-v0.19.0-3d-gaming-demo.mp4

ARM：AArch64 成为第四个架构

星绽 0.19.0 新增了 AArch64 支持，这是继 x86-64、RISC-V 和 LoongArch 之后的第四个 CPU 架构（#3737）。这个移植还很精简，但已经可用。在 QEMU 的 virt 虚拟机上，它能驱动 GICv3 中断控制器、通用定时器、PL031 RTC、PL011 串口和 virtio-mmio 设备，并运行一个带 vDSO 的 BusyBox shell（#3884、#3933）。AArch64 以 Tier 2 平台的身份加入，CI 覆盖还在逐步补齐。

ARM 机器现在也能当开发机了。Docker 镜像同时提供 linux/arm64 和 linux/amd64 两个版本，新的 Nix 开发环境也支持 aarch64-linux，所以一台 ARM 笔记本或服务器就能构建并运行内核，不用再找一台 x86 机器。

安全容器：一个更称职的客户机内核

星绽近期的部署目标，是为 Kata Containers 和机密容器（Confidential Containers）这类基于虚拟机的容器充当客户机内核。一个内存安全的客户机内核，能把一整类可被利用的漏洞挡在沙箱之外。星绽现在已经可以在一定限制下承担这个角色，0.19.0 又去掉了其中的几条限制。

• overlayfs 重写。 容器镜像由多层叠成，overlayfs 把它们呈现为一个文件系统。新实现（#3795）补上了旧实现缺失的多项功能，在 Linux 标准文件系统测试套件 xfstests 的 overlayfs 用例上，通过数量也因此翻了一倍多。

• 挂载传播与新的挂载 API。 挂载点现在可以设为 shared、slave、private 或 unbindable（#3639），基于文件描述符的 fsopen 系列系统调用也已经可用（#3492）。容器运行时和新版 systemd 都靠这两样东西来布置沙箱里的挂载。

• virtio-fs 更成熟。 virtio-fs 用来把宿主机目录共享给虚拟机。驱动新增了 mmap、O_DIRECT、rename、符号链接和更快的多页 I/O，xfstests 也已经在 CI 里对它跑起来了（#3730、#3509、#3334、#3812、#3886、#3747）。

• PVH 启动与 Firecracker。 星绽支持通过 PVH 启动，这是 QEMU、Cloud Hypervisor 和 Firecracker 共用的直接启动协议（#3765），并且能作为 Firecracker microVM 的客户机内核运行（#3461）。

• TDX 启动更快。 在 Intel TDX 客户机里，每一页内存都要先经过“接受”（accept）才能被内核使用。星绽现在把这项工作分摊到所有 vCPU 上并行完成，而不是由一个 CPU 包办（#3640），这大幅缩短了星绽在多核 TDX 虚拟机上的启动时间。

虚拟化：OSTD 加入 hypervisor 支持

Xen 这类裸机（Type 1）hypervisor 自身的核心很小，但驱动和管理要依赖一个完整的操作系统，通常是跑在 dom0 里的 Linux。Linux 加 KVM 用起来方便，代价是把一个庞大的 C 语言内核放进了每台虚拟机的可信基础里。星绽想保留这份方便，同时缩小可能出错的范围：唯一能破坏内存安全的代码只有 OSTD，它之上的虚拟化逻辑全部是安全 Rust。

RFC-0003 提出了 OSTD 的 hypervisor 扩展。星绽底层的框架 OSTD 负责“机制”：虚拟化硬件状态、二级地址转换，以及客户机与宿主机之间的切换。内核负责“策略”：虚拟机和 vCPU 的生命周期、内存槽、中断芯片、设备模拟，以及将来与 KVM 兼容的 /dev/kvm。所有需要 unsafe 的代码都集中在 OSTD 的虚拟化模块里，目前约 2000 行，因此它之上的一切，直到一个完整的 hypervisor，都可以用安全 Rust 来写。

0.19.0 交付了 Intel VMX 的基础设施：VMX 生命周期（#3675）、VMCS（#3833）、基于 EPT 的客户机内存（#3825）、客户机 CPU 状态（#3697），以及把每一次 VM exit 交还给调用者的客户机执行机制（#3860）。星绽文档演示了如何用这些 API、以大约 100 行安全 Rust 写出一个最小的 hypervisor。

驱动：Rust 原生的设备模型

一个成熟的内核里，大部分代码是设备驱动，所以内核架构必须在设备管理这件事上撑得住规模。用户态同样在意这件事：systemd、udev 和 lsblk 这类工具，都是从 /sys 和 /dev 得知机器上有哪些硬件。星绽 0.19.0 搭起了设备模型的核心，也就是新的 aster-device 组件。它对应 Linux 的 driver core，但完全用安全 Rust 写成（#3889）。它把总线、类、驱动和设备定义成带类型的抽象，让 Linux 靠约定来保证的事情，改由类型系统来保证：

• 总线与驱动。Driver<B> 只能注册到总线 B 上，它的 on_probe 收到的是 BusDevice<B>，解引用后就是这条总线自己的设备类型。PCI 驱动可以像读普通字段那样读 dev.vendor_id，而 Linux 驱动拿到的是泛化的 struct device *，得靠 container_of 转回去。

• 类与类设备。ClassDevice<C> 把所属的类写在类型里，所以 ClassObserver<C> 只会收到类 C 的设备通知。一个监听块设备类、负责扫描新磁盘分区的观察者，永远不会被塞进一个终端设备。

• 属性。 sysfs 属性是 Attr<D>，针对它所属的设备类型 D 声明（D 可以是 BusDevice<B>，也可以是 ClassDevice<C>），回调函数拿到的是 &D。一个类的属性不可能挂到另一个类的设备上，回调里也不需要对泛化的设备指针做向下转型。

注册设备只需一次调用，剩下的事自动完成：设备模型为它匹配驱动并探测，/sys/devices、/sys/bus、/sys/class 和 /sys/dev 下出现对应条目，/dev 里出现设备节点，由新的 devtmpfs 负责维护（#3621）。

AI 代码评审：aster-code-review 技能

智能体让写代码变得便宜，但人工评审仍是绕不过去的瓶颈。为了缓解这个瓶颈，本次发布带来了 aster-code-review，一个用来评审一次 Git 变更或一组文件的技能（#3483）。它要回答的问题只有一个：怎样让 AI 像维护者一样做评审？维护者会做两种判断：客观判断，也就是明确无误的 bug；主观判断，也就是这个改动是否符合项目的约定。两项设计让这个技能同时具备这两种能力。

• 以编码规范为依据。 每一条主观判断都引用《编码规范》；本次发布把规范按五种评审者角色重新组织为 81 条，每条都有稳定的短名称（#3416）。技能按角色逐一评审，并在保留每条意见之前先尝试反驳它。

• 用基准测试打磨。 一套 58 道评审题、138 处预期缺陷的基准测试，几乎全部取材于星绽自己的历史，用来衡量召回率。每一次漏检，都会反过来推动规范或技能本身的改进。

自举：用星绽 NixOS 构建并启动星绽内核

能构建自己，是一个操作系统的成人礼，星绽 0.19.0 通过了这一关。星绽文档 新增了一页《在星绽上构建星绽》，把步骤讲了一遍：在虚拟机里启动星绽 NixOS，在里面克隆代码仓库，进入 Nix 开发环境，执行 make kernel，再在嵌套的 QEMU 虚拟机里启动刚编译出来的内核（#3749）。这一路上，Nix、Cargo、rustc 和 QEMU 全部运行在星绽之上，一次自举构建也因此成了这个内核经历过的最大的真实负载之一。

Nix 开发环境也是本次新增的。代码仓库现在提供一个 Nix flake，作为 Docker 之外的另一种开发环境（#3548），工具链、QEMU 和固件都已经在 Cachix 上预先构建好。装好 Nix 之后，三条命令就能从一份新克隆的代码走到一个启动起来的内核：

nix develop
make kernel
make run_kernel

贡献者

本次发布由 55 位贡献者共同完成。感谢大家出色的工作！

• Ruihan Li（145 次提交）

• Chen Chengjun（52 次提交）

• Jianfeng Jiang（42 次提交）

• Qingsong Chen（40 次提交）

• Bet4（38 次提交）

• li041（36 次提交）

• zjp（32 次提交）

• Ray Lee（31 次提交）

• Tao Su（30 次提交）

• Linermao（24 次提交）

• Marsman1996（18 次提交）

• Ruowen Qin（16 次提交）

• Tate, Hongliang Tian（16 次提交）

• WaterWhisperer（12 次提交）

• Zhang Junyang（10 次提交）

• le-monde-bleu（9 次提交）

• Ya0rk（9 次提交）

• co63oc（8 次提交）

• Hsy-Intel（8 次提交）

• volca（7 次提交）

• zzj-5341（7 次提交）

• Duck Ran（6 次提交）

• Endlia（6 次提交）

• Halifuda（6 次提交）

• harry（6 次提交）

• Junrui Luo（6 次提交）

• Mohammad Razeghi（6 次提交）

• FallingLeavez（5 次提交）

• Fan Jie（5 次提交）

• Cautreoxit（4 次提交）

• androidAppGuard（3 次提交）

• Jia Qingtong（3 次提交）

• Xinyi Yu（3 次提交）

• Zhouqi Jiang（3 次提交）

• Bitter127（2 次提交）

• Junjie Cao（2 次提交）

• Martin Holovsky（2 次提交）

• Mike Solar（2 次提交）

• QcN3ep（2 次提交）

• TankTechnology（2 次提交）

• wangyue789（2 次提交）

• wheatfox（2 次提交）

• WX Chen（2 次提交）

• Zhihang Shao（2 次提交）

• aiqubits（1 次提交）

• Boyang Xue（1 次提交）

• Haixin Xu（1 次提交）

• Philipp Schuster（1 次提交）

• rikosellic（1 次提交）

• Shen Bowen（1 次提交）

• Shi Lei（1 次提交）

• Wang Yue（1 次提交）

• yanchaomei（1 次提交）

• YanLien（1 次提交）

• 刘景宇（1 次提交）

---

星绽是一个用 Rust 编写、兼容 Linux ABI 的框内核（framekernel）操作系统，致力于在保持高性能的同时，提供更强的内存安全与可靠性保障。欢迎访问我们的 GitHub 仓库，给我们点亮一颗 Star，或加入社区一起共建！