lkml.org 
[lkml]   [2011]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC] modpost: add option to allow external modules to avoid taint
From
Date
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.
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2011-12-16 05:43    [W:0.222 / U:0.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site