On Thu, Aug 16, 2012 at 4:12 PM, Kasatkin, Dmitry <dmitry.kasat...@intel.com> wrote: >>> 1. signed_modules_install >>> This target creates an ephemeral key pair, signs the kernel modules with >>> the private key, destroys the private key, and embeds the public key in >>> the kernel. (Thanks to Dave Hansen for the target name.) >> >> This requires CONFIG_INTEGRITY_MODULES to be enabled to actually do >> anything useful with the signed modules, correct? >> > > Correct. It does not make sense to sign module if module support is disabled. > But there scripts/genkey.sh and ksign.sh which works without Makefiles. > So possible to generate keys and sign a module...
Right, but it won't actually do anything if the config option isn't set. Which means someone calling 'make signed_modules_install' won't actually get signed modules. That's confusing. >>> 2. modules_install >>> When CONFIG_INTEGRITY_MODULES is enabled, this target uses an existing >>> private key to sign kernel modules. >> >> If the answer to the above question is yes, then why can't we stick >> with a single modules_install command for signing? It would seem to me >> that calling signed_modules_install could use an existing key or >> generate an ephemeral key in the absence of one and install the signed >> modules, and modules_install would simply install unsigned modules. >> >> Or, alternatively, just make modules_install sign or not sign depending >> on whether CONFIG_INTEGRITY_MODULES is enabled. > > This is what "make modules_install" does. It uses existing private key > and does not remove it after install. Right. I should have been more clear. I was suggesting that "make modules_install" generate a key as well if one does not already exist. Essentially removing the necessity for sign_modules_install. >> I don't see why you >> would overload a target or create two different ones when both depend >> on that option. >> >> Could you explain the reasoning behind that a bit more? > > The reason for "signed_modules_install" is to limit existence of private key. > Private key is generate just before install, modules installed and > signed, then key is destroyed. > So existence of private key is limited to "time make > signed_modules_install" execution time. > > We had a debate about it, and strong message was that we might want to > do it like that... I guess I personally don't see the need to destroy they key so quickly. Is the concern that an intruder might grab the key and use it to sign a module that the developer would then later on somehow load? Or similarly someone would grab a temporary key from a distro build machine? That limits the attack surface, sure, but I'm not sure it's really reasonable. For a developer that isn't distributing kernels to others, it's just adding more time to the compile (which I know can be disabled, but still). For a distribution, most of them are either using a private key already or they have a buildsystem that destroys a buildroot after a build completes. The key is already going to be destroyed in that scenario. 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/
