Rust for Linux 内核开发：内存安全、FFI 互操作与编译实战

最近关于 Rust 与 Linux 内核的讨论又热闹起来了。起因是 Linux 6.14 版本合入时Rust for Linux 的主要维护者 Wedson Almeida Filho 宣布退出社区里一部分抽象层被移除NVMe、Btrfs 等驱动的 Rust 支持被临时调整。各种群里立刻出现“Rust 失败了”“Linus 后悔了”的说法但实际情况并没有这么极端。这一期就围绕 Rust 进入 Linux 内核这件事把技术进展、Linus 的态度变化、工具链环境、编译验证流程和 Rust/C 互操作一次讲清楚。先说结论Rust 没有“掀翻”C 语言Linux 内核也不会因为 Rust 变成另一个操作系统。但 Rust 确实已经进入内核主线并且在驱动、安全敏感模块这些场景里逐渐落地。这件事值得关注的重点不是“谁取代谁”而是 Rust 到底在内核里承担什么角色、目前的工具链成熟度如何、你自己能不能动手编译一个带 Rust 支持的 Linux 内核来验证。本文会覆盖以下几个部分先给核心能力速览和适用边界再梳理 Linux 引入 Rust 的版本时间线和 Linus 的真实态度然后做 Rust 与 C 的核心技术对比。接着是实操环节包括 Rust 工具链安装、国内镜像配置、内核编译开启 Rust 支持、简单内核模块验证最后是 FFI 互操作示例、资源占用观察方法、常见问题排查和最佳实践。1. Rust for Linux 核心能力速览先把 Rust 在 Linux 内核中的基本状态整理成一张表方便快速判断你需不需要接触这个东西。能力项现状项目类型编程语言/内核模块开发支持内核主线状态Linux 6.1 起合入实验性 Rust 支持后续版本持续迭代核心作用提高内核模块内存安全性降低空指针、数据竞争、悬垂引用等问题对 C 的替代程度不完全替代主要面向新驱动、抽象层和安全敏感模块与 C 的关系通过 FFI 双向互操作C 代码可以调用 RustRust 可以调用 C架构支持取决于内核版本配置常见的有 x86_64、aarch64需按实际版本确认工具链要求rustc 版本与内核版本严格匹配通常需要 LLVM/Clang 环境编译要求需要开启 CONFIG_RUST 等内核配置项适合场景驱动开发、内核模块、安全关键逻辑、嵌入式系统开发学习学习门槛需要理解所有权和借用机制对内核 API 也有要求当前限制异步支持不成熟、部分驱动抽象仍在变动、维护人力有限从这张表可以看到Rust 在内核里的定位并不是“替代 C”而是在 C 语言长期薄弱的领域做补位。你完全可以继续用 C 写内核驱动也可以在新项目里尝试 Rust。真正需要关心的只有两件事工具链版本是否匹配、目标模块是否适合用 Rust 实现。2. Linux 为什么要把 Rust 放进内核C 语言诞生于上世纪 70 年代和 Unix 的关系极其紧密Linux 内核至今 90% 以上的代码仍然是 C。C 语言的优势非常明确性能高、可控性强、几乎没有运行时开销、对硬件抽象很直接。但它的问题也一直被业界诟病尤其是内存安全。空指针解引用、缓冲区溢出、释放后使用、数据竞争这些漏洞在内核这种长期运行、直接操作硬件的软件里显得特别致命。过去几十年C 语言社区采取了多种方式缓解内存安全问题。比如编译器开启-fstack-protector-strong这类保护选项使用 AddressSanitizer、KASAN、KFENCE 等动态检测工具以及通过代码审查和静态分析提前发现问题。这些手段都有效但它们本质上是在“写完代码之后找问题”而不是在“写代码的过程中杜绝问题”。只要代码是人写的内存错误就很难清零。Rust 走的是另一条路线。它通过所有权、借用、生命周期这套编译期检查机制在代码编译阶段就把悬垂引用、重复释放、数据竞争这类问题拦截住。这并不意味着 Rust 写出来的代码永远不会出 bug但内存安全这一类 bug 的比例会大幅下降。对内核这种安全敏感性极高的项目来说这是非常实际的收益。Linux 社区从 2020 年前后开始逐步讨论 Rust 进入内核的可能性最初是几个外部项目尝试用 Rust 写模块后来成立了 Rust for Linux 项目组按 RFC 流程提交设计方案。2022 年 12 月Linux 6.1 正式合入了基础的 Rust 支持这是标志性事件。到这一步Rust 已经不再只是“未来可能考虑的技术”而是进入了内核主线的真实代码。3. 版本时间线Rust 进入 Linux 主线的关键节点回顾一下 Rust for Linux 的落地过程可以帮助你理解当前版本为什么会是这个状态。内核版本时间重要变化Linux 6.12022 年 12 月合并 Rust 基础支持修复了若干抽象层加入 rust_minimal 示例模块Linux 6.22023 年 2 月完善平台支持增加 Rust 抽象层范围Linux 6.42023 年 6 月引入更多驱动抽象PCI 平台支持增强Linux 6.62023 年 10 月Rust 持续迭代部分 DRM 驱动开始使用 RustLinux 6.142025 年 3 月Rust 维护者调整部分抽象被移除核心支持保留这里需要重点解释的是 6.14 版本。Wedson Almeida Filho 是 Rust for Linux 最早的维护者之一主要工作集中在核心抽象层。他离开时在邮件列表里表示自己在维护过程中持续遭遇到大量非技术性的分歧和评论导致精力被消耗太多难以继续推进抽象层的开发。他的退出直接影响了一批依赖这些抽象层的驱动比如 NVMe、Btrfs 等模块的 Rust 支持在 6.14 期间做了临时调整。很多自媒体把这件事解读成“Rust 失败”“Linus 妥协后后悔”这是不准确的。更符合实际的说法是Rust 进入内核的推进速度比社区期待的要慢但主线方向没有改变。Linus 在多个场合的发言都能看出他对 Rust 的态度从“谨慎观望”逐步转向“认可方向、但不满意部分实现质量”。4. Rust 与 C 的核心技术对比对比 Rust 和 C不应该只看“哪个更强”而要看“它们各自适合解决什么问题”。对比维度C 语言Rust内存安全手动管理运行时崩溃或漏洞风险高编译期所有权/借用检查内存错误显著减少性能表现极致可预测零抽象成本零成本抽象性能与 C 同级语言复杂度相对简单学习曲线平缓生命周期、所有权、trait 系统学习曲线陡峭开发工具链GCC/Clang 成熟rustc/cargo工具链迭代快内核生态完全成熟仍在建设中部分抽象层不稳定驱动开发适配参考文档多模板齐全示例较少需要阅读内核 Rust 抽象源码并发安全依赖开发者经验编译期检查数据竞争FFI 能力自身就是 C ABI通过 extern C 与 C 互操作具体的差异集中在内存安全上。C 语言中一个简单的链表节点释放需要开发者手动保证所有引用都失效Rust 里如果代码试图使用已经移动的所有权编译器会直接拒绝。这种差异在写普通应用时感受不算强烈但在驱动、文件系统、网络协议栈这类处理复杂状态机的场景里收益非常明显。不过 Rust 在内核开发中也面临现实问题。内核代码大量使用自引用结构比如一个结构体保存指向自身的指针这在 Rust 的所有权模型里很难表达。内核还有很多地方依赖 C 的指针算术和强制类型转换Rust 的严格类型系统会让这些代码写起来非常别扭。这也是 Rust for Linux 项目进度不如预期的主要原因之一不是“做不成”而是“做得慢”。5. Rust 工具链安装与国内镜像配置如果你想动手编译一个带 Rust 支持的 Linux 内核第一步是搭好 Rust 环境。这里给出通用方案具体版本号一定要以你目标内核版本的官方文档为准。建议先查询内核自带文档。进入内核源码目录后打开Documentation/rust/quick-start.rst里面有当前内核支持的最低 rustc 版本和 cargo 版本。不同内核版本对 rustc 的要求不一样升级内核后工具链版本也要跟着调整。5.1 安装 rustupLinux 环境下推荐使用 rustup 管理 Rust 工具链curl --proto https --tlsv1.2 -sSf https://sh.rustup.rs | sh安装完成后执行source $HOME/.cargo/env rustc --version cargo --version可以看到 rustc 的版本号。如果安装脚本下载缓慢多半是网络原因可以按下面的方式配置国内镜像。5.2 配置 crates.io 国内镜像编辑~/.cargo/config.toml写入以下内容[source.crates-io] replace-with rsproxy [source.rsproxy] registry sparsehttps://rsproxy.cn/index/ [registries.rsproxy] index sparsehttps://rsproxy.cn/index/ [net] git-fetch-with-cli true5.3 配置 rustup 国内源rustup 下载工具链同样可以走镜像在~/.bashrc或~/.zshrc里追加export RUSTUP_DIST_SERVERhttps://rsproxy.cn export RUSTUP_UPDATE_ROOThttps://rsproxy.cn/rustup保存后重新加载配置再执行 rustup 安装和更新命令下载速度会明显改善。6. 实操编译一个带 Rust 支持的 Linux 内核环境准备好之后重点来了怎么让 Linux 内核开启 Rust 支持并编译通过。这里给出一套完整流程以通用步骤为主实际执行时请根据内核版本调整路径。6.1 准备内核源码git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git cd linux如果你不需要完整 git 历史也可以用内核官网 tarball。无论哪种方式都要先切换到目标版本分支避免工具链版本不匹配。6.2 安装依赖内核编译需要的基础依赖如下以 Debian/Ubuntu 为例sudo apt update sudo apt install build-essential flex bison libssl-dev \ libelf-dev libncurses-dev clang llvm pkg-config \ bc dwarves注意Rust 支持依赖 LLVM/Clang 工具链要确保 clang 已安装。6.3 生成配置文件先复制一份当前系统的内核配置作为起点cp /boot/config-$(uname -r) .config make LLVM1 menuconfig在 menuconfig 界面里依次进入General setup-Rust support- 开启Enable Rust supportKernel hacking-Sample kernel code- 选择Rust samples保存退出后可以确认配置项grep CONFIG_RUST .config输出中CONFIG_RUSTy说明 Rust 支持已经打开。6.4 编译内核make LLVM1 -j$(nproc)编译过程会持续一段时间具体时间取决于 CPU 核心数和源码规模。如果编译报错首先检查 rustc 版本是否满足内核文档要求其次确认 clang 版本。6.5 编译并加载 Rust 示例模块内核自带rust_minimal示例模块。编译完成后可以这样验证make LLVM1 Msamples/rust/rust_minimal -j$(nproc) sudo insmod samples/rust/rust_minimal/rust_minimal.ko dmesg | tail -10如果模块加载成功dmesg 里会看到 Rust 模块输出的日志例如Rust minimal sample (init)和Rust minimal sample (exit)对应的提示。卸载模块sudo rmmod rust_minimal这一步能跑通说明你的 Rust 内核环境基本可用。之后就可以围绕具体驱动场景逐步把真实模块从 C 迁移到 Rust 或直接新增 Rust 驱动。无论哪种方式都要先在内核源码目录下拷贝samples/rust/下的示例作为模板。7. Rust 与 C 的 FFI 互操作Rust 进入 Linux 内核不可能完全脱离 C。内核底层大量 API 是 C 实现的Rust 模块必然要调用 C 函数反过来C 代码也可能需要调用 Rust 模块导出的函数。这种相互调用就是 FFI也就是外部函数接口。7.1 Rust 调用 C 函数在 Rust 里声明 C 函数需要用extern C块。内核中常用的printk就是一个典型例子可以按下面方式声明extern C { fn printk(format: *const core::ffi::c_char, ...); }使用时的代码类似const MSG: [u8] bHello from Rust\0; unsafe { printk(MSG.as_ptr() as *const core::ffi::c_char); }这里最关键的一点是unsafe。Rust 编译器无法验证 C 函数的实现是否安全所以调用 C 函数必须包在unsafe块里。这也提醒开发者Rust 的内存安全保证只存在于安全的 Rust 代码中一旦进入 FFI风险依然需要自己控制。7.2 C 调用 Rust 函数反过来Rust 函数要暴露给 C 调用需要标记#[no_mangle]并声明为extern C#[no_mangle] pub extern C fn rust_simple_add(a: i32, b: i32) - i32 { a b }编译后C 代码里可以直接声明原型并调用int rust_simple_add(int a, int b); void test_rust(void) { int result rust_simple_add(1, 2); printk(rust_simple_add result: %d\n, result); }这种方式的代价是Rust 函数不能用Result、Option、String这类非 C ABI 的类型作为参数和返回值。跨 FFI 边界时只使用 C 兼容类型错误处理也要返回c_int之类的状态码。7.3 使用 bindgen 生成绑定如果 Rust 模块需要调用一个较大的 C 头文件手写 FFI 声明太低效可以用 bindgen 生成绑定。命令模板如下bindgen \ --no-layout-tests \ --size_t-is-usize \ --ctypes-prefix core::ffi \ -o bindings.rs \ header.h配置build.rs让 cargo 在编译时自动生成绑定是一个可以长期维护的做法。不过内核环境下的 bindgen 集成比普通用户态项目更复杂涉及内核头文件的编译参数建议先参考内核源码里已有的 Rust 模块写法再决定是否需要引入 bindgen。8. 资源占用与性能观察在内核模块场景下讨论“资源占用”和“性能”跟在普通应用里不太一样。没有统一的标准数字可以直接套用必须依赖实际运行环境和测试方法。8.1 有哪些可观察的指标对于内核模块最有用的资源指标是模块加载后的内存占用可以通过lsmod和/proc/modules查看dmesg中模块初始化时输出的日志判断分配了多少内存模块运行的时延使用perf或ftrace采样模块对内核启动时间的影响用systemd-analyze或内核启动日志观察性能对比设计要控制变量。如果你要对比 Rust 模块和 C 模块的性能需要保证两者完成的功能完全一致并且使用相同的编译优化等级。比较时才看执行时间、内存分配次数、锁等待时间这些量化指标。脱离实际硬件、驱动具体逻辑去谈“Rust 比 C 快还是慢”没有意义。8.2 显存或内存占用观察方法如果你测试的是 GPU 驱动类 Rust 模块还需要额外关注显存占用。内核模块自身的显存统计工具不多但可以通过/sys/class/drm/下的设备节点和cat /sys/kernel/debug/dri/0/下的调试文件获取。更稳妥的做法是写一个测试脚本在加载模块前和加载模块后分别记录内存和显存数据再做差。这个方法不需要依赖编造的数字能够真实反映模块运行时的资源消耗。8.3 如何降低资源占用内核 Rust 模块的编译优化选项和 C 模块一致开启内核的CONFIG_DEBUG_INFO会带来更大的模块体积发布版建议关闭使用O2或O3优化等级提升运行速度启用panicabort和opt-levelz可以降低代码体积避免在热路径中大量使用Box、Vec这类堆分配结构内核环境下堆分配成本高结合具体业务场景反复测试优先保证没有内存泄漏和错误路径处理再谈性能优化。9. 常见问题与排查方法问题现象可能原因排查方式解决方案rustup 安装脚本下载慢网络原因查看下载日志使用镜像测试配置RUSTUP_DIST_SERVER国内镜像rustc 版本与内核要求不匹配工具链版本问题查看Documentation/rust/quick-start.rst用 rustup 安装指定版本并设为默认版本编译报错cc1: error: unrecognized command line option编译器版本或 LLVM 问题查看 clang 版本确认用的不是 GCC使用LLVM1重新编译CONFIG_RUST不存在内核版本过旧或配置丢失检查内核版本和 make menuconfig 路径切换到 6.1 以上版本打开Rust support模块加载失败Exec format error内核与模块版本不匹配执行dmesg查看详细错误重新编译内核和模块确保同一源码树cargo 拉取依赖慢或失败网络或国内源未配置检查~/.cargo/config.toml配置rsproxy.cn等镜像源内核模块里无法使用StringRust 内核环境缺少标准库检查 panic handler 和全局分配器按内核模块规范编写避免用户态库依赖bindgen 生成绑定失败头文件依赖缺失查看 compiler errors 中缺失的头文件补充对应内核头文件路径或调整 bindgen 参数10. 最佳实践与使用建议10.1 先从最小模块跑通再扩大范围第一次接触 Rust for Linux不要直接尝试重写现有驱动。最稳妥的顺序是编译一个带 Rust 支持的内核 - 编译并加载rust_minimal示例模块 - 修改示例实现一个简单字符设备 - 再研究具体驱动。每一步都验证通过后再进行下一步能避免把环境问题和代码问题混在一起。10.2 锁定工具链版本并记录环境Rust 工具链迭代很快Linux 内核版本也在不断变化。建议把以下内容写进项目的 README 或 CI 脚本内核版本、rustc 版本、clang 版本、cargo 版本、使用的内核配置文件。这样在别人复现或你自己隔一段时间回来继续开发时不会出现“我什么都没改但编译不过”的尴尬。10.3 Rust 负责逻辑C 负责接口在代码布局上建议把驱动中风险较高、逻辑较复杂的部分用 Rust 实现把直接操作硬件的底层部分仍然保留 C 或通过 FFI 桥接。这样既能享受到 Rust 内存安全带来的收益又不会因为 Rust 对硬件寄存器操作不够直接而卡住进度。10.4 关注上游社区而不是碎片化信息Rust for Linux 项目仍处于快速变动期。与其在一些论坛里看二手消息不如直接订阅内核邮件列表中的 rust-for-linux 讨论或者定期阅读 Linux 内核 Release Note 和主线合并记录。项目地址是https://github.com/Rust-for-Linux/linux可以关注 main 分支的提交和 RFC 文档。10.5 安全边界和合规提醒Rust 内核模块也会涉及敏感能力例如对硬件设备、文件系统、网络数据的处理。在实际开发中请确保所有操作都经过了合法授权不要用内核模块去绕过安全限制或操控无关设备。如果模块需要访问用户数据或设备数据务必遵守所在机构的数据保护和隐私合规要求。开源驱动要遵守对应许可证检查 GPL 和 Rust 模块之间的许可兼容性问题。11. 总结与下一步Rust 进入 Linux 内核这件事最值得关注的价值不是“语言之争”而是给内核开发提供了一条新的内存安全实现路径。它没有替代 C也不会让 Linux 在短期内变成 Rust 系统。但围绕安全敏感模块的 Rust 抽象确实在逐步落地未来文件系统、网络协议栈、驱动框架这些方向都存在继续扩展的可能。如果你要亲自验证建议先做两件事第一按本文第 5 章和第 6 章的流程在一台稳定的 Linux 机器上编译一个带 Rust 支持的内核第二跑通rust_minimal模块确认日志输出正常。这是整个链条里最容易踩版本坑、也是最容易获得正反馈的环节。之后可以顺着三个方向继续深入一是用 Rust 写一个字符设备驱动体验内核态下的所有权和引用规则二是尝试把 Rust 模块接入现有 C 驱动通过 FFI 做真实的数据交互三是关注 Rust for Linux 上对异步支持和网络栈支持的新进展。只要工具链版本对齐、测试环境固定这些内容都可以逐步在本地跑通。建议收藏备用下次想动手验证时可以照着流程直接开始。