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 bugOSS-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 Linux9 年后看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