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

[Andy Lutomirski <luto@kernel.org>]

On 05/18/2015 09:20 AM, Linus Torvalds wrote:
> On Mon, May 18, 2015 at 9:04 AM, David Howells <dhowells@redhat.com> wrote:
>>
>> Should we instead provide a script:
>>
>>          ./scripts/generate-key
>>
>> That generates a key if run and make it so that the build fails if you turn on
>> module signing and there's no key.
>
> That would just be stupid.
>
> I'm not ever applying a patch like that. That would absolutely destroy
> the sane "git clean + rebuild" model.
>
> Why the hell would you want to make the sane case that people actually
> *use* be harder to use.
>
> Nobody sane bothers with long-term keys. They are inconvenient and less secure.
>
> Put the onus on making it inconvenient on those people who actually
> have special keys, not on normal people.
>

I think we should get rid of the idea of automatically generated signing 
keys entirely.  Instead I think we should generate, at build time, a 
list of all the module hashes and link that into vmlinux.

If we want to make it better, we could instead have a concept of 
dynamically loadable module verifiers.  A module is acceptable if any of 
the verifiers approve.  We autogenerate module_hashes.ko, which 
registers a verifier that accepts the modules that were built by the 
kernel build in question.  The main vmlinux image includes another 
verifier that accepts *only* module_hashes.ko as built by the build in 
question.

Then, if anyone actually wants to use a public key to verify modules, 
they can build the public key into a module as opposed to dragging all 
of the public key crud into the main kernel image.

Also, this scheme is compatible with deterministic builds, whereas the 
current scheme is fundamentally broken if you try to deterministically 
build a kernel without trusting some key issuer.

--Andy