From: Jessica Yu <jeyu@kernel.org>
To: Matthew Garrett <mjg59@google.com>
Cc: linux-kernel@vger.kernel.org, rusty@rustcorp.com.au
Subject: Re: Allow automatic kernel taint on unsigned module load to be disabled
Date: Thu, 10 Aug 2017 22:43:28 +0200 [thread overview]
Message-ID: <20170810204328.kk4lbj4hvednmofw@redbean> (raw)
In-Reply-To: <20170804180751.14896-1-mjg59@google.com>
+++ Matthew Garrett [04/08/17 11:07 -0700]:
>Distributions may wish to provide kernels that permit loading of
>unsigned modules based on certain policy decisions. Right now that
>results in the kernel being tainted whenever an unsigned module is
>loaded, which may not be desirable. Add a config option to disable that.
Hi Matthew!
I think I'm missing some context here. Could you provide some more
background and help me understand why we want to go into all this
trouble just to avoid a taint? Was there a recent bug report, mailing
list discussion, etc. that spurred you to write this patch? I'm not
understanding why this particular taint is undesirable.
I still think there is informational value in providing the unsigned
module taint on a kernel that supports module signatures (CONFIG_MODULE_SIG).
When debugging or trawling through crash dumps, module taints are
useful for developers to immediately identify which modules were
out-of-tree, which were unsigned and therefore not originally shipped
by the distro etc, which often applies to e.g. 3rd party/dkms modules.
And if a user for example locally compiles a module without signing it
why would the unsigned module taint bother them more than the
out-of-tree one (because that module would get both taints)?
If it is the "module verification failed" message that is actually
scaring users, we could perhaps "soften" it to say something like
"loading unsigned module X".
Jessica
>Signed-off-by: Matthew Garrett <mjg59@google.com>
>---
> init/Kconfig | 13 ++++++++++++-
> kernel/module.c | 2 ++
> 2 files changed, 14 insertions(+), 1 deletion(-)
>
>diff --git a/init/Kconfig b/init/Kconfig
>index 8514b25db21c..196860c5d1e5 100644
>--- a/init/Kconfig
>+++ b/init/Kconfig
>@@ -1749,12 +1749,23 @@ config MODULE_SIG
> debuginfo strip done by some packagers (such as rpmbuild) and
> inclusion into an initramfs that wants the module size reduced.
>
>+config MODULE_UNSIGNED_TAINT
>+ bool "Taint the kernel if unsigned modules are loaded"
>+ default y
>+ depends on MODULE_SIG
>+ help
>+ Taint the kernel if an unsigned kernel module is loaded. If this
>+ option is enabled, the kernel will be tainted on an attempt to load
>+ an unsigned module or signed modules for which we don't have a key
>+ even if signature enforcement is disabled.
>+
> config MODULE_SIG_FORCE
> bool "Require modules to be validly signed"
> depends on MODULE_SIG
> help
> Reject unsigned modules or signed modules for which we don't have a
>- key. Without this, such modules will simply taint the kernel.
>+ key. Without this, such modules will be loaded successfully but will
>+ (if MODULE_UNSIGNED_TAINT is set) taint the kernel.
>
> config MODULE_SIG_ALL
> bool "Automatically sign all modules"
>diff --git a/kernel/module.c b/kernel/module.c
>index 40f983cbea81..71f80c8816f2 100644
>--- a/kernel/module.c
>+++ b/kernel/module.c
>@@ -3660,12 +3660,14 @@ static int load_module(struct load_info *info, const char __user *uargs,
>
> #ifdef CONFIG_MODULE_SIG
> mod->sig_ok = info->sig_ok;
>+#ifdef CONFIG_MODULE_UNSIGNED_TAINT
> if (!mod->sig_ok) {
> pr_notice_once("%s: module verification failed: signature "
> "and/or required key missing - tainting "
> "kernel\n", mod->name);
> add_taint_module(mod, TAINT_UNSIGNED_MODULE, LOCKDEP_STILL_OK);
> }
>+#endif
> #endif
>
> /* To avoid stressing percpu allocator, do this once we're unique. */
>--
>2.14.0.rc1.383.gd1ce394fe2-goog
>
next prev parent reply other threads:[~2017-08-10 20:43 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-04 18:07 [PATCH] " Matthew Garrett
2017-08-06 6:54 ` Rusty Russell
2017-08-06 17:34 ` Matthew Garrett
2017-08-07 2:49 ` Rusty Russell
2017-08-07 3:23 ` Matthew Garrett
2017-08-07 4:47 ` Rusty Russell
2017-08-07 5:31 ` Matthew Garrett
2017-08-10 20:43 ` Jessica Yu [this message]
2017-08-14 16:50 ` Matthew Garrett
2017-08-29 17:56 ` Jessica Yu
2017-08-29 20:22 ` Matthew Garrett
2017-08-29 22:02 ` Ben Hutchings
2017-10-18 18:27 ` Matthew Garrett
2018-01-30 19:00 ` Matthew Garrett
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=20170810204328.kk4lbj4hvednmofw@redbean \
--to=jeyu@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg59@google.com \
--cc=rusty@rustcorp.com.au \
/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
all inboxes | Powered by JetHome®