Messages in this thread | | | Subject | Re: [RFC][PATCH 2/2] modsig: differentiate between ephemeral and persistent key names | From | Mimi Zohar <> | Date | Sun, 02 Dec 2012 23:09:29 -0500 |
| |
On Mon, 2012-12-03 at 11:56 +1030, Rusty Russell wrote: > Mimi Zohar <zohar@linux.vnet.ibm.com> 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
| |