Rust 在 Linux：修补边缘，而非核心

Source: Dev.to

Introduction

在 2022 年，Linus Torvalds 决定将 Rust 支持合并到 Linux 内核——6.1 版是首次包含全新 Rust 基础设施的发布。这并不是对 C 的否定，也不是要重写内核；C 仍然是内核的基石。改变的是人们认识到，内核的安全风险并非主要来源于其核心，而是来源于由人在现实约束下编写的庞大且不断扩展的外围代码。随着内核的成长，开发者必须在复杂的、异步的、硬件驱动的路径中手动跟踪内存的分配与释放——即使是经验丰富的程序员也容易出错。

Kernel Memory Management and Garbage Collection

Linux 内核从未使用垃圾回收（GC）进行内存管理的根本原因在于对确定性性能的需求。在内核环境中，CPU 必须以微秒级的精度响应硬件中断并管理系统资源。GC 会引入“stop‑the‑world”事件，使系统暂停以扫描和清理内存，这会导致不可接受的延迟，甚至系统崩溃。因此，内核历来依赖手动内存管理，使用 C 函数如 kmalloc 和 kfree。

Where Most Vulnerabilities Originate

这些核心内存管理子系统并不是大多数可利用漏洞的来源。页分配器、slab/SLUB、虚拟内存层以及 MMU 交互代码虽然极其复杂，但也高度集中、经过大量审计，并由少数专家维护。数十年的严格审查使得对它们的改动极为罕见，任何修改都必须格外谨慎。虽然这些地方也会出现 bug，但相对少见且往往影响全系统。

大多数内存安全漏洞实际上出现在使用这些分配器的代码中：设备驱动、网络协议栈、文件系统以及其他边缘子系统。这些代码规模庞大、硬件依赖强，常由厂商或偶尔的贡献者编写。在 C 语言下，编译器无法在回调、 中断和异步路径之间强制正确的对象生命周期。于是产生了大量的 use‑after‑free、double‑free 和非法别名错误，这些错误历史上占据了严重内核利用的很大比例。

Rust’s Approach to Memory Safety

Rust 通过将内存管理逻辑从人脑转移到编译器来应对这些风险。凭借其独特的所有权、借用和生命周期系统，Rust 在代码运行前就确保内存被正确处理。不同于依赖重型后台进程进行内存管理的运行时，Rust 在编译时实现安全性，几乎没有运行时开销。这使得它能够在无运行时环境的内核中像 C 一样高效运行，同时对最常见的人为错误提供数学上的保证。

Current Adoption Strategy

内核社区正采用外科手术式的实现策略，主要在新设备驱动和抽象层使用 Rust。诸如进程调度器和内存管理单元等核心子系统仍然使用 C，因为它们极其复杂且经过数十年的优化。该混合模型使内核能够在不必重写数百万行已有、可用的 C 代码的情况下，向更安全的未来演进。