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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <1324010389.2825.265.camel@deadeye>
Date:	Fri, 16 Dec 2011 04:39:49 +0000
From:	Ben Hutchings <ben@...adent.org.uk>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	"John W. Linville" <linville@...driver.com>,
	"Luis R. Rodriguez" <mcgrof@...jolero.org>,
	linux-kernel@...r.kernel.org, Dave Jones <davej@...hat.com>,
	Greg KH <greg@...ah.com>,
	Debian kernel maintainers <debian-kernel@...ts.debian.org>,
	linux-wireless@...r.kernel.org
Subject: Re: [RFC] modpost: add option to allow external modules to avoid
 taint

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@...driver.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@...driver.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.

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)