2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家
148 亿次模糊测试执行如何暴露 Rust 内核原语中的异或不变量陷阱
执行过程揭示了 Rust 内核原语中的一个异或不变量陷阱
在过去的几周里，我一直在为一个长期的 Rust 基础设施项目构建并压力测试一个最小化的内核层。
其关注点刻意保持狭窄：
- 确定性原语
- 零分配类型
- 稳定的二进制表示
- 无隐藏的运行时行为
- 严格的不变量强制
最近，我对这些内核原语进行了一场长期的对抗性模糊测试活动。
该活动累计执行了约 148 亿次。
起初，有趣的部分似乎是崩溃本身。
但第二次崩溃被证明比典型的内存错误有趣得多。
崩溃详情
模糊测试器最终停在这个断言上：
断言失败：acc_even.ct_eq(&FixedHash::ZERO)
乍一看，这看起来像是哈希原语的异或实现中存在潜在问题。
那将会很严重。
尤其是在代数保证至关重要的底层确定性基础设施中。
调查过程
模糊测试目标包含一个链式异或压力测试：
let mut acc_even = h;
for _ in 0..8 {
acc_even = acc_even ^ h;
}
该不变量错误地假设：
“偶数次异或 ⇒ 零值”
但这里有一个细微的错误。
累加器已经用 “h” 进行了初始化。
这意味着该表达式实际上评估为：
h ^ h ^ h ^ h ^ h ^ h ^ h ^ h ^ h
不是 8 次出现。
而是 9 次出现。
而异或奇偶规则是严格的：
- 偶数次出现 ⇒ 零值
- 奇数次出现 ⇒ 原始值
因此，原语是正确的。
验证逻辑才是错误的。
为何这很重要
这正是为什么即使对于“简单”的原语，长期运行的模糊测试活动也极具价值的原因。
目标不仅仅是发现崩溃。
目标是验证假设。
在底层系统工程中，验证层内的错误假设可能变得与实现错误本身一样危险。
尤其是当这些原语旨在成为基础架构组件时。
修复方案
该不变量被重写为从零值开始：
let mut acc_even = FixedHash::ZERO;
for _ in 0..8 {
acc_even = acc_even ^ h;
}
现在，奇偶逻辑在数学上是正确的。
最后思考
在构建基础设施软件的过程中，我学到了一件事：
大多数故障并非来自“复杂”的代码。
它们来自那些在代码审查、测试和直觉中悄然存活下来的小假设。
模糊测试是为数不多的足够残酷、能持续挑战这些假设的工具之一。
有时，最有价值的错误是那个证明原语自始至终都是正确的错误。
