Re: [RFC] modpost: add option to allow external modules to avoid taint
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.
Reply to: