Zack's Kernel News

Best Laid Plans

When the Linux kernel encountered a runtime warning, Alexander Popov didn't like that it had only two possible responses: Ignore the whole thing, or panic (i.e., crash 'n' burn). The crash 'n' burn response would trigger if the user had set the panic_on_warn flag. Otherwise, the warning would be ignored. Alexander felt that a nice middle-of-the-road response would be for the kernel to simply stop whatever it was that caused the warning. This way at least the system could still function.

Alexander also pointed out some security problems with the current state of affairs. He said that to avoid the extreme response, "panic_on_warn is usually disabled on production systems." And, "From a security point of view, kernel warning messages provide a lot of useful information for attackers. Many GNU/Linux distributions allow unprivileged users to read the kernel log, so attackers use kernel warning info leak in vulnerability exploits."

Alexander proposed a compromise so that system administrators and distribution maintainers would not feel the need to completely disable all responses to kernel warnings. He said, "Let's introduce the pkill_on_warn boot parameter. If this parameter is set, the kernel kills all threads in a process that provoked a kernel warning. This behavior is reasonable from a safety point of view described above. It is also useful for kernel security hardening because the system kills an exploit process that hits a kernel warning."

[...]