RustROS · 2026-10-29 · 地址空间

内核搬到高半区：固定地址的程序能跑了

进程拿到整个低半区，Go 默认编译的程序和 Debian 的 python3 在 RustROS 容器里照常运行。内核同时加上了常规的内存保护。按用户确认的设计（docs/user-address-space-design.md）完成，四项决定都按建议。

内核改动有，需重启一次PE 文件 401,408 → 405,504 字节（+4 KiB）

接口改动有Hw 的设备地址和 DMA 调用；所有模块重装

回归测试通过260 个单元测试；KVM 测试见下

转发18.9 Gbit/s · 366 kppsTCP 单流 / 64 字节单流，和之前持平

问题为什么以前跑不了

以前内核用"虚拟地址 = 物理地址"的映射占着低 64 TiB，进程只能从 64 TiB 起放东西。按固定地址链接的程序（Go 默认编译、Debian 的 python3）要装在 0x400000，正好落在内核那块里，所以装不进去。python3 自己的安装脚本也要调用 python3，所以 apt-get install python3 本身就失败。

布局现在的地址空间

范围	用途
0x10000 – 0x7FFF_FFFF_F000	进程自己的（低半区整个）
0xFFFF_8000_0000_0000	线性映射：全部内存，不可执行
0xFFFF_C000_0000_0000	设备寄存器，按需映射，不缓存
0xFFFF_D000_0000_0000	模块，按页映射：代码只读、数据不可执行
0xFFFF_FFFF_8000_0000	内核本身：代码只读，其余不可执行

所有常量都在 crates/api/src/layout.rs 一处。系统调用的开销和以前一样：内核的高半区在每个地址空间里都有，不切页表。

一起做的为以后少留后患

DMA 接口按 IOMMU 设计：驱动交给设备的地址只来自 Hw::dma_alloc / Hw::dma_map；map_device 返回寄存器的地址。以后有 IOMMU 时驱动不用改。
内存保护：开了 NX、内核 W^X，CPU 支持时开 SMEP/SMAP。内核只经线性映射读写进程内存，进程完全看不到内核的页。
模块区：模块不再放在可执行的堆里，按页映射，代码只读。
栈：各个栈下面留一页不映射；双重错误、NMI、机器检查各有独立的栈（IST）。栈溢出时报 "kernel stack overflow"，不会悄悄重启。
预留：vsyscall 页不映射，老程序调用时得到 SIGSEGV，和 Linux 的 vsyscall=none 一样。
进程地址随机化：和 Linux 一样随机化栈、mmap 区（ld.so 在里面）、PIE 程序和堆的起点。调试时用 aslr=off 关掉（命令行或启动状态）。
UEFI：uefi.rs 没改。PE stub 调用它时给它一份页表，里面有固件自己的映射，加上高半区的内核。

验收面板要的几项

检查	Debian 13（debian_test）	LXC Debian 13 cloud，路由容器（node_test）
Go 默认编译，静态（8 个 goroutine、定时器、64 MiB、GC）	通过	通过
Go 默认编译，cgo（glibc 的 ld.so）	通过	通过
`apt-get install -y python3`	通过	通过
`python3 -c 'import ssl, json, sqlite3'`	通过	通过
`pip --version`（python3-pip，不装推荐包）	pip 25.1.1	通过

新的 lowaddr 测试程序（proc_test）是真正装在 0x400000 的固定地址程序，13 项检查全部通过：MAP_FIXED 映射 0x10000 和 0xc000000000、地址提示按原样给、0x10000 以下映射不了；读原恒等映射的地址、内核本身、线性映射、vsyscall 页都会被 SIGSEGV 终止；两次运行的栈和 mmap 地址不同。

顺带修好测试里发现的问题

脚本第一行 #! /bin/sh -e（#! 后面有空格）：以前把 "/bin/sh -e" 整个当成程序名，dpkg 执行 readline-common 的安装脚本时报 ENOENT。现在和 Linux 一样处理（linux 模块）。
服务退回引导版时的释放后使用：拆下已安装的模块管理器、存储或驱动时，模块的代码先被释放，它创建的对象后析构。以前释放的内存还读得到，所以没暴露；现在模块的页被取消映射，hot_test 就崩了。已改成先析构对象、再释放代码（services.rs）。

测试结果

整套 KVM 回归：hot_test 的两个变体都在上面那个释放后使用的问题上失败，修好后单独重跑都通过；docker 在负载下 apt 超时（已知的不稳定），单独重跑通过。
所有启动方式都通过：BIOS、UEFI、UEFI 直接启动、安装 ISO、迁移。
转发：TCP 单流 18.86 Gbit/s，64 字节 365.8 kpps。

还有的已知问题（不是这次引入的）：私有文件映射是整个复制进内存的。apt 会映射约 80 MB 的包缓存，所以在只有 256 MiB 内存的测试机里 fork 会失败（"Failed to fork"）。Debian 测试机现在给 1 GiB，客户容器的内存比这大得多。以后可以改成从页缓存按需读入。

发布影响

内核改了，部署时每台机器重启一次。
接口改了，所有模块都要重装（rustros-update.py deploy 会处理）。
回滚：旧内核继续用旧模块。