From: Jessica Yu <jeyu@kernel.org>
To: Matthew Garrett <mjg59@google.com>
Cc: Ben Hutchings <ben@decadent.org.uk>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Make kernel taint on invalid module signatures configurable
Date: Thu, 15 Feb 2018 16:25:16 +0100 [thread overview]
Message-ID: <20180215152514.rxmh7webdg2i2fct@redbean> (raw)
In-Reply-To: <CACdnJus-X533K0Bgqjc-MoZ2NbLz0ac9x+rryHUtnjrnmJ+Kmg@mail.gmail.com>
+++ Matthew Garrett [14/02/18 18:21 +0000]:
>Hi Jessica,
>
>Any objections to this patch?
>
>Thanks!
Hi Matthew!
My questions and comments from last year still apply here -
http://lkml.kernel.org/r/20170829175647.ej5fqszss2mbpc5i@redbean
I'm still unclear on why a distro would enable CONFIG_MODULE_SIG and
then _not_ want to know about unsigned modules.
>From what I understand from Ben's post from last year
(http://lkml.kernel.org/r/1504044122.4448.24.camel@decadent.org.uk),
it sounds like the main issue is that Debian doesn't support their own
centralised module signing yet, causing all of their modules to be
automatically tainted if they enable CONFIG_MODULE_SIG, and that a new
option like this would likely be used as a temporary "fix". Am I
understanding correctly?
I understand this predicament, but it seems like adding a new set of
options/parameters like this is just hiding the symptoms of the
problem (modules distributed by Debian getting tainted by default)
instead of fixing what seems to be the heart of the issue (Debian
doesn't support their own module signing yet), if that makes sense.
I am hesitant about merging something that would only serve as a
temporary solution until Debian supports their own module signing. In
that case, I would prefer the Debian folks to maintain their own patch
removing the taint until they support module signing for their own
modules, especially if - and please correct me if I'm wrong - the
new option is not going to see long-term usage.
Thanks,
Jessica
next prev parent reply other threads:[~2018-02-15 18:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-07 19:50 Matthew Garrett
2018-02-14 18:21 ` Matthew Garrett
2018-02-15 15:25 ` Jessica Yu [this message]
2018-02-15 19:36 ` Matthew Garrett
2018-02-16 8:24 ` Philipp Hahn
2018-02-17 0:08 ` Matthew Garrett
2018-02-20 19:21 ` Jessica Yu
2018-02-20 20:37 ` Matthew Garrett
2018-02-20 21:23 ` Jessica Yu
2018-02-21 14:59 ` Ben Hutchings
2018-02-20 21:44 ` Jessica Yu
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=20180215152514.rxmh7webdg2i2fct@redbean \
--to=jeyu@kernel.org \
--cc=ben@decadent.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg59@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
all inboxes | Powered by JetHome®