LWN：避免过量oops！

关注了就能看到更多这么棒的文章哦～

Averting excessive oopses

By Jonathan Corbet
November 18, 2022
DeepL assisted translation
https://lwn.net/Articles/914878/

内核发生 oops 一定不是什么好事，一次也不应该发生，因为它表明系统中某个地方出了严重的问题，而且不可能简单地恢复正常。但是看起来如果出现大量的 oops 可能会更糟糕。为了避免反复出现的问题，目前正在努力给内核在放弃并且重启之前所允许出现的 oops 的数量设置一个上限。

内核中的 oops 就相当于用户空间中的 crash。它的出现有很多原因，包括解析一个跑飞了的指针、硬件问题、或者由内核代码本身的检查所发现的 bug。对 oops 的一个通常应对就是向系统日志打印大量的诊断信息，并杀死发生问题时正在运行的进程。

然而在发生 oops 之后，系统作为一个整体在可能的请胯下还是会继续运行的。kill 这个系统的话，会使用户来不及保存那些尚未未完成的工作，也会使问题变得更难 debug。因此，内核将尽最大努力来继续执行，哪怕是已经出现了明显的错误。这个设计决策带来的一个直接结果就是，任何一个系统里都可能出现不止一次的 oops。事实上对于某些类型的问题来说，经常是出现多次 oops 的，而且可能一直持续到有人受不了而重启系统。

Jann Horn 最近开始思考，如果内核里出现了太多次的 oops，那么是否应该彻底放弃，直接进入 panic 状态（这会导致系统重启）。这在通常情况下可能是明智的策略：一个经常发生 oops 的内核显然状态已经不对了，允许它继续运行下去的话可能会导致数据丢失等问题。但是，Horn 还有另一个担忧：通过让系统发生许多次的 oops，可能可以产生安全漏洞。

根据定义，一个 "oops" 会在一个操作完成一部分。通常没有什么办法能清理所有可能需要清理的东西，因为在一个意外的位置出了问题。因此，oops 可能会导致 lock 被保留在被获取了的状态，或者可能导致已经增加过的 counter 无法再减小。counter 问题特别值得关注；如果一个 "oops" 导致某个 counter 不能被正确减小的话，重复出现的 "oops" 很可能可以变成导致该 counter 溢出的一种手段，从而创造一个可利用的安全漏洞。

为了阻止这种类型的攻击，Horn 写了一个 patch，对系统在调用 panic() 并且重启之前的 Oops 次数设置了一个上限。这个限制被设定为 10,000 次，但可以通过命令行参数 oops_limit 来进行改变。

人们可能会想，反复地对内核进行 oops 是否真的是利用内核漏洞的一种现实手段。内核 oops 需要一定的时间，取决于许多因素，包括需要记录的数据量以及 console 设备的速度。开发社区在优化内核中的许多地方的代码都投入了大量的精力，但加快 oops 的处理速度不知为何从来不在优先事项列表里。为了确定处理一个 oops 需要多长时间，Horn 写了一个特殊的 benchmark：

在一个快速的单线程基准测试中，当图形控制台（graphical console）处于活动状态时，在 vfork() 的子程序中进行 oops 处理，打印一个非常简短的 stack trace，这样每次运行只需要 510 微秒；但切换到文本控制台的时候，oops 被打印出来的速度就慢了 87 倍，每次运行大约 45 毫秒。

基于这一点，他得出结论，在最理想的条件下，持续触发 oops 需要 8 到 12 天的时间才能导致一个 32 位的 counter 溢出，假设每一次 oops 都会递增一次的话。因此，这不是一个找到系统漏洞的最快的途径，也不是最隐蔽的。"这是一个 非常 嘈杂且暴力的攻击内核的方法"。虽然几乎可以肯定有一些系统可以连续 OOPS 一个多星期而没有人注意到，但这种情况毕竟还是相对罕见的。

即便如此，似乎也没有人介意来给内核所能承受的 oops 数量设置一个上限。甚至没有人觉得有必要争论 10,000 这个数字是否合理，尽管 Linus Torvalds 确实顺便指出他希望有更高的一个数字来作为限制。Alexander "Solar Designer" Peslyak 建议，与其新增一个专门的命令行参数，Horn 其实可以直接将现有的 panic_on_oops 这个 bool 参数变成一个整数并直接使用。这个想法并没有得到多少赞同，因为现在内核中有很多地方会检查该参数并根据它来选择不同行为。

几天后，Kees Cook 发布了该 patch 的更新版本，将其变成了一组 patch，包含六个独立 patch。Horn 实现的行为没有改变，但有一些补充，首先是新增了一个计数，使得内核在发出太多的 warning 的情况下也会导致系统 panic。Cook 还总结说，由于内核现在正在统计 oops 和 warning 的数量，这些信息就可以通过 sysfs 提供给用户空间，从而监控系统（monitoring system）可以利用它们。

没有人反对这种改动，所以这个 patch set 有可能会采用当前的形式来进入 6.2 内核。此后，没有任何一个内核会被迫长期忍受不断出现 oops 的屈辱了，也许也会抵挡住一些聪明的漏洞。"Don't panic" 可能是对银河系搭便车者的好建议，但有时确实是内核应该做的正确的工作。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～