Date: Thu, 30 Sep 2021 21:27:43 +0300 From: Alexander Popov <alex.popov@...ux.com> To: Andrew Morton <akpm@...ux-foundation.org> Cc: Jonathan Corbet <corbet@....net>, Paul McKenney <paulmck@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, Peter Zijlstra <peterz@...radead.org>, Joerg Roedel <jroedel@...e.de>, Maciej Rozycki <macro@...am.me.uk>, Muchun Song <songmuchun@...edance.com>, Viresh Kumar <viresh.kumar@...aro.org>, Robin Murphy <robin.murphy@....com>, Randy Dunlap <rdunlap@...radead.org>, Lu Baolu <baolu.lu@...ux.intel.com>, Petr Mladek <pmladek@...e.com>, Kees Cook <keescook@...omium.org>, Luis Chamberlain <mcgrof@...nel.org>, Wei Liu <wl@....org>, John Ogness <john.ogness@...utronix.de>, Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, Alexey Kardashevskiy <aik@...abs.ru>, Christophe Leroy <christophe.leroy@...roup.eu>, Jann Horn <jannh@...gle.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Mark Rutland <mark.rutland@....com>, Andy Lutomirski <luto@...nel.org>, Dave Hansen <dave.hansen@...ux.intel.com>, Steven Rostedt <rostedt@...dmis.org>, Will Deacon <will.deacon@....com>, David S Miller <davem@...emloft.net>, Borislav Petkov <bp@...en8.de>, kernel-hardening@...ts.openwall.com, linux-hardening@...r.kernel.org, linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org, notify@...nel.org Subject: Re: [PATCH] Introduce the pkill_on_warn boot parameter On 30.09.2021 02:31, Andrew Morton wrote: > On Wed, 29 Sep 2021 22:01:33 +0300 Alexander Popov <alex.popov@...ux.com> 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@...ux.com> >> >> 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? I would say we need both sysctl and boot parameter for pkill_on_warn. That would be consistent with panic_on_warn, ftrace_dump_on_oops and oops/panic_on_oops. > 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? A kernel warning may occur at any moment. I don't have a deep understanding of possible side effects on early boot stages. So I decided that at least it's safer to avoid interfering before SYSTEM_RUNNING. Best regards, Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.