Linuxeden开源社区本周末，Linux 内核邮件列表上关于 Linux 内核缓解意外算术溢出/下溢/包络问题的讨论非常热烈。
谷歌的基斯-库克（Kees Cook）一直在研究如何更好地处理 Linux 内核 C 源代码中的意外算术溢出错误。他希望看到一种系统的方法，让 Linux 内核能够处理此类算术溢出/下溢/绕过问题。最初的想法是更好地使用基于编译器的消毒器或最近的 C 语言提案，在不混淆名称的情况下进行运算符重载。在后一种可能的解决方案中，C 语言的运算符重载可以在帮助程序中任意处理溢出问题。
Kees 最初的想法是采用基于 sanitizer 的缓解措施，他在邮件列表线程的最后说：”我正在寻求一些普遍共识：
他在邮件列表线程中总结道：”我正在就采取上述 #1 方法寻求普遍共识。任何能让我们真正获得有意义的覆盖率的解决方案都需要对 Linux 的类型进行相当大的改动，因此这是一个普遍的痛点。但我已经敲了很久 “让 Linux 更安全 “的鼓了，我希望我能说服大家，我们需要在这里做出实际改变。现状不够好，我们可以做得更好。我只需要找到一个共同的解决方案，我们可以达成一致，并在未来几年内实际应用。
我现在就去拿我的石棉服……你有什么想法、建议和替代方案？”
Linus Torvalds 很快分享了他对该提议的看法：
“我还是完全不相信。
问题是，wrap-around 不仅定义明确，而且是*常见*和*预期*的。
例如
static inline u32 __hash_32_generic(u32 val)
{
返回 val * GOLDEN_RATIO_32；
}
该死的，我绝对不认为我们应该将其注释为某种 “特殊乘法”。
我不知道有多少这样的乘法存在。但我百分百相信，让人类注释并使源代码变得更糟绝对是错误的做法。
基本上，无符号运算被明确定义为缠绕运算，这样做是有充分理由的。
因此，我有一个硬性要求，那就是任何编译器投诉都必须非常非常理智。编译器需要检测到人们是故意这样做的，而且他们需要对缠绕的事实闭嘴。
任何愚蠢到在上述情况下抱怨绕包的工具，都是需要被忽略的坏工具。
真的。这是没有商量余地的。
这与整个
无符号 int a, b；
if (a+b < a) .
这种模式：在上述情况下抱怨缠绕的工具绝对是破烂，需要忽略。
因此，我认为你需要限制你的绕行抱怨，并真正思考如何限制它们。如果你把 “缠绕是错误的 “作为一种通用规则，我就会无视你，我也会告诉别人无视你，并拒绝任何因这种愚蠢规则而产生的白痴补丁。
换句话说，你首先要做的最基本的事情就是确保工具不会抱怨正常的行为。
除非您做到了这一点，并认真对待这件事，否则这场讨论不会有任何结果。
Linus”
来自 Linus Torvalds 的明确沟通。他随后补充道
“任何无意识的 “这个可以绕一圈 “都是不可原谅的。
它需要比这更聪明。是的，这就意味着要充分考虑到可能出现的缠绕结果的实际使用情况。
如果它被用作大小或数组索引，可能会有问题。但如果它被用于屏蔽，然后*屏蔽*版本被用于索引，显然就不是问题了。
也就是说，它与 “a+b < a “完全一样。是的，”a+b “可能会缠绕在一起，但如果它的用途是与其中一个加数进行比较，那么这种缠绕显然是没有问题的。
如果一个工具不考虑结果是如何使用的，只是盲目地说 “缠绕错误”，我认为这样的工具是有害的。
不，答案绝对不是通过添加更多随机辅助类型和/或函数来增加内核开发人员的认知负担。
我们对内核开发人员的期望已经很高了。我们不应该因为你的宠物项目而增加负担。
换一种说法：我让你承担责任，确保你的宠物项目是宠物项目中的 “瑜珈熊”–比一般的熊更聪明。
只要你从 “这样做把责任推给别人 “的角度出发，*你*就是问题所在。
成为解决方案，而不是问题。
Linus”
作为另一项后续行动，他建议采取更多的小步骤来找到潜在的解决方案。讨论仍在继续，我们将拭目以待讨论的进展，以及最终会提出什么代码来更好地处理 Linux 内核的 C 代码，以减少潜在的意外算术溢出/绕过。
转自 Torvalds Voices Thoughts On Linux Mitigating Unexpected Arithmetic Overflows/Underflows – Phoronix