On Fri, Aug 17, 2012 at 1:08 PM, Mimi Zohar <zo...@linux.vnet.ibm.com> wrote: >> I don't see a need for the kernel make system to ever delete a key. >> If one doesn't exist, it should create one if the config options are >> set and leave it alone entirely after that. If one exists already, >> then it should leave it alone as it already does. > > Ok. Other than generating a key the first time, the normal development > build process now uses the same key, never requiring the developer to do > anything additional. The developer controls the frequency the keys are > created/deleted. I wonder how often that will be ...
For a developer, probably not often. Though in reality, the usage of this by a single developer seems fair small. A much wider, already existing usage is distribution kernel signing. For a distribution kernel there are normally two cases: 1) Existing permanent company/distro key. This is already handled. 2) per-kernel-build key (equivalent to your ephemeral key). This would be handled fine if the key was generated if it didn't already exist and left alone. The distro build system would remove it when it cleaned up the buildroot. >> If you really want to enforce ephemeral keys in the make system, then >> doing it via 'make clean' or 'make distclean' would make more sense to >> me. But I personally think key management is something the developers >> or distros should be handling on their own. Creating a key for them is >> a convenience so it's worthwhile, but removing it should be done by >> them. > > Sorry, I disagree. Without the signed_modules_install target, the > developer would need to do each step manually - create new key, sign > modules, remove private key, and embed the new public key in the > bzImage. Not if the buildsystem just made the key for them at 'make' time. I'm still missing why it isn't done until 'modules_install' time. Seems pretty sub-optimal. > I still think the signed_modules_install script, renamed to something > like ephemeral_signed_modules_install, is worthwhile and becomes a > convience tool for the developer, wanting to use ephemeral keys. The > private key, in Dmitry's updated patches soon to be posted, will be > password protected with a random number, that is only accessible to the > current shell. I think the existence of an additional make target for signed modules is really confusing. Particularly when you consider the target still exists even if the kernel isn't setup to work with signed modules. If the config options are set, just have 'make modules_install' do it and create a key if one doesn't exist (or better yet, have 'make' do it). Also... password protecting the key that only responds to the current shell really sounds like a show-stopper for this being used by distros. There is no way a distro is going to be able to type a password in during a kernel build. It completely removes the usability of distros that want to use a per-kernel build ephemeral key. If you're going to do this, please wrap it in a kconfig option so the second distro case I mentio above is still possible. josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
