Greg Kroah-Hartman 本周出席了 RustWeek 2026,并谈到了一项仍在开发中的基于 Rust 的方案,该方案有望消除 Linux 内核产生的约 80% 的 CVE。
这并非一个轻率的论断。因为它出自一位自 2005 年 Linux 内核安全团队成立以来,亲自审阅过每一个内核安全漏洞的人之口。
C 语言的盲区 在 Greg 看来,核心问题在于"不受信任的数据"。每当数据从用户空间或硬件抵达时,内核都应持怀疑态度。
C 语言从未拥有一个可靠的方法来强制执行这一点。一旦数据从用户空间复制到内核,它就会变成一个普通的指针,并丢失其来源的所有上下文信息。它会被随意传递,而那些本应捕捉问题的外部检查器并不总是得到运行。
硬件则带来了同一问题的另一层挑战。内核在设计时假定硬件是可信的,但随着恶意硬件成为一个真实且日益增长的威胁,这一假设越来越难以维系。
Rust 已经解决的问题 在新方案尚未落地之前,Rust 就已经在发挥作用了。未检查错误返回值以及忘记释放锁,是导致内核 CVE 的两个显著因素,而 Rust 在编译时就处理了这两个问题。
Greg 估计,仅这两项修复就能涵盖约 60% 的内核错误。
而且还不止于此。为现有 C 代码编写 Rust 绑定,已悄然促使内核维护者真正地去记录和思考他们的 API,梳理所有权语义、锁规则以及常量正确性。
"不受信任"类型登场 Greg 提出的解决方案是一种名为 Untrusted 的 Rust 类型,由他和内核贡献者 Benno Lossin 共同开发。
Untrusted
它作为一个编译时标记,附着于来自用户空间或硬件的数据,并且没有运行时开销。
并且,你必须通过一个验证步骤,将其显式转换为"可信"数据,否则无法访问底层数据。
这能将所有验证代码集中到一个可见、可审查的位置。
这对作为 Linux 用户的你意味着什么? 当前以安全更新形式流向你的发行版的众多 CVE,有很大一部分根本就不会产生。
但是,该方案尚未被合并。Rust 编译器仍需进行更改,相关的字段投影工作也在同步进行。
Rust Could Eliminate 80% of Linux Kernel CVEs!
看来 锈化 后的Linux 会更安全
难倒要体验执行一下就检查一下内存安全的快感嘛, Magisk里都有大量unsafe语句块(
Featured Collection
Popular Ranking
Popular Events
Greg Kroah-Hartman 本周出席了 RustWeek 2026,并谈到了一项仍在开发中的基于 Rust 的方案,该方案有望消除 Linux 内核产生的约 80% 的 CVE。
这并非一个轻率的论断。因为它出自一位自 2005 年 Linux 内核安全团队成立以来,亲自审阅过每一个内核安全漏洞的人之口。
C 语言的盲区
在 Greg 看来,核心问题在于"不受信任的数据"。每当数据从用户空间或硬件抵达时,内核都应持怀疑态度。
C 语言从未拥有一个可靠的方法来强制执行这一点。一旦数据从用户空间复制到内核,它就会变成一个普通的指针,并丢失其来源的所有上下文信息。它会被随意传递,而那些本应捕捉问题的外部检查器并不总是得到运行。
硬件则带来了同一问题的另一层挑战。内核在设计时假定硬件是可信的,但随着恶意硬件成为一个真实且日益增长的威胁,这一假设越来越难以维系。
Rust 已经解决的问题
在新方案尚未落地之前,Rust 就已经在发挥作用了。未检查错误返回值以及忘记释放锁,是导致内核 CVE 的两个显著因素,而 Rust 在编译时就处理了这两个问题。
Greg 估计,仅这两项修复就能涵盖约 60% 的内核错误。
而且还不止于此。为现有 C 代码编写 Rust 绑定,已悄然促使内核维护者真正地去记录和思考他们的 API,梳理所有权语义、锁规则以及常量正确性。
"不受信任"类型登场
Greg 提出的解决方案是一种名为
Untrusted的 Rust 类型,由他和内核贡献者 Benno Lossin 共同开发。它作为一个编译时标记,附着于来自用户空间或硬件的数据,并且没有运行时开销。
并且,你必须通过一个验证步骤,将其显式转换为"可信"数据,否则无法访问底层数据。
这能将所有验证代码集中到一个可见、可审查的位置。
这对作为 Linux 用户的你意味着什么?
当前以安全更新形式流向你的发行版的众多 CVE,有很大一部分根本就不会产生。
但是,该方案尚未被合并。Rust 编译器仍需进行更改,相关的字段投影工作也在同步进行。
Rust Could Eliminate 80% of Linux Kernel CVEs!