On Wed, 29 Sep 2021 22:01:33 +0300 Alexander Popov <alex.popov@xxxxxxxxx> wrote: > On 29.09.2021 21:58, Alexander Popov wrote: > > Currently, the Linux kernel provides two types of reaction to kernel > > warnings: > > 1. Do nothing (by default), > > 2. Call panic() if panic_on_warn is set. That's a very strong reaction, > > so panic_on_warn is usually disabled on production systems. > > > > From a safety point of view, the Linux kernel misses a middle way of > > handling kernel warnings: > > - The kernel should stop the activity that provokes a warning, > > - But the kernel should avoid complete denial of service. > > > > 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 infoleak in vulnerability exploits. See the examples: > > https://a13xp0p0v.github.io/2020/02/15/CVE-2019-18683.html > > https://a13xp0p0v.github.io/2021/02/09/CVE-2021-26708.html > > > > 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. > > > > Signed-off-by: Alexander Popov <alex.popov@xxxxxxxxx> > > This patch was tested using CONFIG_LKDTM. > The kernel kills a process that performs this: > echo WARNING > /sys/kernel/debug/provoke-crash/DIRECT > > If you are fine with this approach, I will prepare a patch adding the > pkill_on_warn sysctl. Why do we need a boot parameter? Isn't a sysctl all we need for this feature? Also, if (pkill_on_warn && system_state >= SYSTEM_RUNNING) do_group_exit(SIGKILL); - why do we care about system_state? An explanatory code comment seems appropriate. - do we really want to do this in states > SYSTEM_RUNNING? If so, why?
