From: Kees Cook <keescook@chromium.org>
To: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Cc: linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
Sasha Levin <sashal@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
rcu@vger.kernel.org, Tejun Heo <tj@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 2/2] kernel: add sysctl kernel.nr_taints
Date: Sat, 30 Nov 2019 08:33:44 -0800 [thread overview]
Message-ID: <201911300823.69EAF975E9@keescook> (raw)
In-Reply-To: <157503370887.8187.1663761929323284758.stgit@buzz>
On Fri, Nov 29, 2019 at 04:21:48PM +0300, Konstantin Khlebnikov wrote:
> Once taint flag is set it's never cleared. Following taint could be detected
> only via parsing kernel log messages which are different for each occasion.
> For repeatable taints like TAINT_MACHINE_CHECK, TAINT_BAD_PAGE, TAINT_DIE,
> TAINT_WARN, TAINT_LOCKUP it would be good to know count to see their rate.
>
> This patch adds sysctl with vector of counters. One for each taint flag.
> Counters are non-atomic in favor of simplicity. Exact count doesn't matter.
> Writing vector of zeroes resets counters.
>
> This is useful for detecting frequent problems with automatic monitoring.
>
> Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
I like this, yeah. This would let LKDTM users reset taint counts to
re-check the same kernel, etc, without explicitly clearing the taint
flags which always seemed like a bad idea. :)
Reviewed-by: Kees Cook <keescook@chromium.org>
One nit below...
> ---
> include/linux/kernel.h | 1 +
> kernel/panic.c | 2 ++
> kernel/sysctl.c | 9 +++++++++
> 3 files changed, 12 insertions(+)
>
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index e8a6808e4f2f..900d02167bbd 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -604,6 +604,7 @@ struct taint_flag {
> };
>
> extern const struct taint_flag taint_flags[TAINT_FLAGS_COUNT];
> +extern int sysctl_nr_taints[TAINT_FLAGS_COUNT];
>
> extern const char hex_asc[];
> #define hex_asc_lo(x) hex_asc[((x) & 0x0f)]
> diff --git a/kernel/panic.c b/kernel/panic.c
> index d7750a45ca8d..a3df00ebcba2 100644
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -39,6 +39,7 @@
> int panic_on_oops = CONFIG_PANIC_ON_OOPS_VALUE;
> static unsigned long tainted_mask =
> IS_ENABLED(CONFIG_GCC_PLUGIN_RANDSTRUCT) ? (1 << TAINT_RANDSTRUCT) : 0;
> +int sysctl_nr_taints[TAINT_FLAGS_COUNT];
> static int pause_on_oops;
> static int pause_on_oops_flag;
> static DEFINE_SPINLOCK(pause_on_oops_lock);
> @@ -434,6 +435,7 @@ void add_taint(unsigned flag, enum lockdep_ok lockdep_ok)
> pr_warn("Disabling lock debugging due to kernel taint\n");
>
> set_bit(flag, &tainted_mask);
> + sysctl_nr_taints[flag]++;
As long as we're changing this code, how about adding an explicit check
of "flag" against either ARRAY_SIZE(sysctl_nr_tains) or TAINT_FLAGS_COUNT?
It looks like only 1 caller isn't using a static value, though:
proc_taint(), so it would catch "overflows" there (it's already bounded
to the size of tainted_mask, but proc could set "unknown" taint flags).
-Kees
> }
> EXPORT_SYMBOL(add_taint);
>
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index b6f2f35d0bcf..5d9727556cef 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -553,6 +553,15 @@ static struct ctl_table kern_table[] = {
> .mode = 0644,
> .proc_handler = proc_taint,
> },
> + {
> + .procname = "nr_taints",
> + .data = &sysctl_nr_taints,
> + .maxlen = sizeof(sysctl_nr_taints),
> + .mode = 0644,
> + .proc_handler = proc_dointvec_minmax,
> + .extra1 = SYSCTL_ZERO,
> + .extra2 = SYSCTL_ZERO,
> + },
> {
> .procname = "sysctl_writes_strict",
> .data = &sysctl_writes_strict,
>
--
Kees Cook
next prev parent reply other threads:[~2019-11-30 16:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-29 13:21 [PATCH 1/2] kernel: set taint flag 'L' at any kind of lockup Konstantin Khlebnikov
2019-11-29 13:21 ` [PATCH 2/2] kernel: add sysctl kernel.nr_taints Konstantin Khlebnikov
2019-11-30 16:33 ` Kees Cook [this message]
2019-11-30 16:22 ` [PATCH 1/2] kernel: set taint flag 'L' at any kind of lockup Kees Cook
2019-12-02 20:03 ` Paul E. McKenney
2020-01-16 11:19 ` Thomas Gleixner
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=201911300823.69EAF975E9@keescook \
--to=keescook@chromium.org \
--cc=akpm@linux-foundation.org \
--cc=gregkh@linuxfoundation.org \
--cc=khlebnikov@yandex-team.ru \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rcu@vger.kernel.org \
--cc=sashal@kernel.org \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.org \
/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