uutils - Ubuntu 26.10 完成用 Rust 实现替换 GNU coreutils

Ubuntu 引入 Rust 已不再是孤立实验。Ubuntu 26.10 完成了向基于 Rust 的 coreutils 的切换，此前在 Ubuntu 26.04 LTS 中被暂缓的 cp、mv 和 rm 也改由 uutils 提供。Canonical 同时还在推进 NTP、压缩库等系统组件的 Rust 实现。

Jon Seager 表示，4 月到 10 月之间发生变化的是大量额外测试，以及一批重要缺陷修复。宣布推进迁移之前，他联系了 uutils 主要维护者 Sylvestre Ledru，确认项目是否准备好，以及支撑这次切换还需要什么。Canonical 为此资助了 Ledru 和支持维护者，并资助了独立安全审计。针对 rust-coreutils 的外部审计分两轮进行，共发现 113 个问题，其中不少是 TOCTOU（time of check, time of use）。这些修复没能赶在 Ubuntu 26.04 LTS 发布前完成，因此当时搁置了 cp、mv 和 rm；修复进入上游后，才有信心在 26.10 中切换。不兼容和缺陷仍然会有。26.10 虽是 interim 版本，但鉴于 coreutils 的基础地位，Canonical 承诺把 uutils coreutils 的新版本回移植到 Ubuntu 26.04 LTS，并让用户可以方便地切回 GNU 实现。

Seager 对审计结果并不意外：与 GNU coreutils 相比，uutils 所处阶段更早。它被构建成一个统一二进制，再通过符号链接提供各个工具，因此一处修复常常能同时覆盖多个工具。不少问题属于安全缺陷，但并非内存破坏；只依靠 Rust 的内存安全，并不能得到完整的正确性或整体安全性。

是否就绪，主要依据 Ubuntu 自身的构建和测试。初次切换时，若干阻塞缺陷曾导致无法构建 Ubuntu，团队因此引入 override 列表，指定哪些工具链接到 uutils、哪些继续使用 GNU coreutils。随着上游合并补丁并调整打包，列表逐渐缩短，并在 Ubuntu 26.10 中完全去掉。对于难以复现或难以写明的边界行为，Canonical 认为无法证明已经兼容，只能承诺尽快修复，并对该软件包采用略为特殊的回移植策略。相关工作同时通过内部工程、rust-coreutils 的独立安全审计、资助 Trifecta Tech Foundation 以支持 sudo-rs 和 ntpd-rs，以及与布里斯托大学的研究合作来推进。

https://serokell.io/blog/ubuntu-rust-coreutils-jon-seager

rustc - 类型系统中一处已存在 11 年的不健全性

Rust 的类型系统本应阻止内存不安全。rust-lang/rust 的 issue 164250 给出了一段本应被拒绝、实际却能编译通过的代码：程序把已经离开作用域的引用留了下来，运行后打印出后来分配的另一个字符串的内容；在 AddressSanitizer 下则以 stack-use-after-scope 崩溃。当前 nightly，以及至少回溯到 1.85.0 的 stable，都可以复现。

复现依赖泛型结构体 Q<T> 的 Drop 实现。析构时，Drop 取出字段中的值，放进静态的 Mutex<Vec<Box<dyn std::any::Any + Send>>>。调用处在内部块中构造局部 String，把指向它的引用写入 Q；块结束后这个引用仍留在静态容器里，随后再通过 downcast_ref::<&'static String>() 取出来使用。类型系统没有拒绝这种把更短生命周期的引用当作 'static 保存的写法。

Types Team 的 @lcnr 补充说，该问题标为 P-high；若不是已经存在 11 年，则会标为 P-critical。这么长时间未被发现，说明它并不容易碰到。表面上不难触发，但要利用它，需要有意编写恶意的 Drop 实现，因此这次不健全性很可能并没有在无意中造成内存不安全。团队正在推进 next-generation trait solver、region constraint rework 和 Project Zero，把修掉已知的类型系统不健全性、并降低未知问题的风险作为优先事项。

https://github.com/rust-lang/rust/issues/164250

safe Rust 检查与内存 arena - 热路径性能和分配方式

一位仍在同时学习 Rust 和 C、并正在编写小型解释型玩具语言的开发者，向社区提出了两个与性能有关的问题。

第一个问题是，safe Rust 在热路径上会不会因为编译器偏于保守、自行插入检查而明显变慢。提问者看到过一份与 lox 语言相关的对比，其中 unsafe Rust 比 safe Rust 大约快 4 倍，因此想知道这是日常会遇到的情况，还是只要代码写得合适，编译器通常就足够聪明，这类问题基本不会出现。

第二个问题是，使用 memory arena、在结束时一次性释放或重置整块内存，与由编译器按对象管理分配和释放的 RAII 风格相比，性能差距有多大。提问者明白 RAII 和 arena 并非完全对立，Rust 中也有 arena，但它们不属于标准库；在他看来，Rust 的默认做法往往不使用 arena，而 C 更常通过 arena 或分配器管理内存，而不是逐次 malloc 和 free。

https://www.reddit.com/r/rust/comments/1xttt6y/are_compiler_inserted_checks_something_you/

Rust 移植潮 - 有人询问为何近期各类项目都在改用 Rust

近几周，Reddit 的 r/rust 上有帖子指出，作者看到几乎各类已知的东西都在被移植到 Rust，并认为“把一切重写成 Rust”正在成为一种新趋势。帖子提出的问题是：编程语言有很多，为什么偏偏选择 Rust。

帖中举出的例子依次是：电子游戏方面出现合并，Artcraft 在仿照 Adobe 的产品并免费发布，Minecraft 正在被重写，Discord 也在切换。材料只记录了这一观察和提问，没有给出原因或结论。

https://www.reddit.com/r/rust/comments/1xqudci/everything_is_becoming_rust_now/

Google Summer of Code 2026 - Rust 的 13 个课题全部通过最终评估

Rust 项目今年第三次参加 Google Summer of Code。2026 年共有 13 个课题，周期长短不一，有的在 8 月结束，最后一个到 11 月才完成。11 月 11 日，Jakub Beránek 代表导师团队发布结果：13 个课题全部通过最终评估，并称项目已连续多年保持很高的通过率。今年课题少于 2025 年，主要是因为可投入的导师精力有限。夏季开始时，贡献者与导师开过一次视频会，彼此认识并了解各自课题；之后几个月里，导师持续沟通、提供指导、回答问题并审阅 pull request。Rust 项目认为 GSoC 是把新贡献者引入社区的一种方式，并打算在近期继续参加 GSoC 以及 Outreachy 等导师计划。

博文按字母序列出了这些课题：

1. 安全 GPU offload 的 Rust 前端，贡献者 Marcelo Domínguez
2. 为 Wild 增加 WebAssembly 链接支持，贡献者 Kei Akiyama
3. 将 autodiff 与 offload 纳入 Rust CI，贡献者 Shota Sugano
4. Miri 调试器，贡献者 Mohamed Ali
5. 实现 impl 与 mut 限制，贡献者 Ryosuke Yamano
6. 改进 serialport-rs 的易用性与安全性，贡献者 Tanmay
7. libc：迁移不同位宽的 time 与 offset 变体，并弃用容易出错的常量，贡献者 Adam Martinez
8. 用 Wild 链接 Linux 内核及其模块，贡献者 Vishruth Thimmaiah
9. 将 rust-analyzer 的 assists 迁移到 SyntaxEditor，贡献者 bit-aloo
10. 将 std::arch 测试套件移植到 rust-lang/rust，贡献者 Sumit Kumar
11. 重组 tests/ui/issues，贡献者 zedddie
12. 利用调试器 API 提高调试信息测试的准确性与错误报告，贡献者 Anthony Bolden
13. 为 rustup 支持 XDG 路径，贡献者 Guicheng Liu

其中，Marcelo Domínguez 在导师 Manuel Drehwald 指导下做的安全 GPU offload 前端，是为了改善用 std::offload 编写跨厂商 GPU 程序的可用性。课题开始时，offload 原型只是概念验证：假定被卸载的代码没有 bug，而且用户要写大量样板代码。他在夏季完成的主要工作包括：

1. 实现类型检查，让编译器核验传给任意 offload 调用的参数类型是否符合 GPU kernel 的期望，使 kernel 启动成为安全的。
2. 支持泛型 kernel。编译器收集从 CPU 侧启动的全部泛型实例化，编译 GPU kernel 时再载入这些信息并按需实例化。
3. 可以指定使用哪一块 GPU，适用于同时有集成显卡和独立显卡的笔记本，以及有多块 GPU 的服务器。
4. 新增两个宏，编写和启动 GPU kernel 时不再需要样板代码。
5. 引用是最难的部分。按 Rust 语义，不能把含有可变引用的类型直接映射到 GPU 再用多个线程处理。以往的 Rust GPU 项目用 raw pointer 绕过，这次希望避免。他实现了一种 sound 的抽象，用户可以安全声明 kernel 将如何访问可变参数。
6. 把 RajaPerf 性能套件从 C++ 移植到 Rust，用来给自己的 pull request 做基准测试。

https://blog.rust-lang.org/2026/11/11/gsoc-2026-results/

--

From 日报小组 Mike

社区学习交流平台订阅：

• Rustcc论坛: 支持rss
• 微信公众号：Rust语言中文社区

友情赞助：

• 老马Chat：老马识途，模型比较