[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200515202656.GZ11244@42.do-not-panic.com>
Date: Fri, 15 May 2020 20:26:56 +0000
From: Luis Chamberlain <mcgrof@...nel.org>
To: Rafael Aquini <aquini@...hat.com>
Cc: linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
kexec@...ts.infradead.org, linux-fsdevel@...r.kernel.org,
dyoung@...hat.com, bhe@...hat.com, corbet@....net,
keescook@...omium.org, akpm@...ux-foundation.org, cai@....pw,
rdunlap@...radead.org, tytso@....edu, bunk@...nel.org,
torvalds@...ux-foundation.org, gregkh@...uxfoundation.org,
labbott@...hat.com, jeffm@...e.com, jikos@...nel.org, jeyu@...e.de,
tiwai@...e.de, AnDavis@...e.com, rpalethorpe@...e.de
Subject: Re: [PATCH v5] kernel: add panic_on_taint
On Fri, May 15, 2020 at 01:55:02PM -0400, Rafael Aquini wrote:
> Analogously to the introduction of panic_on_warn, this patch introduces a kernel
> option named panic_on_taint in order to provide a simple and generic way to stop
> execution and catch a coredump when the kernel gets tainted by any given flag.
>
> This is useful for debugging sessions as it avoids having to rebuild the kernel
> to explicitly add calls to panic() into the code sites that introduce the taint
> flags of interest. For instance, if one is interested in proceeding with a
> post-mortem analysis at the point a given code path is hitting a bad page
> (i.e. unaccount_page_cache_page(), or slab_bug()), a coredump can be collected
> by rebooting the kernel with 'panic_on_taint=0x20' amended to the command line.
>
> Another, perhaps less frequent, use for this option would be as a mean for
> assuring a security policy case where only a subset of taints, or no single
> taint (in paranoid mode), is allowed for the running system.
> The optional switch 'nousertaint' is handy in this particular scenario,
> as it will avoid userspace induced crashes by writes to sysctl interface
> /proc/sys/kernel/tainted causing false positive hits for such policies.
>
> Suggested-by: Qian Cai <cai@....pw>
> Signed-off-by: Rafael Aquini <aquini@...hat.com>
Reviewed-by: Luis Chamberlain <mcgrof@...nel.org>
Luis
Powered by blists - more mailing lists