尝试让 sudo 对 Rowhammer 攻击不那么脆弱
sudo 代码库的一项近期改动引入了特意挑选的数值常量，它们具有较大的汉明距离，从而让关键授权状态更难被 Rowhammer 风格的 DRAM 攻击翻转。评论者探讨这种软件层面的加固是否值得，因为 Rowhammer 本质上是一个硬件可靠性问题；他们讨论了复杂度、性能和现实威胁模型之间的权衡，并提出了编译器支持、ECC 内存和更好的硬件规范等替代方案。讨论串还触及了更广泛的安全与韧性系统设计影响，从高可靠嵌入式系统到共享主机和云环境。
补丁与编码技术
- sudo 现在为认证状态（SUCCESS、FAILURE、ERROR 等）使用特意挑选的 32 位常量，并且这些常量之间具有很大的汉明距离。
- 目标是：让 Rowhammer 需要进行大量特定比特翻转，才能把“拒绝”变成“允许”，从而降低所展示的 Mayhem/Rowhammer 利用的可行性。
- 一些评论者认为这种防御性编码风格很有意思，但担心要广泛应用会“非常痛苦”；也有人指出它与早已存在的容错思想相似（单粒子翻转、投票、ECC）。
语言 / 编译器想法
- 有人提议由编译器提供支持：为“安全”枚举添加属性，使其编码尽量最大化汉明距离，或者提供硬化模式，保留那些“冗余”检查而不是把它们优化掉。
- 由于 ABI / 向后兼容性问题，C/C++ 枚举很棘手；Rust 和动态语言可能更容易支持这类特性。
- GCC 的
hardbool被提及为类似的布尔值方案。 - 也有人讨论生成高距离编码的算法；有人指出 sudo 选取的值在数学上并非最优，而构造最优编码本身就是一个不简单的编码理论问题。
有效性与权衡
- 支持者把这视为纵深防御：它直接阻断了一条已知的 Rowhammer 路径，并且适用于 setuid 二进制这类高价值目标。
- 怀疑者认为它只保护了一类变量，无法应对其他可被破坏的控制流/数据，而且会让代码更难阅读和审计。
- 有人指出，如果攻击者已经拥有本地代码执行，可能存在更容易的提权路径；但另一些人反驳说，共享主机、集群和游戏服务器仍然会从这种加固中受益。
Rowhammer、ECC，以及硬件 vs 软件
- 多条评论强调，Rowhammer 本质上是一个 DRAM / 物理问题。讨论分成两派：
- “在硬件里修复 / 退回有缺陷的内存” vs.
- “物理规律和密度意味着完美免疫不现实；软件必须帮忙。”
- ECC 和片上 ECC 可以降低但不能消除 Rowhammer 风险；复杂攻击和多比特翻转可能绕过纠正，不过 ECC 至少应该触发告警。
- 据称现代 DRAM 随着密度提升而更易受影响；厂商侧缓解措施（如定向刷新）本身也可能不完美，甚至可能被滥用。
更广泛的影响
- 有人建议对微控制器和高辐射环境也采用同样的模式（最大距离编码、完整性检查），以检测无效控制路径并触发看门狗重置。