| Message ID | 1421976009-9819-1-git-send-email-holler@ahsoftware.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 2015-01-23 02:20, Alexander Holler wrote: > I usually throw away (delete) the key used to sign modules after having > called make -jN (b)zImage modules && make -jN modules_install. Because I've > got bored to always have to type rm signing_key.* afterwards, I've build > this patch some time ago. > As I'm not eager anymore to publish kernel patches, it rested in my private > chest of patches until I've seen the keynote of Linux.conf.au 2015. It made > me aware that this patch might have a chance to become included. ;) > > Signed-off-by: Alexander Holler <holler@ahsoftware.de> > --- > Makefile | 7 +++++++ > init/Kconfig | 12 ++++++++++++ > 2 files changed, 19 insertions(+) > > diff --git a/Makefile b/Makefile > index fb93350..95e07ca 100644 > --- a/Makefile > +++ b/Makefile > @@ -1129,6 +1129,13 @@ _modinst_: > @cp -f $(objtree)/modules.order $(MODLIB)/ > @cp -f $(objtree)/modules.builtin $(MODLIB)/ > $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modinst > +ifeq ($(CONFIG_MODULE_SIG_THROW_AWAY), y) > + @echo "###" > + @echo "### Deleting key used to sign modules." > + @echo "###" Use @$(kecho) "..." to suppress output with make -s > + @rm ./signing_key.priv > + @rm ./signing_key.x509 Why do you need to delete the certificate? Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am 23.01.2015 um 10:24 schrieb Michal Marek: >> + @rm ./signing_key.priv >> + @rm ./signing_key.x509 > > Why do you need to delete the certificate? No special reason. I'm just not sure (and too lazy to look it up) if it might contain the private key too (like it's possible in pem files), so I've deleted it too. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am 23.01.2015 um 10:39 schrieb Alexander Holler: > Am 23.01.2015 um 10:24 schrieb Michal Marek: > >>> + @rm ./signing_key.priv >>> + @rm ./signing_key.x509 >> >> Why do you need to delete the certificate? > > No special reason. > > I'm just not sure (and too lazy to look it up) if it might contain the > private key too (like it's possible in pem files), so I've deleted it too. Or in other words, while .priv leads me to the educated guess that it contains the private key, .x509 doesn't give me an obvious indication what it contains. If someone assures me that .x509 doesn't contain the private key necessary to sign the modules, I'll send a v2 of the patch. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2015-01-23 11:15, Alexander Holler wrote: > Am 23.01.2015 um 10:39 schrieb Alexander Holler: >> Am 23.01.2015 um 10:24 schrieb Michal Marek: >> >>>> + @rm ./signing_key.priv >>>> + @rm ./signing_key.x509 >>> >>> Why do you need to delete the certificate? >> >> No special reason. >> >> I'm just not sure (and too lazy to look it up) if it might contain the >> private key too (like it's possible in pem files), so I've deleted it too. > > Or in other words, while .priv leads me to the educated guess that it > contains the private key, .x509 doesn't give me an obvious indication > what it contains. > > If someone assures me that .x509 doesn't contain the private key > necessary to sign the modules, I'll send a v2 of the patch. The .x509 file contains a certificate signed by the private key, but not the private key. With some scripting, it can be used to verify the module signatures. Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am 23.01.2015 um 11:55 schrieb Michal Marek: > On 2015-01-23 11:15, Alexander Holler wrote: >> Am 23.01.2015 um 10:39 schrieb Alexander Holler: >>> Am 23.01.2015 um 10:24 schrieb Michal Marek: >>> >>>>> + @rm ./signing_key.priv >>>>> + @rm ./signing_key.x509 >>>> >>>> Why do you need to delete the certificate? >>> >>> No special reason. >>> >>> I'm just not sure (and too lazy to look it up) if it might contain the >>> private key too (like it's possible in pem files), so I've deleted it too. >> >> Or in other words, while .priv leads me to the educated guess that it >> contains the private key, .x509 doesn't give me an obvious indication >> what it contains. >> >> If someone assures me that .x509 doesn't contain the private key >> necessary to sign the modules, I'll send a v2 of the patch. > > The .x509 file contains a certificate signed by the private key, but not > the private key. With some scripting, it can be used to verify the > module signatures. Assuming that doesn't change (hopefully), I'll send v2 in a few minutes (it just compiles in order to test it). Thanks for assuring me that .x509 does not and will not contain the private key. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am 23.01.2015 um 12:43 schrieb Alexander Holler: > Am 23.01.2015 um 11:55 schrieb Michal Marek: >> The .x509 file contains a certificate signed by the private key, but not >> the private key. With some scripting, it can be used to verify the >> module signatures. > > > Assuming that doesn't change (hopefully), I'll send v2 in a few minutes > (it just compiles in order to test it). Thanks for assuring me that > .x509 does not and will not contain the private key. I'm happy I did that. Just deleting the private key currently doesn't work. A subsequent make fails: ----------------------------- (...) ### ### Deleting the private key used to sign modules. ### DEPMOD 3.18.3-00076-ga775cc9 [root@krabat linux]# less signing_key.x509 "signing_key.x509" may be a binary file. See it anyway? [root@krabat linux]# make -j4 bzImage modules && make -j4 modules_install CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CALL scripts/checksyscalls.sh CHK include/generated/compile.h X.509 certificate list changed CHK kernel/config_data.h CERTS kernel/x509_certificate_list - Including cert signing_key.x509 AS kernel/system_certificates.o LD kernel/built-in.o LINK vmlinux LD vmlinux.o MODPOST vmlinux.o GEN .version CHK include/generated/compile.h UPD include/generated/compile.h CC init/version.o LD init/built-in.o KSYM .tmp_kallsyms1.o KSYM .tmp_kallsyms2.o LD vmlinux SORTEX vmlinux SYSMAP System.map Building modules, stage 2. VOFFSET arch/x86/boot/voffset.h CC arch/x86/boot/version.o OBJCOPY arch/x86/boot/compressed/vmlinux.bin RELOCS arch/x86/boot/compressed/vmlinux.relocs CC arch/x86/boot/compressed/aslr.o LZMA arch/x86/boot/compressed/vmlinux.bin.lzma MODPOST 747 modules MKPIGGY arch/x86/boot/compressed/piggy.S AS arch/x86/boot/compressed/piggy.o LD arch/x86/boot/compressed/vmlinux OBJCOPY arch/x86/boot/vmlinux.bin ZOFFSET arch/x86/boot/zoffset.h AS arch/x86/boot/header.o LD arch/x86/boot/setup.elf OBJCOPY arch/x86/boot/setup.bin BUILD arch/x86/boot/bzImage Setup is 16316 bytes (padded to 16384 bytes). System is 3908 kB CRC a049b366 Kernel: arch/x86/boot/bzImage is ready (#682) INSTALL arch/x86/crypto/aes-x86_64.ko INSTALL arch/x86/crypto/blowfish-x86_64.ko INSTALL arch/x86/crypto/camellia-aesni-avx-x86_64.ko INSTALL arch/x86/crypto/aesni-intel.ko Can't read private key (...) ----------------------------- Maybe that's the reason I've always deleted both files, can't remember. I will see if I find the time and passion to change the Makefile in order to fix that. So you might either use my existing patch or wait if I will send a new one. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am 23.01.2015 um 12:54 schrieb Alexander Holler: > Am 23.01.2015 um 12:43 schrieb Alexander Holler: >> Am 23.01.2015 um 11:55 schrieb Michal Marek: > >>> The .x509 file contains a certificate signed by the private key, but not >>> the private key. With some scripting, it can be used to verify the >>> module signatures. >> >> >> Assuming that doesn't change (hopefully), I'll send v2 in a few minutes >> (it just compiles in order to test it). Thanks for assuring me that >> .x509 does not and will not contain the private key. > > I'm happy I did that. Just deleting the private key currently doesn't > work. A subsequent make fails: > > ----------------------------- > (...) > INSTALL arch/x86/crypto/aesni-intel.ko > Can't read private key > (...) > ----------------------------- > > Maybe that's the reason I've always deleted both files, can't remember. > > I will see if I find the time and passion to change the Makefile in > order to fix that. So you might either use my existing patch or wait if > I will send a new one. Having had a look at the Makefile, I don't think I will change that. The reasons are: 1. I have no idea about how distro maintainers do handle their private and public keys used to sign modules. 2. There might be legitimate reasons to build the kernel using only the public key and not regenerating it because the private key doesn't exist. 3. I don't see any real reason not to delete the public key too if this new option is enabled. For me it's enough if the kernel is able to verify the modules with the embedded public key. For other usage scenarios one just should not use the new option. 4. With some scripting it should be possible to extract the public key out of an existing binary kernel. So there is no real need to change the already complicated build process which might make it even more complicated. That means I'm still happy with the patch. So feel free to ignore or apply it. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Alexander Holler <holler@ahsoftware.de> wrote: > 1. I have no idea about how distro maintainers do handle their private and > public keys used to sign modules. In Fedora and RHEL, at least, we use a one-off on-the-fly generated transient key for each rpm build. When a kernel is built by rpmbuild, the source directory is generated afresh and a new key created each time. In the build farms, the kernel build tree is simply erased, private key and all, at the conclusion of the build. We make no effort to retain the transient private key as (1) it would require special handling for kernel builds to avoid leaking it, (2) it might impact non-buildfarm builds, and (3) it's more secure that no one has the private key. One thing that you have to be careful of with your patch is that if you turn it on during development, this will drain the entropy pool from which you get random numbers. David -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am 23.01.2015 um 13:56 schrieb David Howells: > One thing that you have to be careful of with your patch is that if you turn > it on during development, this will drain the entropy pool from which you get > random numbers. Hmm, I wonder how often people are compiling kernels and how much one turn drains the entropy pool. I would suggest to just get better in coding (and reviewing before compile testing) in order to not having to build kernels that often. Or just use a different config for development. ;) My primary use case is just what Linus described in his keynote. I'm building and signing all my kernels whenever a new stable kernel appears, throwing away the keys away immediately afterwards. And the patch avoids that I have to type the rm, and, even more usefull, it makes sure I don't forget to delete the keys, which would make signing the modules useless for me (as my kernel build directories (and thus the private keys) are usually residing on the machine the kernel is deployed afterwards). Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Sorry, either I type too fast or I think too slow, so here is another comment: Am 23.01.2015 um 14:27 schrieb Alexander Holler: > Am 23.01.2015 um 13:56 schrieb David Howells: > >> One thing that you have to be careful of with your patch is that if >> you turn >> it on during development, this will drain the entropy pool from which >> you get >> random numbers. > > Hmm, I wonder how often people are compiling kernels and how much one > turn drains the entropy pool. > > I would suggest to just get better in coding (and reviewing before > compile testing) in order to not having to build kernels that often. Or > just use a different config for development. ;) > > My primary use case is just what Linus described in his keynote. I'm > building and signing all my kernels whenever a new stable kernel > appears, throwing away the keys away immediately afterwards. > > And the patch avoids that I have to type the rm, and, even more usefull, > it makes sure I don't forget to delete the keys, which would make > signing the modules useless for me (as my kernel build directories (and > thus the private keys) are usually residing on the machine the kernel is > deployed afterwards). Besides that the keys are only deleted when modules_install is called. And that usually is only called if the kernels execution will be tested in real, which should offer enough time to fill the entropy pool. If the kernel and the modules are just build (and not installed), the keys will not be deleted. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am 23.01.2015 um 13:34 schrieb Alexander Holler: > 4. With some scripting it should be possible to extract the public key > out of an existing binary kernel. So there is no real need to change the > already complicated build process which might make it even more > complicated. BTW: With "more complicated" I meant that it isn't just done with making modules_install depend on the private key. That would end up with the following when the public key exist but the private key doesn't: - kernel is build including the public key - private key (and thus the public key) will be generated newly - modules will be installed using a key the kernel doesn't know about So the solution to just delete both keys looks for me still like the most easy and thus preferable way to implement that feature with just a few line of changes. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello, besides that calling rm on Linux is just snake oil, the patch below still automatically hides the key used to sign modules and offers a statistically good chance that the key sometimes might physically disappear from the storage used to compile a kernel. So many people still might consider it useful. As mentioned below, at least one well known person seems to might find it useful too. Should I rewrite the commit message (e.g. to nothing as the subject already describes it perfectly) or is the chance to get such stuff from someone outside the holy circles included already zero? Sorry for asking (that way), but I'm curious if there is really zero interest in it. Regards, Alexander Holler Am 23.01.2015 um 02:20 schrieb Alexander Holler: > I usually throw away (delete) the key used to sign modules after having > called make -jN (b)zImage modules && make -jN modules_install. Because I've > got bored to always have to type rm signing_key.* afterwards, I've build > this patch some time ago. > As I'm not eager anymore to publish kernel patches, it rested in my private > chest of patches until I've seen the keynote of Linux.conf.au 2015. It made > me aware that this patch might have a chance to become included. ;) > > Signed-off-by: Alexander Holler <holler@ahsoftware.de> > --- > Makefile | 7 +++++++ > init/Kconfig | 12 ++++++++++++ > 2 files changed, 19 insertions(+) > > diff --git a/Makefile b/Makefile > index fb93350..95e07ca 100644 > --- a/Makefile > +++ b/Makefile > @@ -1129,6 +1129,13 @@ _modinst_: > @cp -f $(objtree)/modules.order $(MODLIB)/ > @cp -f $(objtree)/modules.builtin $(MODLIB)/ > $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modinst > +ifeq ($(CONFIG_MODULE_SIG_THROW_AWAY), y) > + @echo "###" > + @echo "### Deleting key used to sign modules." > + @echo "###" > + @rm ./signing_key.priv > + @rm ./signing_key.x509 > +endif > > # This depmod is only for convenience to give the initial > # boot a modules.dep even before / is mounted read-write. However the > diff --git a/init/Kconfig b/init/Kconfig > index 9afb971..f29304e 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -1884,6 +1884,18 @@ config MODULE_SIG_ALL > Sign all modules during make modules_install. Without this option, > modules must be signed manually, using the scripts/sign-file tool. > > +config MODULE_SIG_THROW_AWAY > + bool "Automatically delete the key after modules were installed" > + default n > + depends on MODULE_SIG_ALL > + help > + Delete the key used to sign modules after modules were installed. > + Be aware of the consequences. The downside is that you won't be > + able to build any module for a (maybe running) kernel, but will > + have to rebuild the kernel and all modules in order to add or modify > + a module. The upside is that you don't have to secure the key in > + order to keep a running kernel safe from unwanted modules. > + > comment "Do not forget to sign required modules with scripts/sign-file" > depends on MODULE_SIG_FORCE && !MODULE_SIG_ALL > > -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Makefile b/Makefile index fb93350..95e07ca 100644 --- a/Makefile +++ b/Makefile @@ -1129,6 +1129,13 @@ _modinst_: @cp -f $(objtree)/modules.order $(MODLIB)/ @cp -f $(objtree)/modules.builtin $(MODLIB)/ $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modinst +ifeq ($(CONFIG_MODULE_SIG_THROW_AWAY), y) + @echo "###" + @echo "### Deleting key used to sign modules." + @echo "###" + @rm ./signing_key.priv + @rm ./signing_key.x509 +endif # This depmod is only for convenience to give the initial # boot a modules.dep even before / is mounted read-write. However the diff --git a/init/Kconfig b/init/Kconfig index 9afb971..f29304e 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -1884,6 +1884,18 @@ config MODULE_SIG_ALL Sign all modules during make modules_install. Without this option, modules must be signed manually, using the scripts/sign-file tool. +config MODULE_SIG_THROW_AWAY + bool "Automatically delete the key after modules were installed" + default n + depends on MODULE_SIG_ALL + help + Delete the key used to sign modules after modules were installed. + Be aware of the consequences. The downside is that you won't be + able to build any module for a (maybe running) kernel, but will + have to rebuild the kernel and all modules in order to add or modify + a module. The upside is that you don't have to secure the key in + order to keep a running kernel safe from unwanted modules. + comment "Do not forget to sign required modules with scripts/sign-file" depends on MODULE_SIG_FORCE && !MODULE_SIG_ALL
I usually throw away (delete) the key used to sign modules after having called make -jN (b)zImage modules && make -jN modules_install. Because I've got bored to always have to type rm signing_key.* afterwards, I've build this patch some time ago. As I'm not eager anymore to publish kernel patches, it rested in my private chest of patches until I've seen the keynote of Linux.conf.au 2015. It made me aware that this patch might have a chance to become included. ;) Signed-off-by: Alexander Holler <holler@ahsoftware.de> --- Makefile | 7 +++++++ init/Kconfig | 12 ++++++++++++ 2 files changed, 19 insertions(+)