All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Hutchings <ben@decadent.org.uk>
To: Matthew Garrett <mjg59@google.com>, Jessica Yu <jeyu@kernel.org>
Cc: linux-kernel@vger.kernel.org, Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: Allow automatic kernel taint on unsigned module load to be disabled
Date: Tue, 29 Aug 2017 23:02:02 +0100	[thread overview]
Message-ID: <1504044122.4448.24.camel@decadent.org.uk> (raw)
In-Reply-To: <CACdnJutWdHi5YOG1Mn0vZwTmZyQHyyABeZ0caNn2rJCYehCGhg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1841 bytes --]

On Tue, 2017-08-29 at 13:22 -0700, Matthew Garrett wrote:
> > On Tue, Aug 29, 2017 at 10:56 AM, Jessica Yu <jeyu@kernel.org> wrote:
> > I understand what the patch is doing, what I don't yet understand is
> > _why_ you would want to remove the unsigned module taint when
> > CONFIG_MODULE_SIG is enabled. Which distributions are asking for this
> > exactly, and for what use cases? I find it a bit contradictory to have
> > CONFIG_MODULE_SIG enabled and at the same time expect the kernel to
> > behave as if the option wasn't enabled.
> 
> Debian disable CONFIG_MODULE_SIG because of this additional taint
> (I've Cc:ed Ben who made this change).

The current state of affairs is that Debian doesn't have the mechanism
in place to sign modules with a trusted key.  If we were to allow third
parties to add signatures in some way (I think that's what Matthew's
interested in doing) we would have to enabled CONFIG_MODULE_SIG, but
that would cause modules to be tainted by default.

> > I would really prefer not to add extra code to remove what is cosmetic
> > and still has informational/debug value. If the unsigned module taint
> > is for whatever reason that bothersome, why can't distro(s) carry a
> > 2-line patch removing the message and taint for those particular
> > setups where signatures are considered "irrelevant" even with
> > CONFIG_MODULE_SIG=y?
> 
> If it's functionality that distributions want to patch out, it makes
> sense to provide them with a config option rather than forcing them to
> maintain a patch separately.

We could use this in Debian.  It would likely be a temporary stage
until we do our own centralised module signing (or someone implements a
Merkle tree for in-tree modules).

Ben.

-- 
Ben Hutchings
Teamwork is essential - it allows you to blame someone else.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2017-08-29 22:02 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-04 18:07 [PATCH] Allow automatic kernel taint on unsigned module load to be disabled 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
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 [this message]
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=1504044122.4448.24.camel@decadent.org.uk \
    --to=ben@decadent.org.uk \
    --cc=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.