[PATCH v7 00/17] Enroll kernel keys thru MOK

[PATCH v7 00/17] Enroll kernel keys thru MOK

[Eric Snowberg]

Back in 2013 Linus requested a feature to allow end-users to have the 
ability "to add their own keys and sign modules they trust". This was
his *second* order outlined here [1]. There have been many attempts 
over the years to solve this problem, all have been rejected.  Many 
of the failed attempts loaded all preboot firmware keys into the kernel,
including the Secure Boot keys. Many distributions carry one of these 
rejected attempts [2], [3], [4]. This series tries to solve this problem 
with a solution that takes into account all the problems brought up in 
the previous attempts.

On UEFI based systems, this series introduces a new Linux kernel keyring 
containing the Machine Owner Keys (MOK) called machine. It also defines
a new MOK variable in shim. This variable allows the end-user to decide 
if they want to load MOK keys into the machine keyring. Mimi has suggested 
that only CA keys contained within the MOK be loaded into the machine 
keyring. All other certs will load into the platform keyring instead.

By default, nothing changes; MOK keys are not loaded into the machine
keyring.  They are only loaded after the end-user makes the decision 
themselves.  The end-user would set this through mokutil using a new 
--trust-mok option [5]. This would work similar to how the kernel uses 
MOK variables to enable/disable signature validation as well as use/ignore 
the db. Any kernel operation that uses either the builtin or secondary 
trusted keys as a trust source shall also reference the new machine 
keyring as a trust source.

Secure Boot keys will never be loaded into the machine keyring.  They
will always be loaded into the platform keyring.  If an end-user wanted 
to load one, they would need to enroll it into the MOK.

Steps required by the end user:

Sign kernel module with user created key:
$ /usr/src/kernels/$(uname -r)/scripts/sign-file sha512 \
   machine_signing_key.priv machine_signing_key.x509 my_module.ko

Import the key into the MOK
$ mokutil --import machine_signing_key.x509

Setup the kernel to load MOK keys into the .machine keyring
$ mokutil --trust-mok

Then reboot, the MokManager will load and ask if you want to trust the
MOK key and enroll the MOK into the MOKList.  Afterwards the signed kernel
module will load.

I have included  a link to the mokutil [5] changes I have made to support 
this new functionality.  The shim changes have now been accepted
upstream [6].

[1] https://marc.info/?l=linux-kernel&m=136185386310140&w=2
[2] https://lore.kernel.org/lkml/1479737095.2487.34.camel@linux.vnet.ibm.com/
[3] https://lore.kernel.org/lkml/1556221605.24945.3.camel@HansenPartnership.com/
[4] https://lore.kernel.org/linux-integrity/1e41f22b1f11784f1e943f32bf62034d4e054cdb.camel@HansenPartnership.com/
[5] https://github.com/esnowberg/mokutil/tree/mokvars-v3
[6] https://github.com/rhboot/shim/commit/4e513405b4f1641710115780d19dcec130c5208f

Eric Snowberg (17):
  integrity: Introduce a Linux keyring called machine
  integrity: Do not allow machine keyring updates following init
  KEYS: Create static version of public_key_verify_signature
  X.509: Parse Basic Constraints for CA
  KEYS: CA link restriction
  integrity: restrict INTEGRITY_KEYRING_MACHINE to restrict_link_by_ca
  integrity: Fix warning about missing prototypes
  integrity: add new keyring handler for mok keys
  KEYS: Rename get_builtin_and_secondary_restriction
  KEYS: add a reference to machine keyring
  KEYS: Introduce link restriction for machine keys
  KEYS: integrity: change link restriction to trust the machine keyring
  KEYS: link secondary_trusted_keys to machine trusted keys
  integrity: store reference to machine keyring
  efi/mokvar: move up init order
  integrity: Trust MOK keys if MokListTrustedRT found
  integrity: Only use machine keyring when uefi_check_trust_mok_keys is
    true

 certs/system_keyring.c                        | 44 ++++++++++-
 crypto/asymmetric_keys/restrict.c             | 43 +++++++++++
 crypto/asymmetric_keys/x509_cert_parser.c     |  9 +++
 drivers/firmware/efi/mokvar-table.c           |  2 +-
 include/crypto/public_key.h                   | 15 ++++
 include/keys/system_keyring.h                 | 14 ++++
 security/integrity/Kconfig                    | 12 +++
 security/integrity/Makefile                   |  1 +
 security/integrity/digsig.c                   | 23 +++++-
 security/integrity/integrity.h                | 17 +++-
 .../platform_certs/keyring_handler.c          | 18 ++++-
 .../platform_certs/keyring_handler.h          |  5 ++
 security/integrity/platform_certs/load_uefi.c |  4 +-
 .../platform_certs/machine_keyring.c          | 77 +++++++++++++++++++
 14 files changed, 273 insertions(+), 11 deletions(-)
 create mode 100644 security/integrity/platform_certs/machine_keyring.c


base-commit: fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf
-- 
2.18.4

[PATCH v7 01/17] integrity: Introduce a Linux keyring called machine

[Eric Snowberg]

Many UEFI Linux distributions boot using shim.  The UEFI shim provides
what is called Machine Owner Keys (MOK). Shim uses both the UEFI Secure
Boot DB and MOK keys to validate the next step in the boot chain.  The
MOK facility can be used to import user generated keys.  These keys can
be used to sign an end-users development kernel build.  When Linux
boots, both UEFI Secure Boot DB and MOK keys get loaded in the Linux
.platform keyring.

Define a new Linux keyring called machine.  This keyring shall contain just
MOK CA keys and not the remaining keys in the platform keyring. This new
machine keyring will be used in follow on patches.  Unlike keys in the
platform keyring, keys contained in the machine keyring will be trusted
within the kernel if the end-user has chosen to do so.

Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
v1: Initial version
v2: Removed destory keyring code
v3: Unmodified from v2
v4: Add Kconfig, merged in "integrity: add add_to_mok_keyring" 
v5: Rename to machine keyring
v6: Depend on EFI in kconfig  (suggested by Mimi)
    Test to see if ".platform" keyring is configured in
      add_to_machine_keyring (suggested by Mimi)
v7: Depend on LOAD_UEFI_KEYS instead EFI for mokvar code
---
 security/integrity/Kconfig                    | 12 ++++++
 security/integrity/Makefile                   |  1 +
 security/integrity/digsig.c                   |  1 +
 security/integrity/integrity.h                | 12 +++++-
 .../platform_certs/machine_keyring.c          | 42 +++++++++++++++++++
 5 files changed, 67 insertions(+), 1 deletion(-)
 create mode 100644 security/integrity/platform_certs/machine_keyring.c

diff --git a/security/integrity/Kconfig b/security/integrity/Kconfig
index 71f0177e8716..12879dec251d 100644
--- a/security/integrity/Kconfig
+++ b/security/integrity/Kconfig
@@ -62,6 +62,18 @@ config INTEGRITY_PLATFORM_KEYRING
          provided by the platform for verifying the kexec'ed kerned image
          and, possibly, the initramfs signature.
 
+config INTEGRITY_MACHINE_KEYRING
+	bool "Provide a keyring to which CA Machine Owner Keys may be added"
+	depends on SECONDARY_TRUSTED_KEYRING
+	depends on INTEGRITY_ASYMMETRIC_KEYS
+	depends on SYSTEM_BLACKLIST_KEYRING
+	depends on LOAD_UEFI_KEYS
+	help
+	 If set, provide a keyring to which CA Machine Owner Keys (MOK) may
+	 be added. This keyring shall contain just CA MOK keys.  Unlike keys
+	 in the platform keyring, keys contained in the .machine keyring will
+	 be trusted within the kernel.
+
 config LOAD_UEFI_KEYS
        depends on INTEGRITY_PLATFORM_KEYRING
        depends on EFI
diff --git a/security/integrity/Makefile b/security/integrity/Makefile
index 7ee39d66cf16..d0ffe37dc1d6 100644
--- a/security/integrity/Makefile
+++ b/security/integrity/Makefile
@@ -10,6 +10,7 @@ integrity-$(CONFIG_INTEGRITY_AUDIT) += integrity_audit.o
 integrity-$(CONFIG_INTEGRITY_SIGNATURE) += digsig.o
 integrity-$(CONFIG_INTEGRITY_ASYMMETRIC_KEYS) += digsig_asymmetric.o
 integrity-$(CONFIG_INTEGRITY_PLATFORM_KEYRING) += platform_certs/platform_keyring.o
+integrity-$(CONFIG_INTEGRITY_MACHINE_KEYRING) += platform_certs/machine_keyring.o
 integrity-$(CONFIG_LOAD_UEFI_KEYS) += platform_certs/efi_parser.o \
 				      platform_certs/load_uefi.o \
 				      platform_certs/keyring_handler.o
diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
index 3b06a01bd0fd..8c315be8ad99 100644
--- a/security/integrity/digsig.c
+++ b/security/integrity/digsig.c
@@ -30,6 +30,7 @@ static const char * const keyring_name[INTEGRITY_KEYRING_MAX] = {
 	".ima",
 #endif
 	".platform",
+	".machine",
 };
 
 #ifdef CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY
diff --git a/security/integrity/integrity.h b/security/integrity/integrity.h
index 547425c20e11..730771eececd 100644
--- a/security/integrity/integrity.h
+++ b/security/integrity/integrity.h
@@ -151,7 +151,8 @@ int integrity_kernel_read(struct file *file, loff_t offset,
 #define INTEGRITY_KEYRING_EVM		0
 #define INTEGRITY_KEYRING_IMA		1
 #define INTEGRITY_KEYRING_PLATFORM	2
-#define INTEGRITY_KEYRING_MAX		3
+#define INTEGRITY_KEYRING_MACHINE	3
+#define INTEGRITY_KEYRING_MAX		4
 
 extern struct dentry *integrity_dir;
 
@@ -283,3 +284,12 @@ static inline void __init add_to_platform_keyring(const char *source,
 {
 }
 #endif
+
+#ifdef CONFIG_INTEGRITY_MACHINE_KEYRING
+void __init add_to_machine_keyring(const char *source, const void *data, size_t len);
+#else
+static inline void __init add_to_machine_keyring(const char *source,
+						  const void *data, size_t len)
+{
+}
+#endif
diff --git a/security/integrity/platform_certs/machine_keyring.c b/security/integrity/platform_certs/machine_keyring.c
new file mode 100644
index 000000000000..ea2ac2f9f2b5
--- /dev/null
+++ b/security/integrity/platform_certs/machine_keyring.c
@@ -0,0 +1,42 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Machine keyring routines.
+ *
+ * Copyright (c) 2021, Oracle and/or its affiliates.
+ */
+
+#include "../integrity.h"
+
+static __init int machine_keyring_init(void)
+{
+	int rc;
+
+	rc = integrity_init_keyring(INTEGRITY_KEYRING_MACHINE);
+	if (rc)
+		return rc;
+
+	pr_notice("Machine keyring initialized\n");
+	return 0;
+}
+device_initcall(machine_keyring_init);
+
+void __init add_to_machine_keyring(const char *source, const void *data, size_t len)
+{
+	key_perm_t perm;
+	int rc;
+
+	perm = (KEY_POS_ALL & ~KEY_POS_SETATTR) | KEY_USR_VIEW;
+	rc = integrity_load_cert(INTEGRITY_KEYRING_MACHINE, source, data, len, perm);
+
+	/*
+	 * Some MOKList keys may not pass the machine keyring restrictions.
+	 * If the restriction check does not pass and the platform keyring
+	 * is configured, try to add it into that keyring instead.
+	 */
+	if (rc && IS_ENABLED(CONFIG_INTEGRITY_PLATFORM_KEYRING))
+		rc = integrity_load_cert(INTEGRITY_KEYRING_PLATFORM, source,
+					 data, len, perm);
+
+	if (rc)
+		pr_info("Error adding keys to machine keyring %s\n", source);
+}
-- 
2.18.4

Re: [PATCH v7 01/17] integrity: Introduce a Linux keyring called machine

[Mimi Zohar]

Hi Eric,

On Mon, 2021-11-15 at 19:15 -0500, Eric Snowberg wrote:
> Many UEFI Linux distributions boot using shim.  The UEFI shim provides
> what is called Machine Owner Keys (MOK). Shim uses both the UEFI Secure
> Boot DB and MOK keys to validate the next step in the boot chain.  The
> MOK facility can be used to import user generated keys.  These keys can
> be used to sign an end-users development kernel build.  When Linux
> boots, both UEFI Secure Boot DB and MOK keys get loaded in the Linux
> .platform keyring.

, which can be used to verify kexec'ed kernel images.

> Define a new Linux keyring called machine.  This keyring shall contain just
> MOK CA keys and not the remaining keys in the platform keyring. This new
> machine keyring will be used in follow on patches.  Unlike keys in the
> platform keyring, keys contained in the machine keyring will be trusted
> within the kernel if the end-user has chosen to do so.

 allowing, for example, keys to be loaded onto the trusted IMA keyring.

> 
> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>

Thank you for all the work!  Just letting you know I'm slowly making my
through the patch set.  With the previous patch re-organization, we
should be able to test everything up to the introduction of the MOK
variable support.

Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>

[PATCH v7 02/17] integrity: Do not allow machine keyring updates following init

[Eric Snowberg]

The machine keyring is setup during init.  No additional keys should be
allowed to be added afterwards.  Leave the permission as read only.

Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
v2: Initial version
v4: Unmodified from v2
v5: Rename to machine keyring
v6: Add additional comment (suggested by Jarkko)
v7: Unmodified from v6
---
 security/integrity/digsig.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
index 8c315be8ad99..910fe29a5037 100644
--- a/security/integrity/digsig.c
+++ b/security/integrity/digsig.c
@@ -140,7 +140,13 @@ int __init integrity_init_keyring(const unsigned int id)
 		return -ENOMEM;
 
 	restriction->check = restrict_link_to_ima;
-	perm |= KEY_USR_WRITE;
+
+	/*
+	 * No additional keys shall be allowed to load into the machine
+	 * keyring following init
+	 */
+	if (id != INTEGRITY_KEYRING_MACHINE)
+		perm |= KEY_USR_WRITE;
 
 out:
 	return __integrity_init_keyring(id, perm, restriction);
-- 
2.18.4

Re: [PATCH v7 02/17] integrity: Do not allow machine keyring updates following init

[Mimi Zohar]

On Mon, 2021-11-15 at 19:15 -0500, Eric Snowberg wrote:
> The machine keyring is setup during init.  No additional keys should be
> allowed to be added afterwards.  Leave the permission as read only.
> 
> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>

Reviewed-by:  Mimi Zohar <zohar@linux.ibm.com>

[PATCH v7 03/17] KEYS: Create static version of public_key_verify_signature

[Eric Snowberg]

The kernel test robot reports undefined reference to
public_key_verify_signature when CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE is
not defined. Create a static version in this case and return -EINVAL.

Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
v7: Initial version
---
 include/crypto/public_key.h | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/include/crypto/public_key.h b/include/crypto/public_key.h
index f603325c0c30..a9b2e600b7cc 100644
--- a/include/crypto/public_key.h
+++ b/include/crypto/public_key.h
@@ -80,7 +80,16 @@ extern int create_signature(struct kernel_pkey_params *, const void *, void *);
 extern int verify_signature(const struct key *,
 			    const struct public_key_signature *);
 
+#if IS_REACHABLE(CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE)
 int public_key_verify_signature(const struct public_key *pkey,
 				const struct public_key_signature *sig);
+#else
+static inline
+int public_key_verify_signature(const struct public_key *pkey,
+				const struct public_key_signature *sig)
+{
+	return -EINVAL;
+}
+#endif
 
 #endif /* _LINUX_PUBLIC_KEY_H */
-- 
2.18.4

Re: [PATCH v7 03/17] KEYS: Create static version of public_key_verify_signature

[Mimi Zohar]

On Mon, 2021-11-15 at 19:15 -0500, Eric Snowberg wrote:
> The kernel test robot reports undefined reference to
> public_key_verify_signature when CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE is
> not defined. Create a static version in this case and return -EINVAL.
> 
> Reported-by: kernel test robot <lkp@intel.com>
> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>

Reviewed-by:  Mimi Zohar <zohar@linux.ibm.com>

Re: [PATCH v7 03/17] KEYS: Create static version of public_key_verify_signature

[Mimi Zohar]

On Wed, 2021-11-17 at 08:32 -0500, Mimi Zohar wrote:
> On Mon, 2021-11-15 at 19:15 -0500, Eric Snowberg wrote:
> > The kernel test robot reports undefined reference to
> > public_key_verify_signature when CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE is
> > not defined. Create a static version in this case and return -EINVAL.
> > 
> > Reported-by: kernel test robot <lkp@intel.com>
> > Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
> 
> Reviewed-by:  Mimi Zohar <zohar@linux.ibm.com>

Perhaps this patch wouldn't be needed if 

+config INTEGRITY_MACHINE_KEYRING
+       bool "Provide a keyring to which CA Machine Owner Keys may be
added"
+       depends on SECONDARY_TRUSTED_KEYRING
+       depends on INTEGRITY_ASYMMETRIC_KEYS

depends on ASYMMETRIC_PUBLIC_KEY_SUBTYPE=y

+       depends on SYSTEM_BLACKLIST_KEYRING
+       depends on LOAD_UEFI_KEYS

Mimi

[PATCH v7 04/17] X.509: Parse Basic Constraints for CA

[Eric Snowberg]

Parse the X.509 Basic Constraints.  The basic constraints extension
identifies whether the subject of the certificate is a CA.

BasicConstraints ::= SEQUENCE {
        cA                      BOOLEAN DEFAULT FALSE,
        pathLenConstraint       INTEGER (0..MAX) OPTIONAL }

If the CA is true, store it in a new public_key field call key_is_ca.
This will be used in a follow on patch that requires knowing if the
public key is a CA.

Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
v7: Initial version
---
 crypto/asymmetric_keys/x509_cert_parser.c | 9 +++++++++
 include/crypto/public_key.h               | 1 +
 2 files changed, 10 insertions(+)

diff --git a/crypto/asymmetric_keys/x509_cert_parser.c b/crypto/asymmetric_keys/x509_cert_parser.c
index 6d003096b5bc..f4299b8a4926 100644
--- a/crypto/asymmetric_keys/x509_cert_parser.c
+++ b/crypto/asymmetric_keys/x509_cert_parser.c
@@ -571,6 +571,15 @@ int x509_process_extension(void *context, size_t hdrlen,
 		return 0;
 	}
 
+	if (ctx->last_oid == OID_basicConstraints) {
+		if (v[0] != (ASN1_CONS_BIT | ASN1_SEQ))
+			return -EBADMSG;
+		if (v[1] != vlen - 2)
+			return -EBADMSG;
+		if (v[1] != 0 && v[2] == ASN1_BOOL && v[3] == 1)
+			ctx->cert->pub->key_is_ca = true;
+	}
+
 	return 0;
 }
 
diff --git a/include/crypto/public_key.h b/include/crypto/public_key.h
index a9b2e600b7cc..61c66be80995 100644
--- a/include/crypto/public_key.h
+++ b/include/crypto/public_key.h
@@ -28,6 +28,7 @@ struct public_key {
 	bool key_is_private;
 	const char *id_type;
 	const char *pkey_algo;
+	bool key_is_ca;
 };
 
 extern void public_key_free(struct public_key *key);
-- 
2.18.4

Re: [PATCH v7 04/17] X.509: Parse Basic Constraints for CA

[Mimi Zohar]

Hi Eric,

On Mon, 2021-11-15 at 19:15 -0500, Eric Snowberg wrote:
> Parse the X.509 Basic Constraints.  The basic constraints extension
> identifies whether the subject of the certificate is a CA.
> 
> BasicConstraints ::= SEQUENCE {
>         cA                      BOOLEAN DEFAULT FALSE,
>         pathLenConstraint       INTEGER (0..MAX) OPTIONAL }
> 
> If the CA is true, store it in a new public_key field call key_is_ca.
> This will be used in a follow on patch that requires knowing if the
> public key is a CA.
> 
> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
> ---
> v7: Initial version
> ---
>  crypto/asymmetric_keys/x509_cert_parser.c | 9 +++++++++
>  include/crypto/public_key.h               | 1 +
>  2 files changed, 10 insertions(+)
> 
> diff --git a/crypto/asymmetric_keys/x509_cert_parser.c b/crypto/asymmetric_keys/x509_cert_parser.c
> index 6d003096b5bc..f4299b8a4926 100644
> --- a/crypto/asymmetric_keys/x509_cert_parser.c
> +++ b/crypto/asymmetric_keys/x509_cert_parser.c
> @@ -571,6 +571,15 @@ int x509_process_extension(void *context, size_t hdrlen,
>  		return 0;
>  	}
>  
> +	if (ctx->last_oid == OID_basicConstraints) {
> +		if (v[0] != (ASN1_CONS_BIT | ASN1_SEQ))
> +			return -EBADMSG;
> +		if (v[1] != vlen - 2)
> +			return -EBADMSG;
> +		if (v[1] != 0 && v[2] == ASN1_BOOL && v[3] == 1)
> +			ctx->cert->pub->key_is_ca = true;
> +	}
> +
>  	return 0;
>  }
>  
> diff --git a/include/crypto/public_key.h b/include/crypto/public_key.h
> index a9b2e600b7cc..61c66be80995 100644
> --- a/include/crypto/public_key.h
> +++ b/include/crypto/public_key.h
> @@ -28,6 +28,7 @@ struct public_key {
>  	bool key_is_private;
>  	const char *id_type;
>  	const char *pkey_algo;
> +	bool key_is_ca;

David added "key_is_private" intentionally where he did.  Adding the
"key_is_ca" immediately afterwards doesn't change the struct size.

Mimi

>  };
>  
>  extern void public_key_free(struct public_key *key);

Re: [PATCH v7 04/17] X.509: Parse Basic Constraints for CA

[Eric Snowberg]

> On Nov 18, 2021, at 3:59 PM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> 
> Hi Eric,
> 
> On Mon, 2021-11-15 at 19:15 -0500, Eric Snowberg wrote:
>> Parse the X.509 Basic Constraints.  The basic constraints extension
>> identifies whether the subject of the certificate is a CA.
>> 
>> BasicConstraints ::= SEQUENCE {
>>        cA                      BOOLEAN DEFAULT FALSE,
>>        pathLenConstraint       INTEGER (0..MAX) OPTIONAL }
>> 
>> If the CA is true, store it in a new public_key field call key_is_ca.
>> This will be used in a follow on patch that requires knowing if the
>> public key is a CA.
>> 
>> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
>> ---
>> v7: Initial version
>> ---
>> crypto/asymmetric_keys/x509_cert_parser.c | 9 +++++++++
>> include/crypto/public_key.h               | 1 +
>> 2 files changed, 10 insertions(+)
>> 
>> diff --git a/crypto/asymmetric_keys/x509_cert_parser.c b/crypto/asymmetric_keys/x509_cert_parser.c
>> index 6d003096b5bc..f4299b8a4926 100644
>> --- a/crypto/asymmetric_keys/x509_cert_parser.c
>> +++ b/crypto/asymmetric_keys/x509_cert_parser.c
>> @@ -571,6 +571,15 @@ int x509_process_extension(void *context, size_t hdrlen,
>> 		return 0;
>> 	}
>> 
>> +	if (ctx->last_oid == OID_basicConstraints) {
>> +		if (v[0] != (ASN1_CONS_BIT | ASN1_SEQ))
>> +			return -EBADMSG;
>> +		if (v[1] != vlen - 2)
>> +			return -EBADMSG;
>> +		if (v[1] != 0 && v[2] == ASN1_BOOL && v[3] == 1)
>> +			ctx->cert->pub->key_is_ca = true;
>> +	}
>> +
>> 	return 0;
>> }
>> 
>> diff --git a/include/crypto/public_key.h b/include/crypto/public_key.h
>> index a9b2e600b7cc..61c66be80995 100644
>> --- a/include/crypto/public_key.h
>> +++ b/include/crypto/public_key.h
>> @@ -28,6 +28,7 @@ struct public_key {
>> 	bool key_is_private;
>> 	const char *id_type;
>> 	const char *pkey_algo;
>> +	bool key_is_ca;
> 
> David added "key_is_private" intentionally where he did.  Adding the
> "key_is_ca" immediately afterwards doesn't change the struct size.

Ok, I’ll change that in the next round.  Thanks.

[PATCH v7 05/17] KEYS: CA link restriction

[Eric Snowberg]

Add a new link restriction.  Restrict the addition of keys in a keyring
based on the key to be added being a CA.

Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
v1: Initial version
v2: Removed secondary keyring references
v3: Removed restrict_link_by_system_trusted_or_ca
    Simplify restrict_link_by_ca - only see if the key is a CA
    Did not add __init in front of restrict_link_by_ca in case
      restriction could be resued in the future
v6: Unmodified from v3
v7: Check for CA restruction in public key
---
 crypto/asymmetric_keys/restrict.c | 43 +++++++++++++++++++++++++++++++
 include/crypto/public_key.h       |  5 ++++
 2 files changed, 48 insertions(+)

diff --git a/crypto/asymmetric_keys/restrict.c b/crypto/asymmetric_keys/restrict.c
index 84cefe3b3585..a891c598a2aa 100644
--- a/crypto/asymmetric_keys/restrict.c
+++ b/crypto/asymmetric_keys/restrict.c
@@ -108,6 +108,49 @@ int restrict_link_by_signature(struct key *dest_keyring,
 	return ret;
 }
 
+/**
+ * restrict_link_by_ca - Restrict additions to a ring of CA keys
+ * @dest_keyring: Keyring being linked to.
+ * @type: The type of key being added.
+ * @payload: The payload of the new key.
+ * @trust_keyring: Unused.
+ *
+ * Check if the new certificate is a CA. If it is a CA, then mark the new
+ * certificate as being ok to link.
+ *
+ * Returns 0 if the new certificate was accepted, -ENOKEY if the
+ * certificate is not a CA. -ENOPKG if the signature uses unsupported
+ * crypto, or some other error if there is a matching certificate but
+ * the signature check cannot be performed.
+ */
+int restrict_link_by_ca(struct key *dest_keyring,
+			const struct key_type *type,
+			const union key_payload *payload,
+			struct key *trust_keyring)
+{
+	const struct public_key_signature *sig;
+	const struct public_key *pkey;
+
+	if (type != &key_type_asymmetric)
+		return -EOPNOTSUPP;
+
+	sig = payload->data[asym_auth];
+	if (!sig)
+		return -ENOPKG;
+
+	if (!sig->auth_ids[0] && !sig->auth_ids[1])
+		return -ENOKEY;
+
+	pkey = payload->data[asym_crypto];
+	if (!pkey)
+		return -ENOPKG;
+
+	if (!pkey->key_is_ca)
+		return -ENOKEY;
+
+	return public_key_verify_signature(pkey, sig);
+}
+
 static bool match_either_id(const struct asymmetric_key_ids *pair,
 			    const struct asymmetric_key_id *single)
 {
diff --git a/include/crypto/public_key.h b/include/crypto/public_key.h
index 61c66be80995..1e4fff6b7820 100644
--- a/include/crypto/public_key.h
+++ b/include/crypto/public_key.h
@@ -72,6 +72,11 @@ extern int restrict_link_by_key_or_keyring_chain(struct key *trust_keyring,
 						 const union key_payload *payload,
 						 struct key *trusted);
 
+extern int restrict_link_by_ca(struct key *dest_keyring,
+			       const struct key_type *type,
+			       const union key_payload *payload,
+			       struct key *trust_keyring);
+
 extern int query_asymmetric_key(const struct kernel_pkey_params *,
 				struct kernel_pkey_query *);
 
-- 
2.18.4

[PATCH v7 06/17] integrity: restrict INTEGRITY_KEYRING_MACHINE to restrict_link_by_ca

[Eric Snowberg]

Set the restriction check for INTEGRITY_KEYRING_MACHINE keys to
restrict_link_by_ca.  This will only allow CA keys into the machine
keyring.

Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
v1: Initial version
v2: Added !IS_ENABLED(CONFIG_INTEGRITY_TRUSTED_KEYRING check so mok
    keyring gets created even when it isn't enabled
v3: Rename restrict_link_by_system_trusted_or_ca to restrict_link_by_ca
v4: removed unnecessary restriction->check set
v5: Rename to machine keyring
v6: split line over 80 char (suggested by Mimi)
v7: Unmodified from v6
---
 security/integrity/digsig.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
index 910fe29a5037..e7dfc55a7c55 100644
--- a/security/integrity/digsig.c
+++ b/security/integrity/digsig.c
@@ -132,14 +132,18 @@ int __init integrity_init_keyring(const unsigned int id)
 		goto out;
 	}
 
-	if (!IS_ENABLED(CONFIG_INTEGRITY_TRUSTED_KEYRING))
+	if (!IS_ENABLED(CONFIG_INTEGRITY_TRUSTED_KEYRING) &&
+	    id != INTEGRITY_KEYRING_MACHINE)
 		return 0;
 
 	restriction = kzalloc(sizeof(struct key_restriction), GFP_KERNEL);
 	if (!restriction)
 		return -ENOMEM;
 
-	restriction->check = restrict_link_to_ima;
+	if (id == INTEGRITY_KEYRING_MACHINE)
+		restriction->check = restrict_link_by_ca;
+	else
+		restriction->check = restrict_link_to_ima;
 
 	/*
 	 * No additional keys shall be allowed to load into the machine
-- 
2.18.4

Re: [PATCH v7 06/17] integrity: restrict INTEGRITY_KEYRING_MACHINE to restrict_link_by_ca

[kernel test robot]

[-- Attachment #1: Type: text/plain, Size: 1604 bytes --]

Hi Eric,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf]

url:    https://github.com/0day-ci/linux/commits/Eric-Snowberg/Enroll-kernel-keys-thru-MOK/20211116-082323
base:   fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf
config: arm-randconfig-c002-20211118 (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/37da84e92e00618ed2df4af65f5c07b16d6a04c0
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Eric-Snowberg/Enroll-kernel-keys-thru-MOK/20211116-082323
        git checkout 37da84e92e00618ed2df4af65f5c07b16d6a04c0
        # save the attached .config to linux build tree
        mkdir build_dir
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=arm SHELL=/bin/bash

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

   arm-linux-gnueabi-ld: security/integrity/digsig.o: in function `integrity_init_keyring':
>> digsig.c:(.init.text+0xdc): undefined reference to `restrict_link_by_ca'
>> arm-linux-gnueabi-ld: digsig.c:(.init.text+0xe0): undefined reference to `restrict_link_by_ca'

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 31649 bytes --]

Re: [PATCH v7 06/17] integrity: restrict INTEGRITY_KEYRING_MACHINE to restrict_link_by_ca

[kernel test robot]

[-- Attachment #1: Type: text/plain, Size: 1639 bytes --]

Hi Eric,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf]

url:    https://github.com/0day-ci/linux/commits/Eric-Snowberg/Enroll-kernel-keys-thru-MOK/20211116-082323
base:   fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf
config: arm-randconfig-c002-20211118 (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/37da84e92e00618ed2df4af65f5c07b16d6a04c0
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Eric-Snowberg/Enroll-kernel-keys-thru-MOK/20211116-082323
        git checkout 37da84e92e00618ed2df4af65f5c07b16d6a04c0
        # save the attached .config to linux build tree
        mkdir build_dir
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=arm SHELL=/bin/bash

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

   arm-linux-gnueabi-ld: security/integrity/digsig.o: in function `integrity_init_keyring':
>> digsig.c:(.init.text+0xdc): undefined reference to `restrict_link_by_ca'
>> arm-linux-gnueabi-ld: digsig.c:(.init.text+0xe0): undefined reference to `restrict_link_by_ca'

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 31649 bytes --]

[PATCH v7 07/17] integrity: Fix warning about missing prototypes

[Eric Snowberg]

make W=1 generates the following warning in keyring_handler.c

security/integrity/platform_certs/keyring_handler.c:71:30: warning: no previous prototype for get_handler_for_db [-Wmissing-prototypes]
 __init efi_element_handler_t get_handler_for_db(const efi_guid_t *sig_type)
                              ^~~~~~~~~~~~~~~~~~
security/integrity/platform_certs/keyring_handler.c:82:30: warning: no previous prototype for get_handler_for_dbx [-Wmissing-prototypes]
 __init efi_element_handler_t get_handler_for_dbx(const efi_guid_t *sig_type)
                              ^~~~~~~~~~~~~~~~~~~
Add the missing prototypes by including keyring_handler.h.

Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
v7: Initial version
---
 security/integrity/platform_certs/keyring_handler.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/security/integrity/platform_certs/keyring_handler.c b/security/integrity/platform_certs/keyring_handler.c
index 5604bd57c990..e9791be98fd9 100644
--- a/security/integrity/platform_certs/keyring_handler.c
+++ b/security/integrity/platform_certs/keyring_handler.c
@@ -9,6 +9,7 @@
 #include <keys/asymmetric-type.h>
 #include <keys/system_keyring.h>
 #include "../integrity.h"
+#include "keyring_handler.h"
 
 static efi_guid_t efi_cert_x509_guid __initdata = EFI_CERT_X509_GUID;
 static efi_guid_t efi_cert_x509_sha256_guid __initdata =
-- 
2.18.4

Re: [PATCH v7 07/17] integrity: Fix warning about missing prototypes

[Mimi Zohar]

Hi Eric,

On Mon, 2021-11-15 at 19:15 -0500, Eric Snowberg wrote:
> make W=1 generates the following warning in keyring_handler.c
> 
> security/integrity/platform_certs/keyring_handler.c:71:30: warning: no previous prototype for get_handler_for_db [-Wmissing-prototypes]
>  __init efi_element_handler_t get_handler_for_db(const efi_guid_t *sig_type)
>                               ^~~~~~~~~~~~~~~~~~
> security/integrity/platform_certs/keyring_handler.c:82:30: warning: no previous prototype for get_handler_for_dbx [-Wmissing-prototypes]
>  __init efi_element_handler_t get_handler_for_dbx(const efi_guid_t *sig_type)
>                               ^~~~~~~~~~~~~~~~~~~
> Add the missing prototypes by including keyring_handler.h.
> 
> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>

These sorts of fixes, which aren't really dependent on the patch set,
could be moved to the begining of the patch set.

Reviewed-by:  Mimi Zohar <zohar@linux.ibm.com>

[PATCH v7 08/17] integrity: add new keyring handler for mok keys

[Eric Snowberg]

Currently both Secure Boot DB and Machine Owner Keys (MOK) go through
the same keyring handler (get_handler_for_db). With the addition of the
new machine keyring, the end-user may choose to trust MOK keys.

Introduce a new keyring handler specific for MOK keys.  If MOK keys are
trusted by the end-user, use the new keyring handler instead.

Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
v1: Initial version
v3: Only change the keyring handler if the secondary is enabled
v4: Removed trust_moklist check
v5: Rename to machine keyring
v7: Unmodified from v5
---
 .../integrity/platform_certs/keyring_handler.c  | 17 ++++++++++++++++-
 .../integrity/platform_certs/keyring_handler.h  |  5 +++++
 security/integrity/platform_certs/load_uefi.c   |  4 ++--
 3 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/security/integrity/platform_certs/keyring_handler.c b/security/integrity/platform_certs/keyring_handler.c
index e9791be98fd9..4872850d081f 100644
--- a/security/integrity/platform_certs/keyring_handler.c
+++ b/security/integrity/platform_certs/keyring_handler.c
@@ -67,7 +67,7 @@ static __init void uefi_revocation_list_x509(const char *source,
 
 /*
  * Return the appropriate handler for particular signature list types found in
- * the UEFI db and MokListRT tables.
+ * the UEFI db tables.
  */
 __init efi_element_handler_t get_handler_for_db(const efi_guid_t *sig_type)
 {
@@ -76,6 +76,21 @@ __init efi_element_handler_t get_handler_for_db(const efi_guid_t *sig_type)
 	return 0;
 }
 
+/*
+ * Return the appropriate handler for particular signature list types found in
+ * the MokListRT tables.
+ */
+__init efi_element_handler_t get_handler_for_mok(const efi_guid_t *sig_type)
+{
+	if (efi_guidcmp(*sig_type, efi_cert_x509_guid) == 0) {
+		if (IS_ENABLED(CONFIG_INTEGRITY_MACHINE_KEYRING))
+			return add_to_machine_keyring;
+		else
+			return add_to_platform_keyring;
+	}
+	return 0;
+}
+
 /*
  * Return the appropriate handler for particular signature list types found in
  * the UEFI dbx and MokListXRT tables.
diff --git a/security/integrity/platform_certs/keyring_handler.h b/security/integrity/platform_certs/keyring_handler.h
index 2462bfa08fe3..284558f30411 100644
--- a/security/integrity/platform_certs/keyring_handler.h
+++ b/security/integrity/platform_certs/keyring_handler.h
@@ -24,6 +24,11 @@ void blacklist_binary(const char *source, const void *data, size_t len);
  */
 efi_element_handler_t get_handler_for_db(const efi_guid_t *sig_type);
 
+/*
+ * Return the handler for particular signature list types found in the mok.
+ */
+efi_element_handler_t get_handler_for_mok(const efi_guid_t *sig_type);
+
 /*
  * Return the handler for particular signature list types found in the dbx.
  */
diff --git a/security/integrity/platform_certs/load_uefi.c b/security/integrity/platform_certs/load_uefi.c
index f290f78c3f30..c1bfd1cd7cc3 100644
--- a/security/integrity/platform_certs/load_uefi.c
+++ b/security/integrity/platform_certs/load_uefi.c
@@ -94,7 +94,7 @@ static int __init load_moklist_certs(void)
 		rc = parse_efi_signature_list("UEFI:MokListRT (MOKvar table)",
 					      mokvar_entry->data,
 					      mokvar_entry->data_size,
-					      get_handler_for_db);
+					      get_handler_for_mok);
 		/* All done if that worked. */
 		if (!rc)
 			return rc;
@@ -109,7 +109,7 @@ static int __init load_moklist_certs(void)
 	mok = get_cert_list(L"MokListRT", &mok_var, &moksize, &status);
 	if (mok) {
 		rc = parse_efi_signature_list("UEFI:MokListRT",
-					      mok, moksize, get_handler_for_db);
+					      mok, moksize, get_handler_for_mok);
 		kfree(mok);
 		if (rc)
 			pr_err("Couldn't parse MokListRT signatures: %d\n", rc);
-- 
2.18.4

Re: [PATCH v7 08/17] integrity: add new keyring handler for mok keys

[Mimi Zohar]

On Mon, 2021-11-15 at 19:15 -0500, Eric Snowberg wrote:
> Currently both Secure Boot DB and Machine Owner Keys (MOK) go through
> the same keyring handler (get_handler_for_db). With the addition of the
> new machine keyring, the end-user may choose to trust MOK keys.
> 
> Introduce a new keyring handler specific for MOK keys.  If MOK keys are
> trusted by the end-user, use the new keyring handler instead.
> 
> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>

Reviewed-by:  Mimi Zohar <zohar@linux.ibm.com>

[PATCH v7 09/17] KEYS: Rename get_builtin_and_secondary_restriction

[Eric Snowberg]

To improve clarity, rename get_builtin_and_secondary_restriction to
get_secondary_restriction.

Suggested-by: Mimi Zohar <zohar@linux.ibm.com>
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
v6: Initial version
v7: Unmodified from v7
---
 certs/system_keyring.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/certs/system_keyring.c b/certs/system_keyring.c
index 692365dee2bd..8f1f87579819 100644
--- a/certs/system_keyring.c
+++ b/certs/system_keyring.c
@@ -77,7 +77,7 @@ int restrict_link_by_builtin_and_secondary_trusted(
  * Allocate a struct key_restriction for the "builtin and secondary trust"
  * keyring. Only for use in system_trusted_keyring_init().
  */
-static __init struct key_restriction *get_builtin_and_secondary_restriction(void)
+static __init struct key_restriction *get_secondary_restriction(void)
 {
 	struct key_restriction *restriction;
 
@@ -117,7 +117,7 @@ static __init int system_trusted_keyring_init(void)
 			       KEY_USR_VIEW | KEY_USR_READ | KEY_USR_SEARCH |
 			       KEY_USR_WRITE),
 			      KEY_ALLOC_NOT_IN_QUOTA,
-			      get_builtin_and_secondary_restriction(),
+			      get_secondary_restriction(),
 			      NULL);
 	if (IS_ERR(secondary_trusted_keys))
 		panic("Can't allocate secondary trusted keyring\n");
-- 
2.18.4

Re: [PATCH v7 09/17] KEYS: Rename get_builtin_and_secondary_restriction

[Mimi Zohar]

Hi Eric,

On Mon, 2021-11-15 at 19:15 -0500, Eric Snowberg wrote:
> To improve clarity, rename get_builtin_and_secondary_restriction to
> get_secondary_restriction.

The existing name clarity is fine.  Perhaps instead prefix the above
sentence with "In preparation for returning either the existing
restrict_link_by_builtin_and_secondary_trusted or the new restriction
that includes the trusted builtin, secondary and machine keys, ..."
> 
> Suggested-by: Mimi Zohar <zohar@linux.ibm.com>
> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>

Otherwise,
Reviewed-by:  Mimi Zohar <zohar@linux.ibm.com>

[PATCH v7 10/17] KEYS: add a reference to machine keyring

[Eric Snowberg]

Expose the .machine keyring created in integrity code by adding
a reference.  This makes the machine keyring accessible for keyring
restrictions in the future.

Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
v2: Initial version
v3: set_mok_trusted_keys only available when secondary is enabled
v4: Moved code under CONFIG_INTEGRITY_MOK_KEYRING
v5: Rename to machine keyring
v7: Unmodified from v5
---
 certs/system_keyring.c        | 9 +++++++++
 include/keys/system_keyring.h | 8 ++++++++
 2 files changed, 17 insertions(+)

diff --git a/certs/system_keyring.c b/certs/system_keyring.c
index 8f1f87579819..bc7e44fc82c2 100644
--- a/certs/system_keyring.c
+++ b/certs/system_keyring.c
@@ -22,6 +22,9 @@ static struct key *builtin_trusted_keys;
 #ifdef CONFIG_SECONDARY_TRUSTED_KEYRING
 static struct key *secondary_trusted_keys;
 #endif
+#ifdef CONFIG_INTEGRITY_MACHINE_KEYRING
+static struct key *machine_trusted_keys;
+#endif
 #ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING
 static struct key *platform_trusted_keys;
 #endif
@@ -91,6 +94,12 @@ static __init struct key_restriction *get_secondary_restriction(void)
 	return restriction;
 }
 #endif
+#ifdef CONFIG_INTEGRITY_MACHINE_KEYRING
+void __init set_machine_trusted_keys(struct key *keyring)
+{
+	machine_trusted_keys = keyring;
+}
+#endif
 
 /*
  * Create the trusted keyrings
diff --git a/include/keys/system_keyring.h b/include/keys/system_keyring.h
index 6acd3cf13a18..98c9b10cdc17 100644
--- a/include/keys/system_keyring.h
+++ b/include/keys/system_keyring.h
@@ -38,6 +38,14 @@ extern int restrict_link_by_builtin_and_secondary_trusted(
 #define restrict_link_by_builtin_and_secondary_trusted restrict_link_by_builtin_trusted
 #endif
 
+#ifdef CONFIG_INTEGRITY_MACHINE_KEYRING
+extern void __init set_machine_trusted_keys(struct key *keyring);
+#else
+static inline void __init set_machine_trusted_keys(struct key *keyring)
+{
+}
+#endif
+
 extern struct pkcs7_message *pkcs7;
 #ifdef CONFIG_SYSTEM_BLACKLIST_KEYRING
 extern int mark_hash_blacklisted(const char *hash);
-- 
2.18.4

[PATCH v7 11/17] KEYS: Introduce link restriction for machine keys

[Eric Snowberg]

Introduce a new link restriction that includes the trusted builtin,
secondary and machine keys. The restriction is based on the key to be
added being vouched for by a key in any of these three keyrings.

Suggested-by: Mimi Zohar <zohar@linux.ibm.com>
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
v3: Initial version
v4: moved code under CONFIG_INTEGRITY_MOK_KEYRING
v5: Rename to machine keyring
v6: Change subject name (suggested by Mimi)
    Rename restrict_link_by_builtin_secondary_and_ca_trusted
      to restrict_link_by_builtin_secondary_and_machine (suggested by
      Mimi)
v7: Unmodified from v6
---
 certs/system_keyring.c        | 23 +++++++++++++++++++++++
 include/keys/system_keyring.h |  6 ++++++
 2 files changed, 29 insertions(+)

diff --git a/certs/system_keyring.c b/certs/system_keyring.c
index bc7e44fc82c2..71a00add9805 100644
--- a/certs/system_keyring.c
+++ b/certs/system_keyring.c
@@ -99,6 +99,29 @@ void __init set_machine_trusted_keys(struct key *keyring)
 {
 	machine_trusted_keys = keyring;
 }
+
+/**
+ * restrict_link_by_builtin_secondary_and_machine
+ *
+ * Restrict the addition of keys into a keyring based on the key-to-be-added
+ * being vouched for by a key in either the built-in, the secondary, or
+ * the machine keyrings.
+ */
+int restrict_link_by_builtin_secondary_and_machine(
+	struct key *dest_keyring,
+	const struct key_type *type,
+	const union key_payload *payload,
+	struct key *restrict_key)
+{
+	if (machine_trusted_keys && type == &key_type_keyring &&
+	    dest_keyring == secondary_trusted_keys &&
+	    payload == &machine_trusted_keys->payload)
+		/* Allow the machine keyring to be added to the secondary */
+		return 0;
+
+	return restrict_link_by_builtin_and_secondary_trusted(dest_keyring, type,
+							      payload, restrict_key);
+}
 #endif
 
 /*
diff --git a/include/keys/system_keyring.h b/include/keys/system_keyring.h
index 98c9b10cdc17..2419a735420f 100644
--- a/include/keys/system_keyring.h
+++ b/include/keys/system_keyring.h
@@ -39,8 +39,14 @@ extern int restrict_link_by_builtin_and_secondary_trusted(
 #endif
 
 #ifdef CONFIG_INTEGRITY_MACHINE_KEYRING
+extern int restrict_link_by_builtin_secondary_and_machine(
+	struct key *dest_keyring,
+	const struct key_type *type,
+	const union key_payload *payload,
+	struct key *restrict_key);
 extern void __init set_machine_trusted_keys(struct key *keyring);
 #else
+#define restrict_link_by_builtin_secondary_and_machine restrict_link_by_builtin_trusted
 static inline void __init set_machine_trusted_keys(struct key *keyring)
 {
 }
-- 
2.18.4

Re: [PATCH v7 11/17] KEYS: Introduce link restriction for machine keys

[Mimi Zohar]

Hi Eric,

On Mon, 2021-11-15 at 19:15 -0500, Eric Snowberg wrote:
> Introduce a new link restriction that includes the trusted builtin,
> secondary and machine keys. The restriction is based on the key to be
> added being vouched for by a key in any of these three keyrings.
> 
> Suggested-by: Mimi Zohar <zohar@linux.ibm.com>
> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
> ---
> v3: Initial version
> v4: moved code under CONFIG_INTEGRITY_MOK_KEYRING
> v5: Rename to machine keyring
> v6: Change subject name (suggested by Mimi)
>     Rename restrict_link_by_builtin_secondary_and_ca_trusted
>       to restrict_link_by_builtin_secondary_and_machine (suggested by
>       Mimi)
> v7: Unmodified from v6
> ---
>  certs/system_keyring.c        | 23 +++++++++++++++++++++++
>  include/keys/system_keyring.h |  6 ++++++
>  2 files changed, 29 insertions(+)
> 
> diff --git a/certs/system_keyring.c b/certs/system_keyring.c
> index bc7e44fc82c2..71a00add9805 100644
> --- a/certs/system_keyring.c
> +++ b/certs/system_keyring.c
> @@ -99,6 +99,29 @@ void __init set_machine_trusted_keys(struct key *keyring)
>  {
>  	machine_trusted_keys = keyring;
>  }
> +
> +/**

This begins the start of kernel doc. 

> + * restrict_link_by_builtin_secondary_and_machine

Missing are the parameter defintions.  Please refer to
Documentation/doc-guide/kernel-doc.rst for details.

Mimi

> + *
> + * Restrict the addition of keys into a keyring based on the key-to-be-added
> + * being vouched for by a key in either the built-in, the secondary, or
> + * the machine keyrings.
> + */
> +int restrict_link_by_builtin_secondary_and_machine(
> +	struct key *dest_keyring,
> +	const struct key_type *type,
> +	const union key_payload *payload,
> +	struct key *restrict_key)
> +{
> +	if (machine_trusted_keys && type == &key_type_keyring &&
> +	    dest_keyring == secondary_trusted_keys &&
> +	    payload == &machine_trusted_keys->payload)
> +		/* Allow the machine keyring to be added to the secondary */
> +		return 0;
> +
> +	return restrict_link_by_builtin_and_secondary_trusted(dest_keyring, type,
> +							      payload, restrict_key);
> +}
>  #endif
>  
>  /*
> diff --git a/include/keys/system_keyring.h b/include/keys/system_keyring.h
> index 98c9b10cdc17..2419a735420f 100644
> --- a/include/keys/system_keyring.h
> +++ b/include/keys/system_keyring.h
> @@ -39,8 +39,14 @@ extern int restrict_link_by_builtin_and_secondary_trusted(
>  #endif
>  
>  #ifdef CONFIG_INTEGRITY_MACHINE_KEYRING
> +extern int restrict_link_by_builtin_secondary_and_machine(
> +	struct key *dest_keyring,
> +	const struct key_type *type,
> +	const union key_payload *payload,
> +	struct key *restrict_key);
>  extern void __init set_machine_trusted_keys(struct key *keyring);
>  #else
> +#define restrict_link_by_builtin_secondary_and_machine restrict_link_by_builtin_trusted
>  static inline void __init set_machine_trusted_keys(struct key *keyring)
>  {
>  }

Re: [PATCH v7 11/17] KEYS: Introduce link restriction for machine keys

[Eric Snowberg]

> On Nov 18, 2021, at 5:20 PM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> 
> Hi Eric,
> 
> On Mon, 2021-11-15 at 19:15 -0500, Eric Snowberg wrote:
>> Introduce a new link restriction that includes the trusted builtin,
>> secondary and machine keys. The restriction is based on the key to be
>> added being vouched for by a key in any of these three keyrings.
>> 
>> Suggested-by: Mimi Zohar <zohar@linux.ibm.com>
>> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
>> ---
>> v3: Initial version
>> v4: moved code under CONFIG_INTEGRITY_MOK_KEYRING
>> v5: Rename to machine keyring
>> v6: Change subject name (suggested by Mimi)
>>    Rename restrict_link_by_builtin_secondary_and_ca_trusted
>>      to restrict_link_by_builtin_secondary_and_machine (suggested by
>>      Mimi)
>> v7: Unmodified from v6
>> ---
>> certs/system_keyring.c        | 23 +++++++++++++++++++++++
>> include/keys/system_keyring.h |  6 ++++++
>> 2 files changed, 29 insertions(+)
>> 
>> diff --git a/certs/system_keyring.c b/certs/system_keyring.c
>> index bc7e44fc82c2..71a00add9805 100644
>> --- a/certs/system_keyring.c
>> +++ b/certs/system_keyring.c
>> @@ -99,6 +99,29 @@ void __init set_machine_trusted_keys(struct key *keyring)
>> {
>> 	machine_trusted_keys = keyring;
>> }
>> +
>> +/**
> 
> This begins the start of kernel doc. 
> 
>> + * restrict_link_by_builtin_secondary_and_machine
> 
> Missing are the parameter defintions.  Please refer to
> Documentation/doc-guide/kernel-doc.rst for details.

I’ll add this in the next round, thanks.

[PATCH v7 12/17] KEYS: integrity: change link restriction to trust the machine keyring

[Eric Snowberg]

With the introduction of the machine keyring, the end-user may choose to
trust Machine Owner Keys (MOK) within the kernel. If they have chosen to
trust them, the .machine keyring will contain these keys.  If not, the
machine keyring will always be empty.  Update the restriction check to
allow the secondary trusted keyring and ima keyring to also trust
machine keys.

Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
v4: Initial version (consolidated two previous patches)
v5: Rename to machine keyring
v6: Account for restriction being renamed earlier
v7: Unmodified from v6
---
 certs/system_keyring.c      | 5 ++++-
 security/integrity/digsig.c | 4 ++++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/certs/system_keyring.c b/certs/system_keyring.c
index 71a00add9805..ba732856ebd0 100644
--- a/certs/system_keyring.c
+++ b/certs/system_keyring.c
@@ -89,7 +89,10 @@ static __init struct key_restriction *get_secondary_restriction(void)
 	if (!restriction)
 		panic("Can't allocate secondary trusted keyring restriction\n");
 
-	restriction->check = restrict_link_by_builtin_and_secondary_trusted;
+	if (IS_ENABLED(CONFIG_INTEGRITY_MACHINE_KEYRING))
+		restriction->check = restrict_link_by_builtin_secondary_and_machine;
+	else
+		restriction->check = restrict_link_by_builtin_and_secondary_trusted;
 
 	return restriction;
 }
diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
index e7dfc55a7c55..74f73f7cc4fe 100644
--- a/security/integrity/digsig.c
+++ b/security/integrity/digsig.c
@@ -34,7 +34,11 @@ static const char * const keyring_name[INTEGRITY_KEYRING_MAX] = {
 };
 
 #ifdef CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY
+#ifdef CONFIG_INTEGRITY_MACHINE_KEYRING
+#define restrict_link_to_ima restrict_link_by_builtin_secondary_and_machine
+#else
 #define restrict_link_to_ima restrict_link_by_builtin_and_secondary_trusted
+#endif
 #else
 #define restrict_link_to_ima restrict_link_by_builtin_trusted
 #endif
-- 
2.18.4

Re: [PATCH v7 12/17] KEYS: integrity: change link restriction to trust the machine keyring

[Mimi Zohar]

On Mon, 2021-11-15 at 19:15 -0500, Eric Snowberg wrote:
> With the introduction of the machine keyring, the end-user may choose to
> trust Machine Owner Keys (MOK) within the kernel. If they have chosen to
> trust them, the .machine keyring will contain these keys.  If not, the
> machine keyring will always be empty.  Update the restriction check to
> allow the secondary trusted keyring and ima keyring to also trust
> machine keys.
> 
> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>

Reviewed-by:  Mimi Zohar <zohar@linux.ibm.com>

[PATCH v7 13/17] KEYS: link secondary_trusted_keys to machine trusted keys

[Eric Snowberg]

Allow the .machine keyring to be linked to the secondary_trusted_keys.
After the link is created, keys contained in the .machine keyring will
automatically be searched when searching secondary_trusted_keys.

Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
v3: Initial version
v4: Unmodified from v3
v5: Rename to machine keyring
v7: Unmodified from v5
---
 certs/system_keyring.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/certs/system_keyring.c b/certs/system_keyring.c
index ba732856ebd0..2a2dc70b126c 100644
--- a/certs/system_keyring.c
+++ b/certs/system_keyring.c
@@ -101,6 +101,9 @@ static __init struct key_restriction *get_secondary_restriction(void)
 void __init set_machine_trusted_keys(struct key *keyring)
 {
 	machine_trusted_keys = keyring;
+
+	if (key_link(secondary_trusted_keys, machine_trusted_keys) < 0)
+		panic("Can't link (machine) trusted keyrings\n");
 }
 
 /**
-- 
2.18.4

Re: [PATCH v7 13/17] KEYS: link secondary_trusted_keys to machine trusted keys

[Mimi Zohar]

Hi Eric,

Is the subject line left over from the original patch?   Shouldn't it
be "link machine trusted keys to secondary_trusted_keys".

On Mon, 2021-11-15 at 19:15 -0500, Eric Snowberg wrote:
> Allow the .machine keyring to be linked to the secondary_trusted_keys.
> After the link is created, keys contained in the .machine keyring will
> automatically be searched when searching secondary_trusted_keys.
> 
> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
> ---
> v3: Initial version
> v4: Unmodified from v3
> v5: Rename to machine keyring
> v7: Unmodified from v5
> ---
>  certs/system_keyring.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/certs/system_keyring.c b/certs/system_keyring.c
> index ba732856ebd0..2a2dc70b126c 100644
> --- a/certs/system_keyring.c
> +++ b/certs/system_keyring.c
> @@ -101,6 +101,9 @@ static __init struct key_restriction *get_secondary_restriction(void)
>  void __init set_machine_trusted_keys(struct key *keyring)
>  {
>  	machine_trusted_keys = keyring;
> +
> +	if (key_link(secondary_trusted_keys, machine_trusted_keys) < 0)
> +		panic("Can't link (machine) trusted keyrings\n");
>  }
>  
>  /**

In general is the ordering of the patches "bisect safe"[1]?  Only in
the next patch is machine_trusted_keys set.   In this case, either
merge the two patches or reverse their order.

thanks,

Mimi

[1] Refer to the section "Separate your changes" in
Documentation/process/submitting-patches.rst.

Re: [PATCH v7 13/17] KEYS: link secondary_trusted_keys to machine trusted keys

[Eric Snowberg]

> On Nov 18, 2021, at 5:32 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> 
> Hi Eric,
> 
> Is the subject line left over from the original patch?   Shouldn't it
> be "link machine trusted keys to secondary_trusted_keys".

Yes, you are right, this was left over from the original patch.  I’ll update
the heading in the next round.

> On Mon, 2021-11-15 at 19:15 -0500, Eric Snowberg wrote:
>> Allow the .machine keyring to be linked to the secondary_trusted_keys.
>> After the link is created, keys contained in the .machine keyring will
>> automatically be searched when searching secondary_trusted_keys.
>> 
>> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
>> ---
>> v3: Initial version
>> v4: Unmodified from v3
>> v5: Rename to machine keyring
>> v7: Unmodified from v5
>> ---
>> certs/system_keyring.c | 3 +++
>> 1 file changed, 3 insertions(+)
>> 
>> diff --git a/certs/system_keyring.c b/certs/system_keyring.c
>> index ba732856ebd0..2a2dc70b126c 100644
>> --- a/certs/system_keyring.c
>> +++ b/certs/system_keyring.c
>> @@ -101,6 +101,9 @@ static __init struct key_restriction *get_secondary_restriction(void)
>> void __init set_machine_trusted_keys(struct key *keyring)
>> {
>> 	machine_trusted_keys = keyring;
>> +
>> +	if (key_link(secondary_trusted_keys, machine_trusted_keys) < 0)
>> +		panic("Can't link (machine) trusted keyrings\n");
>> }
>> 
>> /**
> 
> In general is the ordering of the patches "bisect safe"[1]?  Only in
> the next patch is machine_trusted_keys set.   In this case, either
> merge the two patches or reverse their order.

I’ll also reverse the ordering in the next round too.  Thanks.

[PATCH v7 14/17] integrity: store reference to machine keyring

[Eric Snowberg]

Store a reference to the machine keyring in system keyring code. The
system keyring code needs this to complete the keyring link to
to machine keyring.

Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
v2: Initial version
v3: Unmodified from v2
v4: Removed trust_moklist check
v5: Rename to machine keyring
v7: Unmodified from v5
---
 security/integrity/digsig.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
index 74f73f7cc4fe..109b58840d45 100644
--- a/security/integrity/digsig.c
+++ b/security/integrity/digsig.c
@@ -116,6 +116,8 @@ static int __init __integrity_init_keyring(const unsigned int id,
 	} else {
 		if (id == INTEGRITY_KEYRING_PLATFORM)
 			set_platform_trusted_keys(keyring[id]);
+		if (id == INTEGRITY_KEYRING_MACHINE)
+			set_machine_trusted_keys(keyring[id]);
 		if (id == INTEGRITY_KEYRING_IMA)
 			load_module_cert(keyring[id]);
 	}
-- 
2.18.4

[PATCH v7 15/17] efi/mokvar: move up init order

[Eric Snowberg]

Move up the init order so it can be used by the new machine keyring.

Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
v7: Initial version
---
 drivers/firmware/efi/mokvar-table.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/mokvar-table.c b/drivers/firmware/efi/mokvar-table.c
index 38722d2009e2..5ed0602c2f75 100644
--- a/drivers/firmware/efi/mokvar-table.c
+++ b/drivers/firmware/efi/mokvar-table.c
@@ -359,4 +359,4 @@ static int __init efi_mokvar_sysfs_init(void)
 	}
 	return err;
 }
-device_initcall(efi_mokvar_sysfs_init);
+fs_initcall(efi_mokvar_sysfs_init);
-- 
2.18.4

[PATCH v7 16/17] integrity: Trust MOK keys if MokListTrustedRT found

[Eric Snowberg]

A new Machine Owner Key (MOK) variable called MokListTrustedRT has been
introduced in shim. When this UEFI variable is set, it indicates the
end-user has made the decision themselves that they wish to trust MOK keys
within the Linux trust boundary.  It is not an error if this variable
does not exist. If it does not exist, the MOK keys should not be trusted
within the kernel.

Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
v1: Initial version
v2: Removed mok_keyring_trust_setup function
v4: Unmodified from v2
v5: Rename to machine keyring
v6: Unmodified from v5
v7: Use mokvar table instead of EFI var (suggested by Peter Jones)
---
 .../platform_certs/machine_keyring.c          | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/security/integrity/platform_certs/machine_keyring.c b/security/integrity/platform_certs/machine_keyring.c
index ea2ac2f9f2b5..09fd8f20c756 100644
--- a/security/integrity/platform_certs/machine_keyring.c
+++ b/security/integrity/platform_certs/machine_keyring.c
@@ -5,6 +5,7 @@
  * Copyright (c) 2021, Oracle and/or its affiliates.
  */
 
+#include <linux/efi.h>
 #include "../integrity.h"
 
 static __init int machine_keyring_init(void)
@@ -40,3 +41,21 @@ void __init add_to_machine_keyring(const char *source, const void *data, size_t
 	if (rc)
 		pr_info("Error adding keys to machine keyring %s\n", source);
 }
+
+/*
+ * Try to load the MokListTrustedRT MOK variable to see if we should trust
+ * the MOK keys within the kernel. It is not an error if this variable
+ * does not exist.  If it does not exist, MOK keys should not be trusted
+ * within the machine keyring.
+ */
+static __init bool uefi_check_trust_mok_keys(void)
+{
+	struct efi_mokvar_table_entry *mokvar_entry;
+
+	mokvar_entry = efi_mokvar_entry_find("MokListTrustedRT");
+
+	if (mokvar_entry)
+		return true;
+
+	return false;
+}
-- 
2.18.4

[PATCH v7 17/17] integrity: Only use machine keyring when uefi_check_trust_mok_keys is true

[Eric Snowberg]

With the introduction of uefi_check_trust_mok_keys, it signifies the end-
user wants to trust the machine keyring as trusted keys.  If they have
chosen to trust the machine keyring, load the qualifying keys into it
during boot, then link it to the secondary keyring .  If the user has not
chosen to trust the machine keyring, it will be empty and not linked to
the secondary keyring.

Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
v4: Initial version
v5: Rename to machine keyring
v6: Unmodified from v5
v7: Made trust_mok static
---
 security/integrity/digsig.c                      |  2 +-
 security/integrity/integrity.h                   |  5 +++++
 .../integrity/platform_certs/keyring_handler.c   |  2 +-
 .../integrity/platform_certs/machine_keyring.c   | 16 ++++++++++++++++
 4 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
index 109b58840d45..1de09c7b5f93 100644
--- a/security/integrity/digsig.c
+++ b/security/integrity/digsig.c
@@ -116,7 +116,7 @@ static int __init __integrity_init_keyring(const unsigned int id,
 	} else {
 		if (id == INTEGRITY_KEYRING_PLATFORM)
 			set_platform_trusted_keys(keyring[id]);
-		if (id == INTEGRITY_KEYRING_MACHINE)
+		if (id == INTEGRITY_KEYRING_MACHINE && trust_moklist())
 			set_machine_trusted_keys(keyring[id]);
 		if (id == INTEGRITY_KEYRING_IMA)
 			load_module_cert(keyring[id]);
diff --git a/security/integrity/integrity.h b/security/integrity/integrity.h
index 730771eececd..2e214c761158 100644
--- a/security/integrity/integrity.h
+++ b/security/integrity/integrity.h
@@ -287,9 +287,14 @@ static inline void __init add_to_platform_keyring(const char *source,
 
 #ifdef CONFIG_INTEGRITY_MACHINE_KEYRING
 void __init add_to_machine_keyring(const char *source, const void *data, size_t len);
+bool __init trust_moklist(void);
 #else
 static inline void __init add_to_machine_keyring(const char *source,
 						  const void *data, size_t len)
 {
 }
+static inline bool __init trust_moklist(void)
+{
+	return false;
+}
 #endif
diff --git a/security/integrity/platform_certs/keyring_handler.c b/security/integrity/platform_certs/keyring_handler.c
index 4872850d081f..1db4d3b4356d 100644
--- a/security/integrity/platform_certs/keyring_handler.c
+++ b/security/integrity/platform_certs/keyring_handler.c
@@ -83,7 +83,7 @@ __init efi_element_handler_t get_handler_for_db(const efi_guid_t *sig_type)
 __init efi_element_handler_t get_handler_for_mok(const efi_guid_t *sig_type)
 {
 	if (efi_guidcmp(*sig_type, efi_cert_x509_guid) == 0) {
-		if (IS_ENABLED(CONFIG_INTEGRITY_MACHINE_KEYRING))
+		if (IS_ENABLED(CONFIG_INTEGRITY_MACHINE_KEYRING) && trust_moklist())
 			return add_to_machine_keyring;
 		else
 			return add_to_platform_keyring;
diff --git a/security/integrity/platform_certs/machine_keyring.c b/security/integrity/platform_certs/machine_keyring.c
index 09fd8f20c756..7aaed7950b6e 100644
--- a/security/integrity/platform_certs/machine_keyring.c
+++ b/security/integrity/platform_certs/machine_keyring.c
@@ -8,6 +8,8 @@
 #include <linux/efi.h>
 #include "../integrity.h"
 
+static bool trust_mok;
+
 static __init int machine_keyring_init(void)
 {
 	int rc;
@@ -59,3 +61,17 @@ static __init bool uefi_check_trust_mok_keys(void)
 
 	return false;
 }
+
+bool __init trust_moklist(void)
+{
+	static bool initialized;
+
+	if (!initialized) {
+		initialized = true;
+
+		if (uefi_check_trust_mok_keys())
+			trust_mok = true;
+	}
+
+	return trust_mok;
+}
-- 
2.18.4

Re: [PATCH v7 00/17] Enroll kernel keys thru MOK

[Jarkko Sakkinen]

On Mon, 2021-11-15 at 19:15 -0500, Eric Snowberg wrote:
> Back in 2013 Linus requested a feature to allow end-users to have the 
> ability "to add their own keys and sign modules they trust". This was
> his *second* order outlined here [1]. There have been many attempts 
> over the years to solve this problem, all have been rejected.  Many 
> of the failed attempts loaded all preboot firmware keys into the kernel,
> including the Secure Boot keys. Many distributions carry one of these 
> rejected attempts [2], [3], [4]. This series tries to solve this problem 
> with a solution that takes into account all the problems brought up in 
> the previous attempts.
> 
> On UEFI based systems, this series introduces a new Linux kernel keyring 
> containing the Machine Owner Keys (MOK) called machine. It also defines
> a new MOK variable in shim. This variable allows the end-user to decide 
> if they want to load MOK keys into the machine keyring. Mimi has suggested 
> that only CA keys contained within the MOK be loaded into the machine 
> keyring. All other certs will load into the platform keyring instead.
> 
> By default, nothing changes; MOK keys are not loaded into the machine
> keyring.  They are only loaded after the end-user makes the decision 
> themselves.  The end-user would set this through mokutil using a new 
> --trust-mok option [5]. This would work similar to how the kernel uses 
> MOK variables to enable/disable signature validation as well as use/ignore 
> the db. Any kernel operation that uses either the builtin or secondary 
> trusted keys as a trust source shall also reference the new machine 
> keyring as a trust source.
> 
> Secure Boot keys will never be loaded into the machine keyring.  They
> will always be loaded into the platform keyring.  If an end-user wanted 
> to load one, they would need to enroll it into the MOK.
> 
> Steps required by the end user:
> 
> Sign kernel module with user created key:
> $ /usr/src/kernels/$(uname -r)/scripts/sign-file sha512 \
>    machine_signing_key.priv machine_signing_key.x509 my_module.ko
> 
> Import the key into the MOK
> $ mokutil --import machine_signing_key.x509
> 
> Setup the kernel to load MOK keys into the .machine keyring
> $ mokutil --trust-mok
> 
> Then reboot, the MokManager will load and ask if you want to trust the
> MOK key and enroll the MOK into the MOKList.  Afterwards the signed kernel
> module will load.
> 
> I have included  a link to the mokutil [5] changes I have made to support 
> this new functionality.  The shim changes have now been accepted
> upstream [6].
> 
> [1] https://marc.info/?l=linux-kernel&m=136185386310140&w=2
> [2] https://lore.kernel.org/lkml/1479737095.2487.34.camel@linux.vnet.ibm.com/
> [3] https://lore.kernel.org/lkml/1556221605.24945.3.camel@HansenPartnership.com/
> [4] https://lore.kernel.org/linux-integrity/1e41f22b1f11784f1e943f32bf62034d4e054cdb.camel@HansenPartnership.com/
> [5] https://github.com/esnowberg/mokutil/tree/mokvars-v3
> [6] https://github.com/rhboot/shim/commit/4e513405b4f1641710115780d19dcec130c5208f
> 
> Eric Snowberg (17):
>   integrity: Introduce a Linux keyring called machine
>   integrity: Do not allow machine keyring updates following init
>   KEYS: Create static version of public_key_verify_signature
>   X.509: Parse Basic Constraints for CA
>   KEYS: CA link restriction
>   integrity: restrict INTEGRITY_KEYRING_MACHINE to restrict_link_by_ca
>   integrity: Fix warning about missing prototypes
>   integrity: add new keyring handler for mok keys
>   KEYS: Rename get_builtin_and_secondary_restriction
>   KEYS: add a reference to machine keyring
>   KEYS: Introduce link restriction for machine keys
>   KEYS: integrity: change link restriction to trust the machine keyring
>   KEYS: link secondary_trusted_keys to machine trusted keys
>   integrity: store reference to machine keyring
>   efi/mokvar: move up init order
>   integrity: Trust MOK keys if MokListTrustedRT found
>   integrity: Only use machine keyring when uefi_check_trust_mok_keys is
>     true
> 
>  certs/system_keyring.c                        | 44 ++++++++++-
>  crypto/asymmetric_keys/restrict.c             | 43 +++++++++++
>  crypto/asymmetric_keys/x509_cert_parser.c     |  9 +++
>  drivers/firmware/efi/mokvar-table.c           |  2 +-
>  include/crypto/public_key.h                   | 15 ++++
>  include/keys/system_keyring.h                 | 14 ++++
>  security/integrity/Kconfig                    | 12 +++
>  security/integrity/Makefile                   |  1 +
>  security/integrity/digsig.c                   | 23 +++++-
>  security/integrity/integrity.h                | 17 +++-
>  .../platform_certs/keyring_handler.c          | 18 ++++-
>  .../platform_certs/keyring_handler.h          |  5 ++
>  security/integrity/platform_certs/load_uefi.c |  4 +-
>  .../platform_certs/machine_keyring.c          | 77 +++++++++++++++++++
>  14 files changed, 273 insertions(+), 11 deletions(-)
>  create mode 100644 security/integrity/platform_certs/machine_keyring.c
> 
> 
> base-commit: fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf

Does shim have the necessary features in a release?

/Jarkko

Re: [PATCH v7 00/17] Enroll kernel keys thru MOK

[Konrad Rzeszutek Wilk]

> > I have included  a link to the mokutil [5] changes I have made to support 
> > this new functionality.  The shim changes have now been accepted
> > upstream [6].

..snip..
> > [6] https://github.com/rhboot/shim/commit/4e513405b4f1641710115780d19dcec130c5208f

..snip..
> 
> Does shim have the necessary features in a release?

Hi!

It has been accepted in the upstream shim. If you are looking
for a distribution having rolled out a shim with this feature (so signed
by MSF) I fear that distributions are not that fast with shim releases.

Also these:
https://github.com/rhboot/shim/pulls
https://github.com/rhboot/shim/issues

do mean some extra work would need to go in before an official
release is cut.

Hope this helps?

Re: [PATCH v7 00/17] Enroll kernel keys thru MOK

[Jarkko Sakkinen]

On Tue, 2021-11-16 at 11:18 -0500, Konrad Rzeszutek Wilk wrote:
> > > I have included  a link to the mokutil [5] changes I have made to support 
> > > this new functionality.  The shim changes have now been accepted
> > > upstream [6].
> 
> ..snip..
> > > [6] https://github.com/rhboot/shim/commit/4e513405b4f1641710115780d19dcec130c5208f
> 
> ..snip..
> > 
> > Does shim have the necessary features in a release?
> 
> Hi!
> 
> It has been accepted in the upstream shim. If you are looking
> for a distribution having rolled out a shim with this feature (so signed
> by MSF) I fear that distributions are not that fast with shim releases.
> 
> Also these:
> https://github.com/rhboot/shim/pulls
> https://github.com/rhboot/shim/issues
> 
> do mean some extra work would need to go in before an official
> release is cut.
> 
> Hope this helps?

Yes. I'll hold with this up until there is an official release. Thank you.

/Jarkko

Re: [PATCH v7 00/17] Enroll kernel keys thru MOK

[Konrad Rzeszutek Wilk]

On Tue, Nov 16, 2021 at 06:24:52PM +0200, Jarkko Sakkinen wrote:
> On Tue, 2021-11-16 at 11:18 -0500, Konrad Rzeszutek Wilk wrote:
> > > > I have included  a link to the mokutil [5] changes I have made to support 
> > > > this new functionality.  The shim changes have now been accepted
> > > > upstream [6].
> > 
> > ..snip..
> > > > [6] https://github.com/rhboot/shim/commit/4e513405b4f1641710115780d19dcec130c5208f
> > 
> > ..snip..
> > > 
> > > Does shim have the necessary features in a release?
> > 
> > Hi!
> > 
> > It has been accepted in the upstream shim. If you are looking
> > for a distribution having rolled out a shim with this feature (so signed
> > by MSF) I fear that distributions are not that fast with shim releases.
> > 
> > Also these:
> > https://github.com/rhboot/shim/pulls
> > https://github.com/rhboot/shim/issues
> > 
> > do mean some extra work would need to go in before an official
> > release is cut.
> > 
> > Hope this helps?
> 
> Yes. I'll hold with this up until there is an official release. Thank you.

Not sure I understand - but what are the concerns you have with shim
code that has been accepted?

Re: [PATCH v7 00/17] Enroll kernel keys thru MOK

[Jarkko Sakkinen]

On Tue, 2021-11-16 at 11:39 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 16, 2021 at 06:24:52PM +0200, Jarkko Sakkinen wrote:
> > On Tue, 2021-11-16 at 11:18 -0500, Konrad Rzeszutek Wilk wrote:
> > > > > I have included  a link to the mokutil [5] changes I have made to support 
> > > > > this new functionality.  The shim changes have now been accepted
> > > > > upstream [6].
> > > 
> > > ..snip..
> > > > > [6] https://github.com/rhboot/shim/commit/4e513405b4f1641710115780d19dcec130c5208f
> > > 
> > > ..snip..
> > > > 
> > > > Does shim have the necessary features in a release?
> > > 
> > > Hi!
> > > 
> > > It has been accepted in the upstream shim. If you are looking
> > > for a distribution having rolled out a shim with this feature (so signed
> > > by MSF) I fear that distributions are not that fast with shim releases.
         ~~~

Should that be MS, or what does MSF mean?

> > > 
> > > Also these:
> > > https://github.com/rhboot/shim/pulls
> > > https://github.com/rhboot/shim/issues
> > > 
> > > do mean some extra work would need to go in before an official
> > > release is cut.
> > > 
> > > Hope this helps?
> > 
> > Yes. I'll hold with this up until there is an official release. Thank you.
> 
> Not sure I understand - but what are the concerns you have with shim
> code that has been accepted?

Maybe my concern is that none of the patches have a tested-by?

Probably would be easier to get a test coverage, e.g. for people like
me who do not even know how to self-compile Shim, how to setup user
space using the product and so forth.

I don't demand a release, if the changes have been accepted, but 17
patches do need to be tested.

/Jarkko

Re: [PATCH v7 00/17] Enroll kernel keys thru MOK

[Jarkko Sakkinen]

On Wed, 2021-11-17 at 09:50 +0200, Jarkko Sakkinen wrote:
> On Tue, 2021-11-16 at 11:39 -0500, Konrad Rzeszutek Wilk wrote:
> > On Tue, Nov 16, 2021 at 06:24:52PM +0200, Jarkko Sakkinen wrote:
> > > On Tue, 2021-11-16 at 11:18 -0500, Konrad Rzeszutek Wilk wrote:
> > > > > > I have included  a link to the mokutil [5] changes I have made to support 
> > > > > > this new functionality.  The shim changes have now been accepted
> > > > > > upstream [6].
> > > > 
> > > > ..snip..
> > > > > > [6] https://github.com/rhboot/shim/commit/4e513405b4f1641710115780d19dcec130c5208f
> > > > 
> > > > ..snip..
> > > > > 
> > > > > Does shim have the necessary features in a release?
> > > > 
> > > > Hi!
> > > > 
> > > > It has been accepted in the upstream shim. If you are looking
> > > > for a distribution having rolled out a shim with this feature (so signed
> > > > by MSF) I fear that distributions are not that fast with shim releases.
>          ~~~
> 
> Should that be MS, or what does MSF mean?
> 
> > > > 
> > > > Also these:
> > > > https://github.com/rhboot/shim/pulls
> > > > https://github.com/rhboot/shim/issues
> > > > 
> > > > do mean some extra work would need to go in before an official
> > > > release is cut.
> > > > 
> > > > Hope this helps?
> > > 
> > > Yes. I'll hold with this up until there is an official release. Thank you.
> > 
> > Not sure I understand - but what are the concerns you have with shim
> > code that has been accepted?
> 
> Maybe my concern is that none of the patches have a tested-by?
> 
> Probably would be easier to get a test coverage, e.g. for people like
> me who do not even know how to self-compile Shim, how to setup user
> space using the product and so forth.
        ~~~~~~~~~~~~~~~~~

for the end product

/Jarkko

Re: [PATCH v7 00/17] Enroll kernel keys thru MOK

[Konrad Rzeszutek Wilk]

On Wed, Nov 17, 2021 at 09:51:25AM +0200, Jarkko Sakkinen wrote:
> On Wed, 2021-11-17 at 09:50 +0200, Jarkko Sakkinen wrote:
> > On Tue, 2021-11-16 at 11:39 -0500, Konrad Rzeszutek Wilk wrote:
> > > On Tue, Nov 16, 2021 at 06:24:52PM +0200, Jarkko Sakkinen wrote:
> > > > On Tue, 2021-11-16 at 11:18 -0500, Konrad Rzeszutek Wilk wrote:
> > > > > > > I have included  a link to the mokutil [5] changes I have made to support 
> > > > > > > this new functionality.  The shim changes have now been accepted
> > > > > > > upstream [6].
> > > > > 
> > > > > ..snip..
> > > > > > > [6] https://github.com/rhboot/shim/commit/4e513405b4f1641710115780d19dcec130c5208f
> > > > > 
> > > > > ..snip..
> > > > > > 
> > > > > > Does shim have the necessary features in a release?
> > > > > 
> > > > > Hi!
> > > > > 
> > > > > It has been accepted in the upstream shim. If you are looking
> > > > > for a distribution having rolled out a shim with this feature (so signed
> > > > > by MSF) I fear that distributions are not that fast with shim releases.
> >          ~~~
> > 
> > Should that be MS, or what does MSF mean?

Microsoft :-)

> > 
> > > > > 
> > > > > Also these:
> > > > > https://github.com/rhboot/shim/pulls
> > > > > https://github.com/rhboot/shim/issues
> > > > > 
> > > > > do mean some extra work would need to go in before an official
> > > > > release is cut.
> > > > > 
> > > > > Hope this helps?
> > > > 
> > > > Yes. I'll hold with this up until there is an official release. Thank you.
> > > 
> > > Not sure I understand - but what are the concerns you have with shim
> > > code that has been accepted?
> > 
> > Maybe my concern is that none of the patches have a tested-by?
> > 
> > Probably would be easier to get a test coverage, e.g. for people like
> > me who do not even know how to self-compile Shim, how to setup user
> > space using the product and so forth.
>         ~~~~~~~~~~~~~~~~~
> 
> for the end product

<nods> That makes total sense. Thanks for the explanation, let me double
check whether

https://github.com/rhboot/shim/blob/main/BUILDING

is still correct.
> 
> /Jarkko
> 
> 
> 

Re: [PATCH v7 00/17] Enroll kernel keys thru MOK

[Eric Snowberg]

> On Nov 17, 2021, at 10:02 AM, Konrad Wilk <konrad.wilk@oracle.com> wrote:
> 
> On Wed, Nov 17, 2021 at 09:51:25AM +0200, Jarkko Sakkinen wrote:
>> On Wed, 2021-11-17 at 09:50 +0200, Jarkko Sakkinen wrote:
>>> On Tue, 2021-11-16 at 11:39 -0500, Konrad Rzeszutek Wilk wrote:
>>>> On Tue, Nov 16, 2021 at 06:24:52PM +0200, Jarkko Sakkinen wrote:
>>>>> On Tue, 2021-11-16 at 11:18 -0500, Konrad Rzeszutek Wilk wrote:
>>>>>>>> I have included  a link to the mokutil [5] changes I have made to support 
>>>>>>>> this new functionality.  The shim changes have now been accepted
>>>>>>>> upstream [6].
>>>>>> 
>>>>>> ..snip..
>>>>>>>> [6] https://github.com/rhboot/shim/commit/4e513405b4f1641710115780d19dcec130c5208f
>>>>>> 
>>>>>> ..snip..
>>>>>>> 
>>>>>>> Does shim have the necessary features in a release?
>>>>>> 
>>>>>> Hi!
>>>>>> 
>>>>>> It has been accepted in the upstream shim. If you are looking
>>>>>> for a distribution having rolled out a shim with this feature (so signed
>>>>>> by MSF) I fear that distributions are not that fast with shim releases.
>>>          ~~~
>>> 
>>> Should that be MS, or what does MSF mean?
> 
> Microsoft :-)

Correct, I’ll fix that in the next round.

>>>>>> 
>>>>>> Also these:
>>>>>> https://github.com/rhboot/shim/pulls
>>>>>> https://github.com/rhboot/shim/issues
>>>>>> 
>>>>>> do mean some extra work would need to go in before an official
>>>>>> release is cut.
>>>>>> 
>>>>>> Hope this helps?
>>>>> 
>>>>> Yes. I'll hold with this up until there is an official release. Thank you.
>>>> 
>>>> Not sure I understand - but what are the concerns you have with shim
>>>> code that has been accepted?
>>> 
>>> Maybe my concern is that none of the patches have a tested-by?
>>> 
>>> Probably would be easier to get a test coverage, e.g. for people like
>>> me who do not even know how to self-compile Shim, how to setup user
>>> space using the product and so forth.
>>        ~~~~~~~~~~~~~~~~~
>> 
>> for the end product
> 
> <nods> That makes total sense. Thanks for the explanation, let me double
> check whether
> 
> https://github.com/rhboot/shim/blob/main/BUILDING
> 
> is still correct.

Those are the steps I use for building.   I then move over mmx64.efi and  
shimx64.efi to the ESP.  I can add the shim build/install instructions to the next
cover letter If you think that would be appropriate.

Re: [PATCH v7 00/17] Enroll kernel keys thru MOK

[Jarkko Sakkinen]

On Wed, 2021-11-17 at 17:20 +0000, Eric Snowberg wrote:
> 
> 
> > On Nov 17, 2021, at 10:02 AM, Konrad Wilk <konrad.wilk@oracle.com> wrote:
> > 
> > On Wed, Nov 17, 2021 at 09:51:25AM +0200, Jarkko Sakkinen wrote:
> > > On Wed, 2021-11-17 at 09:50 +0200, Jarkko Sakkinen wrote:
> > > > On Tue, 2021-11-16 at 11:39 -0500, Konrad Rzeszutek Wilk wrote:
> > > > > On Tue, Nov 16, 2021 at 06:24:52PM +0200, Jarkko Sakkinen wrote:
> > > > > > On Tue, 2021-11-16 at 11:18 -0500, Konrad Rzeszutek Wilk wrote:
> > > > > > > > > I have included  a link to the mokutil [5] changes I have made to support 
> > > > > > > > > this new functionality.  The shim changes have now been accepted
> > > > > > > > > upstream [6].
> > > > > > > 
> > > > > > > ..snip..
> > > > > > > > > [6] https://github.com/rhboot/shim/commit/4e513405b4f1641710115780d19dcec130c5208f
> > > > > > > 
> > > > > > > ..snip..
> > > > > > > > 
> > > > > > > > Does shim have the necessary features in a release?
> > > > > > > 
> > > > > > > Hi!
> > > > > > > 
> > > > > > > It has been accepted in the upstream shim. If you are looking
> > > > > > > for a distribution having rolled out a shim with this feature (so signed
> > > > > > > by MSF) I fear that distributions are not that fast with shim releases.
> > > >          ~~~
> > > > 
> > > > Should that be MS, or what does MSF mean?
> > 
> > Microsoft :-)
> 
> Correct, I’ll fix that in the next round.
> 
> > > > > > > 
> > > > > > > Also these:
> > > > > > > https://github.com/rhboot/shim/pulls
> > > > > > > https://github.com/rhboot/shim/issues
> > > > > > > 
> > > > > > > do mean some extra work would need to go in before an official
> > > > > > > release is cut.
> > > > > > > 
> > > > > > > Hope this helps?
> > > > > > 
> > > > > > Yes. I'll hold with this up until there is an official release. Thank you.
> > > > > 
> > > > > Not sure I understand - but what are the concerns you have with shim
> > > > > code that has been accepted?
> > > > 
> > > > Maybe my concern is that none of the patches have a tested-by?
> > > > 
> > > > Probably would be easier to get a test coverage, e.g. for people like
> > > > me who do not even know how to self-compile Shim, how to setup user
> > > > space using the product and so forth.
> > >        ~~~~~~~~~~~~~~~~~
> > > 
> > > for the end product
> > 
> > <nods> That makes total sense. Thanks for the explanation, let me double
> > check whether
> > 
> > https://github.com/rhboot/shim/blob/main/BUILDING
> > 
> > is still correct.
> 
> Those are the steps I use for building.   I then move over mmx64.efi and  
> shimx64.efi to the ESP.  I can add the shim build/install instructions to the next
> cover letter If you think that would be appropriate.

Yeah, that would be great. I'll try to setup VM for that purpose. I have
already a script to build UEFI enabled archlinux VM's, which I use to
test SGX patches. I can probably tailor that for this purpose.

/Jarkko