2017 年 10 月 Linux 4.14 RC5 发布时，Linus Torvalds 在邮件列表里罕见地夸了一段 fuzzing------这位平时对工具和方法论保持距离的工程师，这次直接说「很高兴可以看到」人们在驱动子系统等地方做针对性的模糊测试。那时候 Google 的 OSS-Fuzz 才运行一年多，syzkaller 还在内部孵化，微软同期推出 Project Springfield（后改名 Security Risk Detection）想把 fuzzing 商业化。Linus 那段话当年是 Linux 内核安全史的转折点------把 fuzzing 从「少数派用的额外工具」定调为「系统性提升内核安全的关键方法」。
9 年后回看，syzkaller 帮内核找了 5000+ bug，OSS-Fuzz 覆盖 1000+ 项目，KASAN / KCSAN 进内核主线。Linus 当年的判断完全被验证，但他 9 年前没料到的是------fuzzing 在 AI 时代反而更重要，因为 AI 生成的代码量、可读性、单元测试覆盖都不如人类写的。
文章讲了啥
ZDNet 报道了 Torvalds 在 4.14 RC5 发布说明里关于 fuzzing 的言论，整篇文章围绕一段简短但份量重的引语展开：
另外值得一提的是人们做了多少随机化模糊测试，而且这正在发现东西。我们一直在做模糊测试（谁还记得只是生成随机代码，并跳转过去的老 "crashme" 程序？我们过去很早就这样做），人们在驱动子系统等方面做了一些很好的针对性模糊测试，而且已经有了各种各样的修复（不仅仅是上周的这些）。很高兴可以看到。
Linus 这段话可以拆成几个论点。
第一，fuzzing 不是新技术。1991 年的 crashme 就是最早的 fuzz 工具之一------它随机生成代码并跳转过去，看系统会不会崩。Linux 内核社区用 fuzzing 至少 20 年，但 2017 年之前这事没人系统性投入。
第二，targeted fuzzing 是关键。随机化测试 + 针对特定子系统的深度测试双管齐下，比纯随机 fuzz 有效得多。Linus 当时在夸的具体工具是 Google 的 syzkaller（前身是 trinity 和 ikos），它针对特定系统调用做深度 fuzzing。
第三，驱动子系统已被 fuzz 覆盖。Linux 内核代码里驱动占了大约 70%，也是 bug 最密集的地方。targeted fuzzing 的重点就是驱动子系统。
第四，已发现大量 bug。不仅是 4.14 这一版本，「各种修复」贯穿了多个版本------这是 Linus 在用 release notes 的口吻告诉业界：fuzzing 已经在持续产出成果。
第五，Linus 罕见肯定。Torvalds 通常对工具和方法论保持距离，邮件列表里他的语气一般是「这个 bug 必须修」或「这个设计不行」。这次他直接说「很高兴可以看到」，是他少有的对工具方法论点赞。
第六，Linux 4.14 是个 LTS。这是个延伸论点------4.14 内核被多家厂商选作长期支持版本，fuzzing 找出的 bug 修复会进入未来多年生产环境。
ZDNet 那篇报道同时指出，Google 用各种 fuzzing 工具来查找它及其它供应商软件中的错误。微软同期推出 Project Springfield（后改名 Security Risk Detection）做商业化 fuzzing 服务。
重读
这些观点今天还成立吗
- ✅ targeted fuzzing 比随机 fuzz 有效 ------ syzkaller 已成为 Linux 内核持续 fuzzing 的工业标准
- ✅ fuzzing 能发现驱动子系统 bug ------ syzkaller 在 9 年里发现超过 5000 个 Linux 内核 bug
- ✅ Linus 重视 fuzzing 工具 ------ Linux 内核已内置 KASAN、KCSAN、syzkaller 集成
- ✅ fuzzing 是开源安全的关键工具 ------ Google OSS-Fuzz 已覆盖 1000+ 开源项目
- ⚠️ 内存安全漏洞是主要威胁 ------ Rust for Linux 6.1+ 合并，开始用类型安全语言重写
Torvalds 当时不会想到的变量是 Rust for Linux
9 年后看，syzkaller 是 Torvalds 当年判断的最强注脚。Google 的 syzkaller 是 Linux 内核持续 fuzzing 的工业标准，9 年里发现超过 5000 个内核 bug，其中相当一部分是安全相关的内存错误。syzkaller 的设计哲学就是 Torvalds 当年说的「targeted fuzzing」------针对特定系统调用、特定驱动做深度 fuzzing。
Linus 当时不会想到的变量是 Rust for Linux。2022 年 6.1 内核合并了 Rust 基础设施，2026 年 Linux 内核中 Rust 代码已达数万行。fuzzing 找的是「已写错的 C 代码」，Rust 直接在类型系统层消灭了大部分内存错误------这是 Torvalds 当年方法论的自然延伸。
AI Agent 元年让 fuzzing 更重要
2026 年是 AI Agent 元年。AI 生成的代码反而让 fuzzing 变得更重要------AI 生成的代码量大、可读性差、单元测试覆盖低，AI Agent 写代码时容易产生边界错误、空指针解引用，大量 AI 生成的「小工具」、「小脚本」、「小胶水代码」涌入生产，人类 reviewer 越来越难 catch AI 写的微 bug。
fuzzing 9 年前是「高阶安全工具」，今天成了「AI 代码唯一可靠的验证手段」。LibFuzzer、AFL、honggfuzz 在 AI 代码生态里被广泛集成。
「fuzzing 有效」的前提是有钱有时间
2017 年 Torvalds 那段关于 fuzzing 的话，背景是 Google 投了大钱做 OSS-Fuzz、Microsoft 投了大钱做 Project Springfield、各大厂都有自己的安全团队。但 9 年后看，fuzzing、代码审计、安全响应这些「隐性基础设施」的投入是永远追不上漏洞产生速度的------Torvalds 9 年前夸 fuzzing 时，OSS-Fuzz 才运行 1 年；9 年后 OSS-Fuzz 覆盖 1000+ 项目，但每天仍有新的 CVE 爆出。
真正决定开源项目安全的，不是「投入多少钱」------是「维护机制是否可持续」 。Heartbleed 后的 CII、log4j 后的 OpenSSF、xz 后的 Alpha-Omega，都是在反复试错「如何让开源维护可持续」。9 年后回头看，「开源安全靠大公司投钱」这条路走到了尽头 ：Google、Microsoft、IBM 这几家投了几十亿美元在开源安全上，但 xz-utils 后门证明单点失守仍然能让这些投入付之东流；AI 时代下，开源代码的「生成速度」远超过「审计速度」------投入再多钱也审计不过来。
真正能解决开源安全的，不是「更多钱」------是「维护者激励 + 自动化验证 + 分发链协同」这三件事 。少问「开源安不安全」，多问「这个项目的维护者是否在拿工资」------这才是 2026 年该问的真正问题。Torvalds 9 年前说 fuzzing 有效是技术判断；但 9 年后看，「fuzzing 有效」的前提是有钱、有时间、有能力去跑 fuzzing 。Fuzzing 本身是机制不是道德------一个维护者工资没着落的项目，再多 fuzzing 工具也救不了。
出处
- 原文 （ARR 风险）：zdnet.com{rel="nofollow noopener"}
- LCTT 译稿源档 ：github.com/LCTT/TranslateProject
- 原译 ：lctt.x-cmd.com
- 发布：2017-10-17