Re: [RFC] modpost: add option to allow external modules to avoid taint

[Rusty Russell <rusty@rustcorp.com.au>]

On Fri, 16 Dec 2011 04:39:49 +0000, Ben Hutchings <ben@decadent.org.uk> wrote:
Non-text part: multipart/signed
> 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:
> > 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?

Whoever turns this flag on.  I was using friendly, inclusive language :)

> > 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).

So, in your case, the kernel team want to know what's outside their
support, so this flag works well for you.

As John pointed out, it's a bit useless for them.  We could enable it
with a config option, or they could ignore it, since they're going to
module-signing route anyway.

> > 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.)

Agreed, 60k is a bit expensive for this minor feature.  

Thanks,
Rusty.