[PATCH 1/2] Replace magic for trusting the secondary keyring with #define

From: Yannik Sembritzki <redacted>

Replace the use of a magic number that indicates that verify_*_signature()
should use the secondary keyring with a symbol.

Signed-off-by: Yannik Sembritzki <redacted>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: keyrings at vger.kernel.org
cc: linux-security-module at vger.kernel.org
---

 certs/system_keyring.c                  |    3 ++-
 crypto/asymmetric_keys/pkcs7_key_type.c |    2 +-
 include/linux/verification.h            |    6 ++++++
 3 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/certs/system_keyring.c b/certs/system_keyring.c
index 6251d1b27f0c..81728717523d 100644
--- a/certs/system_keyring.c
+++ b/certs/system_keyring.c

@@ -15,6 +15,7 @@
 #include <linux/cred.h>
 #include <linux/err.h>
 #include <linux/slab.h>
+#include <linux/verification.h>
 #include <keys/asymmetric-type.h>
 #include <keys/system_keyring.h>
 #include <crypto/pkcs7.h>

@@ -230,7 +231,7 @@ int verify_pkcs7_signature(const void *data, size_t len,
 
 	if (!trusted_keys) {
 		trusted_keys = builtin_trusted_keys;
-	} else if (trusted_keys == (void *)1UL) {
+	} else if (trusted_keys == VERIFY_USE_SECONDARY_KEYRING) {
 #ifdef CONFIG_SECONDARY_TRUSTED_KEYRING
 		trusted_keys = secondary_trusted_keys;
 #else

diff --git a/crypto/asymmetric_keys/pkcs7_key_type.c b/crypto/asymmetric_keys/pkcs7_key_type.c
index e284d9cb9237..5b2f6a2b5585 100644
--- a/crypto/asymmetric_keys/pkcs7_key_type.c
+++ b/crypto/asymmetric_keys/pkcs7_key_type.c

@@ -63,7 +63,7 @@ static int pkcs7_preparse(struct key_preparsed_payload *prep)
 
 	return verify_pkcs7_signature(NULL, 0,
 				      prep->data, prep->datalen,
-				      (void *)1UL, usage,
+				      VERIFY_USE_SECONDARY_KEYRING, usage,
 				      pkcs7_view_content, prep);
 }
 

diff --git a/include/linux/verification.h b/include/linux/verification.h
index a10549a6c7cd..cfa4730d607a 100644
--- a/include/linux/verification.h
+++ b/include/linux/verification.h

@@ -12,6 +12,12 @@
 #ifndef _LINUX_VERIFICATION_H
 #define _LINUX_VERIFICATION_H
 
+/*
+ * Indicate that both builtin trusted keys and secondary trusted keys
+ * should be used.
+ */
+#define VERIFY_USE_SECONDARY_KEYRING ((struct key *)1UL)
+
 /*
  * The use to which an asymmetric key is being put.
  */

From: Yannik Sembritzki <redacted>

The split of .system_keyring into .builtin_trusted_keys and
.secondary_trusted_keys broke kexec, thereby preventing kernels signed by
keys which are now in the secondary keyring from being kexec'd.

Fix this by passing VERIFY_USE_SECONDARY_KEYRING to
verify_pefile_signature().

Fixes: d3bfe84129f6 ("certs: Add a secondary system keyring that can be added to dynamically")
Signed-off-by: Yannik Sembritzki <redacted>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: kexec at lists.infradead.org
cc: keyrings at vger.kernel.org
cc: linux-security-module at vger.kernel.org
cc: stable at vger.kernel.org
---

 arch/x86/kernel/kexec-bzimage64.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c
index 7326078eaa7a..278cd07228dd 100644
--- a/arch/x86/kernel/kexec-bzimage64.c
+++ b/arch/x86/kernel/kexec-bzimage64.c

@@ -532,7 +532,7 @@ static int bzImage64_cleanup(void *loader_data)
 static int bzImage64_verify_sig(const char *kernel, unsigned long kernel_len)
 {
 	return verify_pefile_signature(kernel, kernel_len,
-				       NULL,
+				       VERIFY_USE_SECONDARY_KEYRING,
 				       VERIFYING_KEXEC_PE_SIGNATURE);
 }
 #endif

Hi Yannik,

I would suggest something like that.  I've switched the patches over as has
been suggested.  I think it makes more sense to create the constant first and
then use that.

I've also fleshed out the patch description a bit and added cc and Fixes
fields as appropriate.

David

On 16.08.2018 15:15, David Howells wrote:

I would suggest something like that.  I've switched the patches over as has
been suggested.  I think it makes more sense to create the constant first and
then use that.

I've also fleshed out the patch description a bit and added cc and Fixes
fields as appropriate.

Thanks, that looks good to me.
I see that you only cc'd stable@ in the (now) second patch. I'm curious,
will this automatically apply the first patch to stable?

Yannik

On Thu, Aug 16, 2018 at 03:17:47PM +0200, Yannik Sembritzki wrote:

On 16.08.2018 15:15, David Howells wrote:

quoted

I would suggest something like that.  I've switched the patches over as has
been suggested.  I think it makes more sense to create the constant first and
then use that.

I've also fleshed out the patch description a bit and added cc and Fixes
fields as appropriate.

Thanks, that looks good to me.
I see that you only cc'd stable@ in the (now) second patch. I'm curious,
will this automatically apply the first patch to stable?

No, but I'll try to remember to do it in order to get it right :)

thanks,

greg k-h