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-prev] [day] [month] [year] [list]

Message-ID: <87k45tnmgm.fsf@rustcorp.com.au>
Date:	Mon, 19 Dec 2011 16:15:45 +1030
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Ben Hutchings <ben@...adent.org.uk>
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, 16 Dec 2011 04:39:49 +0000, Ben Hutchings <ben@...adent.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@...driver.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/