From: Alexander Popov Date: Sat, 10 Aug 2024 14:23:23 +0000 (+0300) Subject: Improve the reflections on CONFIG_PANIC_ON_OOPS X-Git-Tag: v0.6.10~28 X-Git-Url: https://jxself.org/git/?a=commitdiff_plain;h=e9d682fe967808e6c215233c2fe3e056a9a5b02f;p=kconfig-hardened-check.git Improve the reflections on CONFIG_PANIC_ON_OOPS --- diff --git a/README.md b/README.md index 0b5bd29..c6b764e 100644 --- a/README.md +++ b/README.md @@ -442,13 +442,17 @@ The rationale: __Q:__ KSPP and CLIP OS recommend `CONFIG_PANIC_ON_OOPS=y`. Why doesn't this tool do the same? -__A:__ I personally don't support this recommendation because: - - It decreases system safety (kernel oops is still not a rare situation) +__A:__ I can't support this recommendation because: + - It decreases system robustness (kernel oops is still not a rare situation even on production systems) - It allows easier denial-of-service attacks for the whole system -I think having `CONFIG_BUG` is enough here. -If a kernel oops happens in the process context, the offending/attacking process is killed. -In other cases, the kernel panics, which is similar to `CONFIG_PANIC_ON_OOPS=y`. +You should enable `CONFIG_PANIC_ON_OOPS` if: + - Your kernel doesn't encounter oopses during a typical workload + - Occasional system reboot is not a problem in your use case + +I see a good compromise, which `kernel-hardening-checker` recommends: + - Enable the `CONFIG_BUG` kconfig option. If a kernel oops happens in the process context, the offending/attacking process is killed. In other cases, the kernel panics, which is similar to `CONFIG_PANIC_ON_OOPS=y`. + - Set the sysctl options `kernel.oops_limit` and `kernel.warn_limit` to `100`, for example. On the one hand, this value doesn't allow easy DoS. On the other hand, it is not too large to miss the vulnerability exploitation attempts generating a lot of kernel warnings or oopses.