kernel-hardening.lists.openwall.com archive mirror
 help / color / mirror / Atom feed
From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Steven Rostedt <rostedt@goodmis.org>,
	Lukas Bulwahn <lukas.bulwahn@gmail.com>
Cc: Alexander Popov <alex.popov@linux.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Paul McKenney <paulmck@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Joerg Roedel <jroedel@suse.de>,
	Maciej Rozycki <macro@orcam.me.uk>,
	Muchun Song <songmuchun@bytedance.com>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	Lu Baolu <baolu.lu@linux.intel.com>,
	Petr Mladek <pmladek@suse.com>, Kees Cook <keescook@chromium.org>,
	Luis Chamberlain <mcgrof@kernel.org>, Wei Liu <wl@xen.org>,
	John Ogness <john.ogness@linutronix.de>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Alexey Kardashevskiy <aik@ozlabs.ru>,
	Jann Horn <jannh@google.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Andy Lutomirski <luto@kernel.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Will Deacon <will@kernel.org>, Ard Biesheuvel <ardb@kernel.org>,
	Laura Abbott <labbott@kernel.org>,
	David S Miller <davem@davemloft.net>,
	Borislav Petkov <bp@alien8.de>, Arnd Bergmann <arnd@arndb.de>,
	Andrew Scull <ascull@google.com>, Marc Zyngier <maz@kernel.org>,
	Jessica Yu <jeyu@kernel.org>, Iurii Zaikin <yzaikin@google.com>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Wang Qing <wangqing@vivo.com>, Mel Gorman <mgorman@suse.de>,
	Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
	Andrew Klychkov <andrew.a.klychkov@gmail.com>,
	Mathieu Chouquet-Stringer <me@mathieu.digital>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Stephen Kitt <steve@sk2.org>, Stephen Boyd <sboyd@kernel.org>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Mike Rapoport <rppt@kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Kernel Hardening <kernel-hardening@lists.openwall.com>,
	linux-hardening@vger.kernel.org,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	notify@kernel.org, main@lists.elisa.tech,
	safety-architecture@lists.elisa.tech, devel@lists.elisa.tech,
	Shuah Khan <shuah@kernel.org>
Subject: Re: [PATCH v2 0/2] Introduce the pkill_on_warn parameter
Date: Tue, 16 Nov 2021 07:37:29 +0100	[thread overview]
Message-ID: <380a8fd0-d7c3-2487-7cd5-e6fc6e7693d9@csgroup.eu> (raw)
In-Reply-To: <20211115110649.4f9cb390@gandalf.local.home>



Le 15/11/2021 à 17:06, Steven Rostedt a écrit :
> On Mon, 15 Nov 2021 14:59:57 +0100
> Lukas Bulwahn <lukas.bulwahn@gmail.com> wrote:
> 
>> 1. Allow a reasonably configured kernel to boot and run with
>> panic_on_warn set. Warnings should only be raised when something is
>> not configured as the developers expect it or the kernel is put into a
>> state that generally is _unexpected_ and has been exposed little to
>> the critical thought of the developer, to testing efforts and use in
>> other systems in the wild. Warnings should not be used for something
>> informative, which still allows the kernel to continue running in a
>> proper way in a generally expected environment. Up to my knowledge,
>> there are some kernels in production that run with panic_on_warn; so,
>> IMHO, this requirement is generally accepted (we might of course
> 
> To me, WARN*() is the same as BUG*(). If it gets hit, it's a bug in the
> kernel and needs to be fixed. I have several WARN*() calls in my code, and
> it's all because the algorithms used is expected to prevent the condition
> in the warning from happening. If the warning triggers, it means either that
> the algorithm is wrong or my assumption about the algorithm is wrong. In
> either case, the kernel needs to be updated. All my tests fail if a WARN*()
> gets hit (anywhere in the kernel, not just my own).
> 
> After reading all the replies and thinking about this more, I find the
> pkill_on_warning actually worse than not doing anything. If you are
> concerned about exploits from warnings, the only real solution is a
> panic_on_warning. Yes, it brings down the system, but really, it has to be
> brought down anyway, because it is in need of a kernel update.
> 

We also have LIVEPATCH to avoid bringing down the system for a kernel 
update, don't we ? So I wouldn't expect bringing down a vital system 
just for a WARN.

As far as I understand from 
https://www.kernel.org/doc/html/latest/process/deprecated.html#bug-and-bug-on, 
WARN() and WARN_ON() are meant to deal with those situations as 
gracefull as possible, allowing the system to continue running the best 
it can until a human controled action is taken.

So I'd expect the WARN/WARN_ON to be handled and I agree that that 
pkill_on_warning seems dangerous and unrelevant, probably more dangerous 
than doing nothing, especially as the WARN may trigger for a reason 
which has nothing to do with the running thread.

Christophe

  parent reply	other threads:[~2021-11-16  6:44 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-27 23:32 [PATCH v2 0/2] Introduce the pkill_on_warn parameter Alexander Popov
2021-10-27 23:32 ` [PATCH v2 1/2] bug: do refactoring allowing to add a warning handling action Alexander Popov
2021-10-27 23:32 ` [PATCH v2 2/2] sysctl: introduce kernel.pkill_on_warn Alexander Popov
2021-11-12 21:24   ` Steven Rostedt
2021-11-12 18:52 ` [PATCH v2 0/2] Introduce the pkill_on_warn parameter Alexander Popov
2021-11-12 21:26   ` Linus Torvalds
2021-11-13 18:14     ` Alexander Popov
2021-11-13 19:58       ` Linus Torvalds
2021-11-14 14:21         ` Marco Elver
2021-11-15 13:59       ` Lukas Bulwahn
2021-11-15 15:51         ` [ELISA Safety Architecture WG] " Gabriele Paoloni
2021-11-16  7:52           ` Alexander Popov
2021-11-16  8:01             ` Lukas Bulwahn
2021-11-16  8:41             ` Petr Mladek
2021-11-16  9:19               ` Lukas Bulwahn
2021-11-16 13:20               ` James Bottomley
2021-11-15 15:52         ` Robert Krutsch
2021-11-15 16:06         ` Steven Rostedt
2021-11-15 22:06           ` Kees Cook
2021-11-16  9:12             ` Alexander Popov
2021-11-16 18:41               ` Kees Cook
2021-11-16 19:00                 ` Casey Schaufler
2021-11-18 17:32                   ` Kees Cook
2021-11-18 18:30                     ` Casey Schaufler
2021-11-18 20:29                       ` Kees Cook
2021-11-16 13:07             ` James Bottomley
2021-11-20 12:17             ` Marco Elver
2021-11-22 16:21               ` Steven Rostedt
2021-11-16  6:37           ` Christophe Leroy [this message]
2021-11-16  8:34             ` Alexander Popov
2021-11-16  8:57             ` Lukas Bulwahn
2021-11-15  8:12 ` Kaiwan N Billimoria

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=380a8fd0-d7c3-2487-7cd5-e6fc6e7693d9@csgroup.eu \
    --to=christophe.leroy@csgroup.eu \
    --cc=aik@ozlabs.ru \
    --cc=akpm@linux-foundation.org \
    --cc=alex.popov@linux.com \
    --cc=andrew.a.klychkov@gmail.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=ascull@google.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=daniel@iogearbox.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=davem@davemloft.net \
    --cc=devel@lists.elisa.tech \
    --cc=gregkh@linuxfoundation.org \
    --cc=jannh@google.com \
    --cc=jeyu@kernel.org \
    --cc=john.ogness@linutronix.de \
    --cc=jroedel@suse.de \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=labbott@kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=lukas.bulwahn@gmail.com \
    --cc=luto@kernel.org \
    --cc=macro@orcam.me.uk \
    --cc=main@lists.elisa.tech \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=mchehab+huawei@kernel.org \
    --cc=me@mathieu.digital \
    --cc=mgorman@suse.de \
    --cc=notify@kernel.org \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=pmladek@suse.com \
    --cc=rdunlap@infradead.org \
    --cc=robin.murphy@arm.com \
    --cc=rostedt@goodmis.org \
    --cc=rppt@kernel.org \
    --cc=safety-architecture@lists.elisa.tech \
    --cc=sboyd@kernel.org \
    --cc=shuah@kernel.org \
    --cc=songmuchun@bytedance.com \
    --cc=steve@sk2.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=tsbogend@alpha.franken.de \
    --cc=viresh.kumar@linaro.org \
    --cc=wangqing@vivo.com \
    --cc=will@kernel.org \
    --cc=wl@xen.org \
    --cc=yzaikin@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).