linux-kernel - Re: Should we automatically generate a module signing key at all?

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

Date:	Thu, 21 May 2015 17:10:54 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	George Spelvin <linux@...izon.com>,
	David Howells <dhowells@...hat.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	LSM List <linux-security-module@...r.kernel.org>,
	petkan@...-labs.com, "Theodore Ts'o" <tytso@....edu>,
	Mimi Zohar <zohar@...ux.vnet.ibm.com>
Subject: Re: Should we automatically generate a module signing key at all?

On Thu, May 21, 2015 at 5:03 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Thu, May 21, 2015 at 4:54 PM, George Spelvin <linux@...izon.com> wrote:
>>
>> The annoying thing is that it's a two-pass process: the kernel has to
>> have the hashes of ALL of the modules to generate the sibling hashes
>> for ANY of them.
>
> It's also very annoying because the whole build gets much nastier,
> particularly if you want to have modules in external trees.
>
> In short, I don't see any actual *advantages* over just using signed
> modules. Signing is much more flexible, and thanks to that extra
> indirection (the signing key), there are no ordering constraints on
> generating modules vs the kernel.
>
> I realize that people have political objections to signing, but it's
> the better technology, for chissake!

I still claim that reproducible builds are technical, not political.
CONFIG_MODULE_SIGN_ALL=y is literally the only thing in the kernel
that's incompatible with reproducible builds.

Yes, the build gets messier, but it's not that bad.  It's even less
bad if we'd be willing to accept kmod changes as a prerequisite (so
kmod would generate the proofs on the fly from a little database
instead of appending the proof to each .ko file

There's even a (nasty) implementation:
https://wiki.debian.org/SameKernel  I'm sure we could make it much
cleaner (and even make it a normal config option that would generate a
bzImage that depends only on the kernel tree and exact toolchain
version) if we put a bit of effort in.

--Andy
--
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/