linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ben Hutchings <ben@decadent.org.uk>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: "John W. Linville" <linville@tuxdriver.com>,
	"Luis R. Rodriguez" <mcgrof@frijolero.org>,
	linux-kernel@vger.kernel.org, Dave Jones <davej@redhat.com>,
	Greg KH <greg@kroah.com>,
	Debian kernel maintainers <debian-kernel@lists.debian.org>,
	linux-wireless@vger.kernel.org
Subject: Re: [RFC] modpost: add option to allow external modules to avoid taint
Date: Fri, 16 Dec 2011 04:39:49 +0000	[thread overview]
Message-ID: <1324010389.2825.265.camel@deadeye> (raw)
In-Reply-To: <87mxatp3ty.fsf@rustcorp.com.au>

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

On Fri, 2011-12-16 at 14:26 +1030, Rusty Russell wrote:
> On Wed, 14 Dec 2011 11:20:03 -0500, "John W. Linville" <linville@tuxdriver.com> wrote:
> > In some cases, it might be desirable to package a module from an
> > external source tree alongside the base kernel.  In those cases, it
> > might also be desirable to not have those modules tainting the kernel.
> > 
> > This patch provides a mechanism for an external module build to declare
> > itself as an "integrated build".  Such a module is then treated the same
> > as an intree module.
> > 
> > Signed-off-by: John W. Linville <linville@tuxdriver.com>
> > ---
> > Any thoughts on this?  I'm thinking of adding this to Fedora kernels,
> > where I have been working to integrate the compat-wireless package as
> > part of the base kernel RPM.
> 
> I don't think the feature is useful it it's too easy to disable.
> Experience has shown this with license tags.
> 
> We really want to indicate "out-of-support" which is only a 1:1
> mapping to out-of-tree for upstream kernels.

Who are 'we' in this instance?

> How does Debian handle this?

All the modules in Debian's kernel binary packages are built in-tree.
Backported modules are patched in as necessary.

Debian includes many packages of OOT modules, but those are supported by
their respective maintainers and not the kernel team.  So for the kernel
team, the 'O' flag does not mean 'unsupported' but may indicate that
another maintainer should handle the bug (or it may also be irrelevant
to the bug).

> Perhaps it makes more sense to use the proposed module signing stuff in
> a simplified mode to mark built-with-kernel modules (eg. just put the
> sha of known modules inside the kernel).

Unlike commercial distributions, no-one is paying Debian for support
contracts and no-one can game the system by hiding OOT modules.  So it's
probably not worthwhile for us to use module signing at all.

However, supposing we did go down this route, I would guess that
checksums for ~3000 modules take up more space than the signature
checking code.  Instead, we could perhaps generate a key pair during
build, include the public key in the kernel and then discard the private
key.  (But getting entropy would likely be a problem for the key
generation.)

Ben.

> I think we should revert this change, meanwhile, and figure out what to
> do.
> 
> Cheers,
> Rusty.
> 

-- 
Ben Hutchings
Computers are not intelligent.	They only think they are.

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

  parent reply	other threads:[~2011-12-16  4:40 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1319461948.31243.31.camel@deadeye>
2011-12-12 21:40 ` [PATCH] module,bug: Add TAINT_OOT_MODULE flag for modules not built in-tree Luis R. Rodriguez
2011-12-12 21:58   ` Ben Hutchings
2011-12-12 22:47     ` Luis R. Rodriguez
2011-12-12 22:49       ` Luis R. Rodriguez
2011-12-13  5:02       ` Ben Hutchings
2011-12-14 16:20         ` [RFC] modpost: add option to allow external modules to avoid taint John W. Linville
2011-12-14 16:52           ` Ben Hutchings
2011-12-14 17:39             ` John W. Linville
     [not found]           ` <87mxatp3ty.fsf@rustcorp.com.au>
2011-12-16  4:39             ` Ben Hutchings [this message]
2011-12-19  5:45               ` Rusty Russell

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=1324010389.2825.265.camel@deadeye \
    --to=ben@decadent.org.uk \
    --cc=davej@redhat.com \
    --cc=debian-kernel@lists.debian.org \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=mcgrof@frijolero.org \
    --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;
as well as URLs for NNTP newsgroup(s).