Re: [RFC][PATCH 2/2] modsig: differentiate between ephemeral andpersistent key names

[Mimi Zohar]

On Mon, 2012-12-03 at 11:56 +1030, Rusty Russell wrote:
> Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> writes:
> > Using the same name for ephemeral and "persistent" keys results
> > in deleting the "persistent" key.  This patch renames the normal
> > kbuild asymmetric key pair name to "default_signing_key" and the
> > ephemeral key pair name to "ephemeral_signing_key".
> 
> I like the idea: I was always uncomfortable with the mixing of
> persistent and temporary keys.  But it's a bit misguided, because surely
> persistent keys don't belong in the build tree at all.

The original intent of the patch was to differentiate between a key
generated as part of the kbuild process, that exists for an indefinite
period of time, versus an ephemeral key, which is created and
immediately thrown away, after signing the kernel modules.

> 
> How about we do something like:
> 
> # Default to temporary keys
> MODKEYPREFIX = ./temp_signing_key
> 
> MODSECKEY = $(MODKEYPREFIX).priv
> MODPUBKEY = $(MODKEYPREFIX).x509
> 
> Then encourage people to do:
> 
>         make MODKEYPREFIX=...

Although your suggestion addresses a different use case scenario, I like
it a lot.  Fortunately, it also works for the above ephemeral use case.
The default temporary key would be persistent across builds, while an
ephemeral key could be defined as "MODKEYPREFIX
= ./ephemeral_signing_key".

My main concern is having to force modsign_pubkey to be rebuilt each and
every time, since there is no way of knowing which key was previously
included.

> We could also use a config option to set the path, but that's probably
> less convenient.

Definitely less convenient.  I assume the normal use case for developers
would be multiple builds, followed by an install.  Each build shouldn't
require regenerating a new keypair, nor at the point that we're ready to
sign and install the kernel modules and image, do we want to change
the .config, which would result in additional, as you put it, root owned
turds.

thanks,

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/