lkml.org 
[lkml]   [2015]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Should we automatically generate a module signing key at all?
On Thu, May 21, 2015 at 5:03 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, May 21, 2015 at 4:54 PM, George Spelvin <linux@horizon.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


\
 
 \ /
  Last update: 2015-05-22 02:41    [W:0.078 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site