[PATCH 1/4] Fix arm64 kexec forbidding kernels signed with keys in the secondary keyring to boot

[PATCH 1/4] Fix arm64 kexec forbidding kernels signed with keys in the secondary keyring to boot

[Michal Suchanek]

commit d3bfe84129f6 ("certs: Add a secondary system keyring that can be added to dynamically")
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().

Cherry-picked from
commit ea93102f3224 ("Fix kexec forbidding kernels signed with keys in the secondary keyring to boot")

Fixes: 732b7b93d849 ("arm64: kexec_file: add kernel signature verification support")
Cc: kexec@lists.infradead.org
Cc: keyrings@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
Cc: stable@kernel.org
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
---
 arch/arm64/kernel/kexec_image.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_image.c
index 9ec34690e255..1fbf2ee7c005 100644
--- a/arch/arm64/kernel/kexec_image.c
+++ b/arch/arm64/kernel/kexec_image.c
@@ -133,7 +133,8 @@ static void *image_load(struct kimage *image,
 #ifdef CONFIG_KEXEC_IMAGE_VERIFY_SIG
 static int image_verify_sig(const char *kernel, unsigned long kernel_len)
 {
-	return verify_pefile_signature(kernel, kernel_len, NULL,
+	return verify_pefile_signature(kernel, kernel_len,
+				       VERIFY_USE_SECONDARY_KEYRING,
 				       VERIFYING_KEXEC_PE_SIGNATURE);
 }
 #endif
-- 
2.31.1

Re: [PATCH 1/4] Fix arm64 kexec forbidding kernels signed with keys in the secondary keyring to boot

[joeyli]

On Tue, Feb 15, 2022 at 08:39:38PM +0100, Michal Suchanek wrote:
> commit d3bfe84129f6 ("certs: Add a secondary system keyring that can be added to dynamically")
> 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().
> 
> Cherry-picked from
> commit ea93102f3224 ("Fix kexec forbidding kernels signed with keys in the secondary keyring to boot")
> 
> Fixes: 732b7b93d849 ("arm64: kexec_file: add kernel signature verification support")
> Cc: kexec@lists.infradead.org
> Cc: keyrings@vger.kernel.org
> Cc: linux-security-module@vger.kernel.org
> Cc: stable@kernel.org
> Signed-off-by: Michal Suchanek <msuchanek@suse.de>

Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>

> ---
>  arch/arm64/kernel/kexec_image.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_image.c
> index 9ec34690e255..1fbf2ee7c005 100644
> --- a/arch/arm64/kernel/kexec_image.c
> +++ b/arch/arm64/kernel/kexec_image.c
> @@ -133,7 +133,8 @@ static void *image_load(struct kimage *image,
>  #ifdef CONFIG_KEXEC_IMAGE_VERIFY_SIG
>  static int image_verify_sig(const char *kernel, unsigned long kernel_len)
>  {
> -	return verify_pefile_signature(kernel, kernel_len, NULL,
> +	return verify_pefile_signature(kernel, kernel_len,
> +				       VERIFY_USE_SECONDARY_KEYRING,
>  				       VERIFYING_KEXEC_PE_SIGNATURE);
>  }
>  #endif
> -- 
> 2.31.1

Re: [PATCH 1/4] Fix arm64 kexec forbidding kernels signed with keys in the secondary keyring to boot

[Baoquan He]

Hi,

On 02/15/22 at 08:39pm, Michal Suchanek wrote:
> commit d3bfe84129f6 ("certs: Add a secondary system keyring that can be added to dynamically")
> 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().
> 
> Cherry-picked from
> commit ea93102f3224 ("Fix kexec forbidding kernels signed with keys in the secondary keyring to boot")

This line may need a line feed?

The patch 1~3 looks good to me. Coiby encountered the same issue
on arm64, and has posted a patch series to fix that and there's clean up
and code adjustment.

https://lore.kernel.org/all/20220401013118.348084-1-coxu@redhat.com/T/#u

Hi Coiby,

Maybe you can check this patchset, and consider how to integrate your
patches based on this patch 1~/3?

For this patch itself, ack.

Acked-by: Baoquan He <bhe@redhat.com>

> 
> Fixes: 732b7b93d849 ("arm64: kexec_file: add kernel signature verification support")
> Cc: kexec@lists.infradead.org
> Cc: keyrings@vger.kernel.org
> Cc: linux-security-module@vger.kernel.org
> Cc: stable@kernel.org
> Signed-off-by: Michal Suchanek <msuchanek@suse.de>
> ---
>  arch/arm64/kernel/kexec_image.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_image.c
> index 9ec34690e255..1fbf2ee7c005 100644
> --- a/arch/arm64/kernel/kexec_image.c
> +++ b/arch/arm64/kernel/kexec_image.c
> @@ -133,7 +133,8 @@ static void *image_load(struct kimage *image,
>  #ifdef CONFIG_KEXEC_IMAGE_VERIFY_SIG
>  static int image_verify_sig(const char *kernel, unsigned long kernel_len)
>  {
> -	return verify_pefile_signature(kernel, kernel_len, NULL,
> +	return verify_pefile_signature(kernel, kernel_len,
> +				       VERIFY_USE_SECONDARY_KEYRING,
>  				       VERIFYING_KEXEC_PE_SIGNATURE);
>  }
>  #endif
> -- 
> 2.31.1
> 

[PATCH 2/4] kexec, KEYS, arm64: Make use of platform keyring for signature verification

[Michal Suchanek]

commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify")
adds platform keyring support on x86 kexec but not arm64.

Add platform keyring support on arm64 as well.

Fixes: 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify")
Cc: kexec@lists.infradead.org
Cc: keyrings@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
Cc: stable@kernel.org
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
---
 arch/arm64/kernel/kexec_image.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_image.c
index 1fbf2ee7c005..3dee7b2d8336 100644
--- a/arch/arm64/kernel/kexec_image.c
+++ b/arch/arm64/kernel/kexec_image.c
@@ -133,9 +133,17 @@ static void *image_load(struct kimage *image,
 #ifdef CONFIG_KEXEC_IMAGE_VERIFY_SIG
 static int image_verify_sig(const char *kernel, unsigned long kernel_len)
 {
-	return verify_pefile_signature(kernel, kernel_len,
-				       VERIFY_USE_SECONDARY_KEYRING,
-				       VERIFYING_KEXEC_PE_SIGNATURE);
+	int ret;
+
+	ret = verify_pefile_signature(kernel, kernel_len,
+				      VERIFY_USE_SECONDARY_KEYRING,
+				      VERIFYING_KEXEC_PE_SIGNATURE);
+	if (ret == -ENOKEY && IS_ENABLED(CONFIG_INTEGRITY_PLATFORM_KEYRING)) {
+		ret = verify_pefile_signature(kernel, kernel_len,
+					      VERIFY_USE_PLATFORM_KEYRING,
+					      VERIFYING_KEXEC_PE_SIGNATURE);
+	}
+	return ret;
 }
 #endif
 
-- 
2.31.1

Re: [PATCH 2/4] kexec, KEYS, arm64: Make use of platform keyring for signature verification

[joeyli]

On Tue, Feb 15, 2022 at 08:39:39PM +0100, Michal Suchanek wrote:
> commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify")
> adds platform keyring support on x86 kexec but not arm64.
> 
> Add platform keyring support on arm64 as well.
> 
> Fixes: 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify")
> Cc: kexec@lists.infradead.org
> Cc: keyrings@vger.kernel.org
> Cc: linux-security-module@vger.kernel.org
> Cc: stable@kernel.org
> Signed-off-by: Michal Suchanek <msuchanek@suse.de>

Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>

> ---
>  arch/arm64/kernel/kexec_image.c | 14 +++++++++++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_image.c
> index 1fbf2ee7c005..3dee7b2d8336 100644
> --- a/arch/arm64/kernel/kexec_image.c
> +++ b/arch/arm64/kernel/kexec_image.c
> @@ -133,9 +133,17 @@ static void *image_load(struct kimage *image,
>  #ifdef CONFIG_KEXEC_IMAGE_VERIFY_SIG
>  static int image_verify_sig(const char *kernel, unsigned long kernel_len)
>  {
> -	return verify_pefile_signature(kernel, kernel_len,
> -				       VERIFY_USE_SECONDARY_KEYRING,
> -				       VERIFYING_KEXEC_PE_SIGNATURE);
> +	int ret;
> +
> +	ret = verify_pefile_signature(kernel, kernel_len,
> +				      VERIFY_USE_SECONDARY_KEYRING,
> +				      VERIFYING_KEXEC_PE_SIGNATURE);
> +	if (ret == -ENOKEY && IS_ENABLED(CONFIG_INTEGRITY_PLATFORM_KEYRING)) {
> +		ret = verify_pefile_signature(kernel, kernel_len,
> +					      VERIFY_USE_PLATFORM_KEYRING,
> +					      VERIFYING_KEXEC_PE_SIGNATURE);
> +	}
> +	return ret;
>  }
>  #endif
>  
> -- 
> 2.31.1

[PATCH 3/4] kexec, KEYS, s390: Make use of built-in and secondary keyring for signature verification

[Michal Suchanek]

commit e23a8020ce4e ("s390/kexec_file: Signature verification prototype")
adds support for KEXEC_SIG verification with keys from platform keyring
but the built-in keys and secondary keyring are not used.

Add support for the built-in keys and secondary keyring as x86 does.

Fixes: e23a8020ce4e ("s390/kexec_file: Signature verification prototype")
Cc: Philipp Rudo <prudo@linux.ibm.com>
Cc: kexec@lists.infradead.org
Cc: keyrings@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
Cc: stable@kernel.org
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
---
 arch/s390/kernel/machine_kexec_file.c | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/arch/s390/kernel/machine_kexec_file.c b/arch/s390/kernel/machine_kexec_file.c
index 8f43575a4dd3..fc6d5f58debe 100644
--- a/arch/s390/kernel/machine_kexec_file.c
+++ b/arch/s390/kernel/machine_kexec_file.c
@@ -31,6 +31,7 @@ int s390_verify_sig(const char *kernel, unsigned long kernel_len)
 	const unsigned long marker_len = sizeof(MODULE_SIG_STRING) - 1;
 	struct module_signature *ms;
 	unsigned long sig_len;
+	int ret;
 
 	/* Skip signature verification when not secure IPLed. */
 	if (!ipl_secure_flag)
@@ -65,11 +66,18 @@ int s390_verify_sig(const char *kernel, unsigned long kernel_len)
 		return -EBADMSG;
 	}
 
-	return verify_pkcs7_signature(kernel, kernel_len,
-				      kernel + kernel_len, sig_len,
-				      VERIFY_USE_PLATFORM_KEYRING,
-				      VERIFYING_MODULE_SIGNATURE,
-				      NULL, NULL);
+	ret = verify_pkcs7_signature(kernel, kernel_len,
+				     kernel + kernel_len, sig_len,
+				     VERIFY_USE_SECONDARY_KEYRING,
+				     VERIFYING_MODULE_SIGNATURE,
+				     NULL, NULL);
+	if (ret == -ENOKEY && IS_ENABLED(CONFIG_INTEGRITY_PLATFORM_KEYRING))
+		ret = verify_pkcs7_signature(kernel, kernel_len,
+					     kernel + kernel_len, sig_len,
+					     VERIFY_USE_PLATFORM_KEYRING,
+					     VERIFYING_MODULE_SIGNATURE,
+					     NULL, NULL);
+	return ret;
 }
 #endif /* CONFIG_KEXEC_SIG */
 
-- 
2.31.1

Re: [PATCH 3/4] kexec, KEYS, s390: Make use of built-in and secondary keyring for signature verification

[joeyli]

On Tue, Feb 15, 2022 at 08:39:40PM +0100, Michal Suchanek wrote:
> commit e23a8020ce4e ("s390/kexec_file: Signature verification prototype")
> adds support for KEXEC_SIG verification with keys from platform keyring
> but the built-in keys and secondary keyring are not used.
> 
> Add support for the built-in keys and secondary keyring as x86 does.
> 
> Fixes: e23a8020ce4e ("s390/kexec_file: Signature verification prototype")
> Cc: Philipp Rudo <prudo@linux.ibm.com>
> Cc: kexec@lists.infradead.org
> Cc: keyrings@vger.kernel.org
> Cc: linux-security-module@vger.kernel.org
> Cc: stable@kernel.org
> Signed-off-by: Michal Suchanek <msuchanek@suse.de>

Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>

> ---
>  arch/s390/kernel/machine_kexec_file.c | 18 +++++++++++++-----
>  1 file changed, 13 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/s390/kernel/machine_kexec_file.c b/arch/s390/kernel/machine_kexec_file.c
> index 8f43575a4dd3..fc6d5f58debe 100644
> --- a/arch/s390/kernel/machine_kexec_file.c
> +++ b/arch/s390/kernel/machine_kexec_file.c
> @@ -31,6 +31,7 @@ int s390_verify_sig(const char *kernel, unsigned long kernel_len)
>  	const unsigned long marker_len = sizeof(MODULE_SIG_STRING) - 1;
>  	struct module_signature *ms;
>  	unsigned long sig_len;
> +	int ret;
>  
>  	/* Skip signature verification when not secure IPLed. */
>  	if (!ipl_secure_flag)
> @@ -65,11 +66,18 @@ int s390_verify_sig(const char *kernel, unsigned long kernel_len)
>  		return -EBADMSG;
>  	}
>  
> -	return verify_pkcs7_signature(kernel, kernel_len,
> -				      kernel + kernel_len, sig_len,
> -				      VERIFY_USE_PLATFORM_KEYRING,
> -				      VERIFYING_MODULE_SIGNATURE,
> -				      NULL, NULL);
> +	ret = verify_pkcs7_signature(kernel, kernel_len,
> +				     kernel + kernel_len, sig_len,
> +				     VERIFY_USE_SECONDARY_KEYRING,
> +				     VERIFYING_MODULE_SIGNATURE,
> +				     NULL, NULL);
> +	if (ret == -ENOKEY && IS_ENABLED(CONFIG_INTEGRITY_PLATFORM_KEYRING))
> +		ret = verify_pkcs7_signature(kernel, kernel_len,
> +					     kernel + kernel_len, sig_len,
> +					     VERIFY_USE_PLATFORM_KEYRING,
> +					     VERIFYING_MODULE_SIGNATURE,
> +					     NULL, NULL);
> +	return ret;
>  }
>  #endif /* CONFIG_KEXEC_SIG */
>  
> -- 
> 2.31.1

[PATCH 4/4] module, KEYS: Make use of platform keyring for signature verification

[Michal Suchanek]

Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify")
adds support for use of platform keyring in kexec verification but
support for modules is missing.

Add support for verification of modules with keys from platform keyring
as well.

Fixes: 219a3e8676f3 ("integrity, KEYS: add a reference to platform keyring")
Cc: linux-modules@vger.kernel.org
Cc: keyrings@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
Cc: stable@kernel.org
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
---
 kernel/module_signing.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/kernel/module_signing.c b/kernel/module_signing.c
index 8723ae70ea1f..5e1624294874 100644
--- a/kernel/module_signing.c
+++ b/kernel/module_signing.c
@@ -38,8 +38,14 @@ int mod_verify_sig(const void *mod, struct load_info *info)
 	modlen -= sig_len + sizeof(ms);
 	info->len = modlen;
 
-	return verify_pkcs7_signature(mod, modlen, mod + modlen, sig_len,
-				      VERIFY_USE_SECONDARY_KEYRING,
-				      VERIFYING_MODULE_SIGNATURE,
-				      NULL, NULL);
+	ret = verify_pkcs7_signature(mod, modlen, mod + modlen, sig_len,
+				     VERIFY_USE_SECONDARY_KEYRING,
+				     VERIFYING_MODULE_SIGNATURE,
+				     NULL, NULL);
+	if (ret == -ENOKEY && IS_ENABLED(CONFIG_INTEGRITY_PLATFORM_KEYRING))
+		ret = verify_pkcs7_signature(mod, modlen, mod + modlen, sig_len,
+					     VERIFY_USE_PLATFORM_KEYRING,
+					     VERIFYING_MODULE_SIGNATURE,
+					     NULL, NULL);
+	return ret;
 }
-- 
2.31.1

Re: [PATCH 4/4] module, KEYS: Make use of platform keyring for signature verification

[Mimi Zohar]

[Cc'ing Eric Snowberg]

Hi Michal,

On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote:
> Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify")
> adds support for use of platform keyring in kexec verification but
> support for modules is missing.
> 
> Add support for verification of modules with keys from platform keyring
> as well.

Permission for loading the pre-OS keys onto the "platform" keyring and
using them is limited to verifying the kexec kernel image, nothing
else.

FYI, Eric Snowberg's initial patch set titled "[PATCH v10 0/8] Enroll
kernel keys thru MOK" is queued in Jarkko's git repo to be usptreamed. 
A subsequent patch set is expected.

-- 
thanks,

Mimi

[1] Message-Id: <20211124044124.998170-11-eric.snowberg@oracle.com>

Re: [PATCH 4/4] module, KEYS: Make use of platform keyring for signature verification

[Michal Suchánek]

Hello,

On Tue, Feb 15, 2022 at 03:08:18PM -0500, Mimi Zohar wrote:
> [Cc'ing Eric Snowberg]
> 
> Hi Michal,
> 
> On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote:
> > Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify")
> > adds support for use of platform keyring in kexec verification but
> > support for modules is missing.
> > 
> > Add support for verification of modules with keys from platform keyring
> > as well.
> 
> Permission for loading the pre-OS keys onto the "platform" keyring and
> using them is limited to verifying the kexec kernel image, nothing
> else.

Why is the platform keyring limited to kexec, and nothing else?

It should either be used for everything or for nothing. You have the
option to compile it in and then it should be used, and the option to
not compile it in and then it cannot be used.

There are two basic use cases:

(1) there is a vendor key which is very hard to use so you sign
something small and simple like shim with the vendor key, and sign your
kernel and modules with your own key that's typically enrolled with shim
MOK, and built into the kernel.

(2) you import your key into the firmware, and possibly disable the
vendor key. You can load the kernel directly without shim, and then your
signing key is typically in the platform keyring and built into the
kernel.

In neither case do I see any reason to use some keyrings for kexec and
other keyrings for modules.

Thanks

Michal

Re: [PATCH 4/4] module, KEYS: Make use of platform keyring for signature verification

[Mimi Zohar]

On Tue, 2022-02-15 at 21:47 +0100, Michal Suchánek wrote:
> Hello,
> 
> On Tue, Feb 15, 2022 at 03:08:18PM -0500, Mimi Zohar wrote:
> > [Cc'ing Eric Snowberg]
> > 
> > Hi Michal,
> > 
> > On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote:
> > > Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify")
> > > adds support for use of platform keyring in kexec verification but
> > > support for modules is missing.
> > > 
> > > Add support for verification of modules with keys from platform keyring
> > > as well.
> > 
> > Permission for loading the pre-OS keys onto the "platform" keyring and
> > using them is limited to verifying the kexec kernel image, nothing
> > else.
> 
> Why is the platform keyring limited to kexec, and nothing else?
> 
> It should either be used for everything or for nothing. You have the
> option to compile it in and then it should be used, and the option to
> not compile it in and then it cannot be used.
> 
> There are two basic use cases:
> 
> (1) there is a vendor key which is very hard to use so you sign
> something small and simple like shim with the vendor key, and sign your
> kernel and modules with your own key that's typically enrolled with shim
> MOK, and built into the kernel.
> 
> (2) you import your key into the firmware, and possibly disable the
> vendor key. You can load the kernel directly without shim, and then your
> signing key is typically in the platform keyring and built into the
> kernel.
> 
> In neither case do I see any reason to use some keyrings for kexec and
> other keyrings for modules.

When building your own kernel there isn't a problem.  Additional keys
may be built into the kernel image, which are loaded onto the
".builtin_trusted_keys" keyring, and may be stored in MOK.  Normally
different keys are used for signing the kernel image and kernel
modules.  Kernel modules can be signed by the build time ephemeral
kernel module signing key, which is built into the kernel and
automatically loaded onto the ".builtin_trusted_keys" keyring.
 
Similarly distros build the kernel module signing key into the kernel,
which is built into the kernel and loaded onto the
".builtin_trusted_keys" keyring.  By loading the pre-OS keys onto the
".platform" keyring,  kexec may verify the distro or other signed
kernel images.

-- 
thanks,

Mimi

Re: [PATCH 4/4] module, KEYS: Make use of platform keyring for signature verification

[Michal Suchánek]

On Tue, Feb 15, 2022 at 05:12:32PM -0500, Mimi Zohar wrote:
> On Tue, 2022-02-15 at 21:47 +0100, Michal Suchánek wrote:
> > Hello,
> > 
> > On Tue, Feb 15, 2022 at 03:08:18PM -0500, Mimi Zohar wrote:
> > > [Cc'ing Eric Snowberg]
> > > 
> > > Hi Michal,
> > > 
> > > On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote:
> > > > Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify")
> > > > adds support for use of platform keyring in kexec verification but
> > > > support for modules is missing.
> > > > 
> > > > Add support for verification of modules with keys from platform keyring
> > > > as well.
> > > 
> > > Permission for loading the pre-OS keys onto the "platform" keyring and
> > > using them is limited to verifying the kexec kernel image, nothing
> > > else.
> > 
> > Why is the platform keyring limited to kexec, and nothing else?
> > 
> > It should either be used for everything or for nothing. You have the
> > option to compile it in and then it should be used, and the option to
> > not compile it in and then it cannot be used.
> > 
> > There are two basic use cases:
> > 
> > (1) there is a vendor key which is very hard to use so you sign
> > something small and simple like shim with the vendor key, and sign your
> > kernel and modules with your own key that's typically enrolled with shim
> > MOK, and built into the kernel.
> > 
> > (2) you import your key into the firmware, and possibly disable the
> > vendor key. You can load the kernel directly without shim, and then your
> > signing key is typically in the platform keyring and built into the
> > kernel.
> > 
> > In neither case do I see any reason to use some keyrings for kexec and
> > other keyrings for modules.
> 
> When building your own kernel there isn't a problem.  Additional keys
> may be built into the kernel image, which are loaded onto the
> ".builtin_trusted_keys" keyring, and may be stored in MOK.  Normally
> different keys are used for signing the kernel image and kernel

That's actually not normal.

> modules.  Kernel modules can be signed by the build time ephemeral
> kernel module signing key, which is built into the kernel and
> automatically loaded onto the ".builtin_trusted_keys" keyring.

Right, there is this advice to use ephemeral key to sign modules.

I don't think that's a sound advice in general. It covers only the
special case when you build the kernel once, only rebuild the whole
kernel and never just one module, don't use any 3rd party module, don't
bother signing firmware (I am not sure that is supported right now but
if you are into integrity and stuff you can see that it makes sense to
sign it, too).

And you need to manage the key you use for the kernel signing, anyway.
Sure, you could use the same ephemeral key as for the modules, enroll
it, and shred it but then it is NOT a key different from the one you use
for modules.

Or you could maintain a long-lived key for the kernel, but if you do I
do NOT see any reason to not use it also for modules, in-tree and
out-of-tree.

> Similarly distros build the kernel module signing key into the kernel,
> which is built into the kernel and loaded onto the
> ".builtin_trusted_keys" keyring.  By loading the pre-OS keys onto the
> ".platform" keyring,  kexec may verify the distro or other signed
> kernel images.

Which are signed by the same key as the modules so there is no reason to
load the platform key at all. I don't think loading shim with kexec is
supported.

Thanks

Michal

Re: [PATCH 4/4] module, KEYS: Make use of platform keyring for signature verification

[Michal Suchánek]

On Wed, Feb 16, 2022 at 11:56:45AM +0100, Michal Suchánek wrote:
> On Tue, Feb 15, 2022 at 05:12:32PM -0500, Mimi Zohar wrote:
> > On Tue, 2022-02-15 at 21:47 +0100, Michal Suchánek wrote:
> > > Hello,
> > > 
> > > On Tue, Feb 15, 2022 at 03:08:18PM -0500, Mimi Zohar wrote:
> > > > [Cc'ing Eric Snowberg]
> > > > 
> > > > Hi Michal,
> > > > 
> > > > On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote:
> > > > > Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify")
> > > > > adds support for use of platform keyring in kexec verification but
> > > > > support for modules is missing.
> > > > > 
> > > > > Add support for verification of modules with keys from platform keyring
> > > > > as well.
> > > > 
> > > > Permission for loading the pre-OS keys onto the "platform" keyring and
> > > > using them is limited to verifying the kexec kernel image, nothing
> > > > else.
> > > 
> > > Why is the platform keyring limited to kexec, and nothing else?
> > > 
> > > It should either be used for everything or for nothing. You have the
> > > option to compile it in and then it should be used, and the option to
> > > not compile it in and then it cannot be used.
> > > 
> > > There are two basic use cases:
> > > 
> > > (1) there is a vendor key which is very hard to use so you sign
> > > something small and simple like shim with the vendor key, and sign your
> > > kernel and modules with your own key that's typically enrolled with shim
> > > MOK, and built into the kernel.
> > > 
> > > (2) you import your key into the firmware, and possibly disable the
> > > vendor key. You can load the kernel directly without shim, and then your
> > > signing key is typically in the platform keyring and built into the
> > > kernel.
> > > 
> > > In neither case do I see any reason to use some keyrings for kexec and
> > > other keyrings for modules.
> > 
> > When building your own kernel there isn't a problem.  Additional keys
> > may be built into the kernel image, which are loaded onto the
> > ".builtin_trusted_keys" keyring, and may be stored in MOK.  Normally
> > different keys are used for signing the kernel image and kernel
> 
> That's actually not normal.
> 
> > modules.  Kernel modules can be signed by the build time ephemeral
> > kernel module signing key, which is built into the kernel and
> > automatically loaded onto the ".builtin_trusted_keys" keyring.
> 
> Right, there is this advice to use ephemeral key to sign modules.
> 
> I don't think that's a sound advice in general. It covers only the
> special case when you build the kernel once, only rebuild the whole
> kernel and never just one module, don't use any 3rd party module, don't
> bother signing firmware (I am not sure that is supported right now but
> if you are into integrity and stuff you can see that it makes sense to
> sign it, too).
And don't forget signing ramdisk which you typically don't build only
once at kernel build time.
> 
> And you need to manage the key you use for the kernel signing, anyway.
> Sure, you could use the same ephemeral key as for the modules, enroll
> it, and shred it but then it is NOT a key different from the one you use
> for modules.
> 
> Or you could maintain a long-lived key for the kernel, but if you do I
> do NOT see any reason to not use it also for modules, in-tree and
> out-of-tree.
> 
> > Similarly distros build the kernel module signing key into the kernel,
> > which is built into the kernel and loaded onto the
> > ".builtin_trusted_keys" keyring.  By loading the pre-OS keys onto the
> > ".platform" keyring,  kexec may verify the distro or other signed
> > kernel images.
> 
> Which are signed by the same key as the modules so there is no reason to
> load the platform key at all. I don't think loading shim with kexec is
> supported.
> 
> Thanks
> 
> Michal

Re: [PATCH 4/4] module, KEYS: Make use of platform keyring for signature verification

[Mimi Zohar]

On Wed, 2022-02-16 at 11:56 +0100, Michal Suchánek wrote:
> On Tue, Feb 15, 2022 at 05:12:32PM -0500, Mimi Zohar wrote:
> > On Tue, 2022-02-15 at 21:47 +0100, Michal Suchánek wrote:
> > > Hello,
> > > 
> > > On Tue, Feb 15, 2022 at 03:08:18PM -0500, Mimi Zohar wrote:
> > > > [Cc'ing Eric Snowberg]
> > > > 
> > > > Hi Michal,
> > > > 
> > > > On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote:
> > > > > Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify")
> > > > > adds support for use of platform keyring in kexec verification but
> > > > > support for modules is missing.
> > > > > 
> > > > > Add support for verification of modules with keys from platform keyring
> > > > > as well.
> > > > 
> > > > Permission for loading the pre-OS keys onto the "platform" keyring and
> > > > using them is limited to verifying the kexec kernel image, nothing
> > > > else.
> > > 
> > > Why is the platform keyring limited to kexec, and nothing else?
> > > 
> > > It should either be used for everything or for nothing. You have the
> > > option to compile it in and then it should be used, and the option to
> > > not compile it in and then it cannot be used.
> > > 
> > > There are two basic use cases:
> > > 
> > > (1) there is a vendor key which is very hard to use so you sign
> > > something small and simple like shim with the vendor key, and sign your
> > > kernel and modules with your own key that's typically enrolled with shim
> > > MOK, and built into the kernel.
> > > 
> > > (2) you import your key into the firmware, and possibly disable the
> > > vendor key. You can load the kernel directly without shim, and then your
> > > signing key is typically in the platform keyring and built into the
> > > kernel.
> > > 
> > > In neither case do I see any reason to use some keyrings for kexec and
> > > other keyrings for modules.
> > 
> > When building your own kernel there isn't a problem.  Additional keys
> > may be built into the kernel image, which are loaded onto the
> > ".builtin_trusted_keys" keyring, and may be stored in MOK.  Normally
> > different keys are used for signing the kernel image and kernel
> 
> That's actually not normal.
> 
> > modules.  Kernel modules can be signed by the build time ephemeral
> > kernel module signing key, which is built into the kernel and
> > automatically loaded onto the ".builtin_trusted_keys" keyring.
> 
> Right, there is this advice to use ephemeral key to sign modules.
> 
> I don't think that's a sound advice in general. It covers only the
> special case when you build the kernel once, only rebuild the whole
> kernel and never just one module, don't use any 3rd party module, don't
> bother signing firmware (I am not sure that is supported right now but
> if you are into integrity and stuff you can see that it makes sense to
> sign it, too).
> 
> And you need to manage the key you use for the kernel signing, anyway.
> Sure, you could use the same ephemeral key as for the modules, enroll
> it, and shred it but then it is NOT a key different from the one you use
> for modules.
> 
> Or you could maintain a long-lived key for the kernel, but if you do I
> do NOT see any reason to not use it also for modules, in-tree and
> out-of-tree.

If signing ALL kernel modules, in-tree and out-of-tree, with the same
key as the kernel image, is your real intention, then by all means
write a complete patch description with the motivation for why kernel
module signatures need to be verified against this one pre-OS key
stored only in the platform keyring.  Such a major change like this
shouldn't be buried here.

Otherwise, I suggest looking at Eric Snowberg's "Enroll kernel keys
thru MOK patch set" patch set [1], as previously mentioned, which is
queued to be upstreamed by Jarkko.  It loads MOK keys onto the
'.machine' keyring, which is linked to the '.secondary_trusted_keys"
keyring.  A subsequent patch set will enable IMA support.

[1] 
https://lore.kernel.org/lkml/20220126025834.255493-1-eric.snowberg@oracle.com/
-- 
thanks,

Mimi

Re: [PATCH 4/4] module, KEYS: Make use of platform keyring for signature verification

[Michal Suchánek]

On Wed, Feb 16, 2022 at 06:58:51AM -0500, Mimi Zohar wrote:
> On Wed, 2022-02-16 at 11:56 +0100, Michal Suchánek wrote:
> > On Tue, Feb 15, 2022 at 05:12:32PM -0500, Mimi Zohar wrote:
> > > On Tue, 2022-02-15 at 21:47 +0100, Michal Suchánek wrote:
> > > > Hello,
> > > > 
> > > > On Tue, Feb 15, 2022 at 03:08:18PM -0500, Mimi Zohar wrote:
> > > > > [Cc'ing Eric Snowberg]
> > > > > 
> > > > > Hi Michal,
> > > > > 
> > > > > On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote:
> > > > > > Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify")
> > > > > > adds support for use of platform keyring in kexec verification but
> > > > > > support for modules is missing.
> > > > > > 
> > > > > > Add support for verification of modules with keys from platform keyring
> > > > > > as well.
> > > > > 
> > > > > Permission for loading the pre-OS keys onto the "platform" keyring and
> > > > > using them is limited to verifying the kexec kernel image, nothing
> > > > > else.
> > > > 
> > > > Why is the platform keyring limited to kexec, and nothing else?
> > > > 
> > > > It should either be used for everything or for nothing. You have the
> > > > option to compile it in and then it should be used, and the option to
> > > > not compile it in and then it cannot be used.
> > > > 
> > > > There are two basic use cases:
> > > > 
> > > > (1) there is a vendor key which is very hard to use so you sign
> > > > something small and simple like shim with the vendor key, and sign your
> > > > kernel and modules with your own key that's typically enrolled with shim
> > > > MOK, and built into the kernel.
> > > > 
> > > > (2) you import your key into the firmware, and possibly disable the
> > > > vendor key. You can load the kernel directly without shim, and then your
> > > > signing key is typically in the platform keyring and built into the
> > > > kernel.
> > > > 
> > > > In neither case do I see any reason to use some keyrings for kexec and
> > > > other keyrings for modules.
> > > 
> > > When building your own kernel there isn't a problem.  Additional keys
> > > may be built into the kernel image, which are loaded onto the
> > > ".builtin_trusted_keys" keyring, and may be stored in MOK.  Normally
> > > different keys are used for signing the kernel image and kernel
> > 
> > That's actually not normal.
> > 
> > > modules.  Kernel modules can be signed by the build time ephemeral
> > > kernel module signing key, which is built into the kernel and
> > > automatically loaded onto the ".builtin_trusted_keys" keyring.
> > 
> > Right, there is this advice to use ephemeral key to sign modules.
> > 
> > I don't think that's a sound advice in general. It covers only the
> > special case when you build the kernel once, only rebuild the whole
> > kernel and never just one module, don't use any 3rd party module, don't
> > bother signing firmware (I am not sure that is supported right now but
> > if you are into integrity and stuff you can see that it makes sense to
> > sign it, too).
> > 
> > And you need to manage the key you use for the kernel signing, anyway.
> > Sure, you could use the same ephemeral key as for the modules, enroll
> > it, and shred it but then it is NOT a key different from the one you use
> > for modules.
> > 
> > Or you could maintain a long-lived key for the kernel, but if you do I
> > do NOT see any reason to not use it also for modules, in-tree and
> > out-of-tree.
> 
> If signing ALL kernel modules, in-tree and out-of-tree, with the same
> key as the kernel image, is your real intention, then by all means

Why would you sign them with different keys, specifically?

For out of tree modules, sure. But that's an ADDITIONAL key, not
REMOVAL of a key.

> write a complete patch description with the motivation for why kernel
> module signatures need to be verified against this one pre-OS key
> stored only in the platform keyring.  Such a major change like this
> shouldn't be buried here.

No, in my book it does not make sense to verify anything against the
pre-os key at all in the common case.

However, if you do verify the kernel against the pre-os key it does not
make sense to not verify modules against the pre-os key. There is no
sense using different key for kernel and modules. They are both built in
the same environment with access to same the keys.

> Otherwise, I suggest looking at Eric Snowberg's "Enroll kernel keys
> thru MOK patch set" patch set [1], as previously mentioned, which is
> queued to be upstreamed by Jarkko.  It loads MOK keys onto the
> '.machine' keyring, which is linked to the '.secondary_trusted_keys"
> keyring.  A subsequent patch set will enable IMA support.

I don't really care how many keyrings there are. What I care about is
that they are used conssitently.

Thanks

Michal

Re: [PATCH 4/4] module, KEYS: Make use of platform keyring for signature verification

[Luis Chamberlain]

How's this series going? Did you and Mimi sort things out? Either way,
just wanted to let you kow you can base your changes on modules-testing
[0] if you want to resubmit for v5.19 (v5.18 will be too late already).
Once testing is done what is on modules-testing will go to modules-next
for testing for v5.19. There are no changes planned for v5.18 other than
fixes and so far there are none.

[0] https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git/log/?h=modules-testing

  Luis

Re: [PATCH 4/4] module, KEYS: Make use of platform keyring for signature verification

[Mimi Zohar]

Hi Luis,

On Tue, 2022-03-22 at 10:37 -0700, Luis Chamberlain wrote:
> How's this series going? Did you and Mimi sort things out? Either way,
> just wanted to let you kow you can base your changes on modules-testing
> [0] if you want to resubmit for v5.19 (v5.18 will be too late already).
> Once testing is done what is on modules-testing will go to modules-next
> for testing for v5.19. There are no changes planned for v5.18 other than
> fixes and so far there are none.
> 
> [0] https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git/log/?h=modules-testing

The "platform" keyring was upstreamed specifically to verify the kexec
kernel image. Orginally it contained only the UEFI db keys, but the MOK
keys were later added as well.  Any other usage of the "platform" is
not planned.

To allow end users to sign their own kernel modules, executables, or
any other file, Eric Snowberg is working on a patch set to only load
the MOK CA keys onto the ".machine" keyring, which is linked to the
"secondary" keyring[1].  Verifying kernel modules based on certificates
signed by a MOK CA will then be possible.

thanks,

Mimi

[1] 
https://lore.kernel.org/all/20220301173651.3435350-1-eric.snowberg@oracle.com/

Re: [PATCH 4/4] module, KEYS: Make use of platform keyring for signature verification

[joeyli]

Hi Mimi,

Sorry for bother you for this old topic.

On Tue, Feb 15, 2022 at 09:47:30PM +0100, Michal Suchánek wrote:
> Hello,
> 
> On Tue, Feb 15, 2022 at 03:08:18PM -0500, Mimi Zohar wrote:
> > [Cc'ing Eric Snowberg]
> > 
> > Hi Michal,
> > 
> > On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote:
> > > Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify")
> > > adds support for use of platform keyring in kexec verification but
> > > support for modules is missing.
> > > 
> > > Add support for verification of modules with keys from platform keyring
> > > as well.
> > 
> > Permission for loading the pre-OS keys onto the "platform" keyring and
> > using them is limited to verifying the kexec kernel image, nothing
> > else.
> 
> Why is the platform keyring limited to kexec, and nothing else?
> 
> It should either be used for everything or for nothing. You have the
> option to compile it in and then it should be used, and the option to
> not compile it in and then it cannot be used.
> 
> There are two basic use cases:
> 
> (1) there is a vendor key which is very hard to use so you sign
> something small and simple like shim with the vendor key, and sign your
> kernel and modules with your own key that's typically enrolled with shim
> MOK, and built into the kernel.
> 
> (2) you import your key into the firmware, and possibly disable the
> vendor key. You can load the kernel directly without shim, and then your
> signing key is typically in the platform keyring and built into the
> kernel.
>

In the second use case, if user can enroll their own key to db either before
or after hardware shipping. And they don't need shim because they removed
Microsoft or OEM/ODM keys.  Why kernel can not provide a Kconfig option to
them for trusting db keys for verifying kernel module, or for IMA (using CA
in db)?
 
In the above use case for distro, partner doesn't need to re-compiler distro
kernel. They just need to re-sign distro kernel and modules. Which means
that the partner trusted distro. Then the partner's key in db can be used to
verify kernel image and also kernel module without shim involve.

Regards
Joey Lee

Re: [PATCH 4/4] module, KEYS: Make use of platform keyring for signature verification

[Mimi Zohar]

On Mon, 2022-03-28 at 18:15 +0800, joeyli wrote:

Hi Joey,

> Hi Mimi,
> 
> Sorry for bother you for this old topic.

Cc'ing Luis the kernel modules maintainer.

> 
> On Tue, Feb 15, 2022 at 09:47:30PM +0100, Michal Suchánek wrote:
> > Hello,
> > 
> > On Tue, Feb 15, 2022 at 03:08:18PM -0500, Mimi Zohar wrote:
> > > [Cc'ing Eric Snowberg]
> > > 
> > > Hi Michal,
> > > 
> > > On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote:
> > > > Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify")
> > > > adds support for use of platform keyring in kexec verification but
> > > > support for modules is missing.
> > > > 
> > > > Add support for verification of modules with keys from platform keyring
> > > > as well.
> > > 
> > > Permission for loading the pre-OS keys onto the "platform" keyring and
> > > using them is limited to verifying the kexec kernel image, nothing
> > > else.
> > 
> > Why is the platform keyring limited to kexec, and nothing else?
> > 
> > It should either be used for everything or for nothing. You have the
> > option to compile it in and then it should be used, and the option to
> > not compile it in and then it cannot be used.
> > 
> > There are two basic use cases:
> > 
> > (1) there is a vendor key which is very hard to use so you sign
> > something small and simple like shim with the vendor key, and sign your
> > kernel and modules with your own key that's typically enrolled with shim
> > MOK, and built into the kernel.
> > 
> > (2) you import your key into the firmware, and possibly disable the
> > vendor key. You can load the kernel directly without shim, and then your
> > signing key is typically in the platform keyring and built into the
> > kernel.
> >
> 
> In the second use case, if user can enroll their own key to db either before
> or after hardware shipping. And they don't need shim because they removed
> Microsoft or OEM/ODM keys.  Why kernel can not provide a Kconfig option to
> them for trusting db keys for verifying kernel module, or for IMA (using CA
> in db)?
>  
> In the above use case for distro, partner doesn't need to re-compiler distro
> kernel. They just need to re-sign distro kernel and modules. Which means
> that the partner trusted distro. Then the partner's key in db can be used to
> verify kernel image and also kernel module without shim involve.

From what I understand, distros don't want customers resigning their
kernels.  If they did, then they could have enabled the
CONFIG_SYSTEM_EXTRA_CERTIFICATE, which would load the keys onto the
"builtin" keyring, and anything signed by those keys could be loaded
onto the secondary keyring.  (Of course CONFIG_SYSTEM_EXTRA_CERTIFICATE
would need to be fixed/updated.)

We've gone through "what if" scenarios before.  My response then, as
now, is post it as a patch with the real motivation for such a change.

thanks,

Mimi

Re: [PATCH 4/4] module, KEYS: Make use of platform keyring for signature verification

[Michal Suchánek]

Hello,

On Mon, Mar 28, 2022 at 09:28:14AM -0400, Mimi Zohar wrote:
> On Mon, 2022-03-28 at 18:15 +0800, joeyli wrote:
> 
> Hi Joey,
> 
> > Hi Mimi,
> > 
> > Sorry for bother you for this old topic.
> 
> Cc'ing Luis the kernel modules maintainer.
> 
> > 
> > On Tue, Feb 15, 2022 at 09:47:30PM +0100, Michal Suchánek wrote:
> > > Hello,
> > > 
> > > On Tue, Feb 15, 2022 at 03:08:18PM -0500, Mimi Zohar wrote:
> > > > [Cc'ing Eric Snowberg]
> > > > 
> > > > Hi Michal,
> > > > 
> > > > On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote:
> > > > > Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify")
> > > > > adds support for use of platform keyring in kexec verification but
> > > > > support for modules is missing.
> > > > > 
> > > > > Add support for verification of modules with keys from platform keyring
> > > > > as well.
> > > > 
> > > > Permission for loading the pre-OS keys onto the "platform" keyring and
> > > > using them is limited to verifying the kexec kernel image, nothing
> > > > else.
> > > 
> > > Why is the platform keyring limited to kexec, and nothing else?
> > > 
> > > It should either be used for everything or for nothing. You have the
> > > option to compile it in and then it should be used, and the option to
> > > not compile it in and then it cannot be used.
> > > 
> > > There are two basic use cases:
> > > 
> > > (1) there is a vendor key which is very hard to use so you sign
> > > something small and simple like shim with the vendor key, and sign your
> > > kernel and modules with your own key that's typically enrolled with shim
> > > MOK, and built into the kernel.
> > > 
> > > (2) you import your key into the firmware, and possibly disable the
> > > vendor key. You can load the kernel directly without shim, and then your
> > > signing key is typically in the platform keyring and built into the
> > > kernel.
> > >
> > 
> > In the second use case, if user can enroll their own key to db either before
> > or after hardware shipping. And they don't need shim because they removed
> > Microsoft or OEM/ODM keys.  Why kernel can not provide a Kconfig option to
> > them for trusting db keys for verifying kernel module, or for IMA (using CA
> > in db)?
> >  
> > In the above use case for distro, partner doesn't need to re-compiler distro
> > kernel. They just need to re-sign distro kernel and modules. Which means
> > that the partner trusted distro. Then the partner's key in db can be used to
> > verify kernel image and also kernel module without shim involve.
> 
> From what I understand, distros don't want customers resigning their
> kernels.  If they did, then they could have enabled the
> CONFIG_SYSTEM_EXTRA_CERTIFICATE, which would load the keys onto the
> "builtin" keyring, and anything signed by those keys could be loaded
> onto the secondary keyring.  (Of course CONFIG_SYSTEM_EXTRA_CERTIFICATE
> would need to be fixed/updated.)

You don't need to re-sign. You can just import the distro key into the
firmware.

> 
> We've gone through "what if" scenarios before.  My response then, as
> now, is post it as a patch with the real motivation for such a change.

Then that's what this does. Both modules and kernel run on ring0 so
there is no practical distinction. For consistency verify both with the
same keys.

Either way if there should be a disctinction it should be explicit, not
implicit.

That is each option that imports keys should crate a basic keyring that
just has keys, and we should have 'kexec' and 'module' keyrings that
do not have keys, only link the keyrings that import keys from some
specific source. All of them by default but you can adjust this in
defconfigs depending on platform-typical usage.

Contrast to that the current 'secondary' keyring that randomly links
some key sources and not others, is used in some kexec implementations
and not others. Also if you list the keys in it do you get the keys
dynamically added at runtime, or also all the keys on the linked
keyrings? Whatever you get is misleading and unclear.

Thanks

Michal

Re: [PATCH 4/4] module, KEYS: Make use of platform keyring for signature verification

[Eric Snowberg]

> On Mar 28, 2022, at 4:15 AM, joeyli <jlee@suse.com> wrote:
> 
> Hi Mimi,
> 
> Sorry for bother you for this old topic.
> 
> On Tue, Feb 15, 2022 at 09:47:30PM +0100, Michal Suchánek wrote:
>> Hello,
>> 
>> On Tue, Feb 15, 2022 at 03:08:18PM -0500, Mimi Zohar wrote:
>>> [Cc'ing Eric Snowberg]
>>> 
>>> Hi Michal,
>>> 
>>> On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote:
>>>> Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify")
>>>> adds support for use of platform keyring in kexec verification but
>>>> support for modules is missing.
>>>> 
>>>> Add support for verification of modules with keys from platform keyring
>>>> as well.
>>> 
>>> Permission for loading the pre-OS keys onto the "platform" keyring and
>>> using them is limited to verifying the kexec kernel image, nothing
>>> else.
>> 
>> Why is the platform keyring limited to kexec, and nothing else?
>> 
>> It should either be used for everything or for nothing. You have the
>> option to compile it in and then it should be used, and the option to
>> not compile it in and then it cannot be used.
>> 
>> There are two basic use cases:
>> 
>> (1) there is a vendor key which is very hard to use so you sign
>> something small and simple like shim with the vendor key, and sign your
>> kernel and modules with your own key that's typically enrolled with shim
>> MOK, and built into the kernel.
>> 
>> (2) you import your key into the firmware, and possibly disable the
>> vendor key. You can load the kernel directly without shim, and then your
>> signing key is typically in the platform keyring and built into the
>> kernel.
>> 
> 
> In the second use case, if user can enroll their own key to db either before
> or after hardware shipping. And they don't need shim because they removed
> Microsoft or OEM/ODM keys.  Why kernel can not provide a Kconfig option to
> them for trusting db keys for verifying kernel module, or for IMA (using CA
> in db)?
> 
> In the above use case for distro, partner doesn't need to re-compiler distro
> kernel. They just need to re-sign distro kernel and modules. Which means
> that the partner trusted distro. Then the partner's key in db can be used to
> verify kernel image and also kernel module without shim involve.

If shim is used, the new machine keyring can be used to solve this problem. 
This pull request [1] allows additional certificates to be loaded into the MOKList 
without going through MokManager.  Have the end-user/partner create a 
shim_certificate.efi containing their key. Then sign it with their DB key.  When 
shim boots, it will validate shim_certificate.efi against the DB key and load the 
key contained within it into the MOKList.  Now both module and kernel validation 
can be performed with this key, since it is contained within the machine keyring.

[1] https://github.com/rhboot/shim/pull/446

Re: [PATCH 4/4] module, KEYS: Make use of platform keyring for signature verification

[Michal Suchánek]

Hello,

On Mon, Mar 28, 2022 at 02:44:30PM +0000, Eric Snowberg wrote:
> 
> 
> > On Mar 28, 2022, at 4:15 AM, joeyli <jlee@suse.com> wrote:
> > 
> > Hi Mimi,
> > 
> > Sorry for bother you for this old topic.
> > 
> > On Tue, Feb 15, 2022 at 09:47:30PM +0100, Michal Suchánek wrote:
> >> Hello,
> >> 
> >> On Tue, Feb 15, 2022 at 03:08:18PM -0500, Mimi Zohar wrote:
> >>> [Cc'ing Eric Snowberg]
> >>> 
> >>> Hi Michal,
> >>> 
> >>> On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote:
> >>>> Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify")
> >>>> adds support for use of platform keyring in kexec verification but
> >>>> support for modules is missing.
> >>>> 
> >>>> Add support for verification of modules with keys from platform keyring
> >>>> as well.
> >>> 
> >>> Permission for loading the pre-OS keys onto the "platform" keyring and
> >>> using them is limited to verifying the kexec kernel image, nothing
> >>> else.
> >> 
> >> Why is the platform keyring limited to kexec, and nothing else?
> >> 
> >> It should either be used for everything or for nothing. You have the
> >> option to compile it in and then it should be used, and the option to
> >> not compile it in and then it cannot be used.
> >> 
> >> There are two basic use cases:
> >> 
> >> (1) there is a vendor key which is very hard to use so you sign
> >> something small and simple like shim with the vendor key, and sign your
> >> kernel and modules with your own key that's typically enrolled with shim
> >> MOK, and built into the kernel.
> >> 
> >> (2) you import your key into the firmware, and possibly disable the
> >> vendor key. You can load the kernel directly without shim, and then your
> >> signing key is typically in the platform keyring and built into the
> >> kernel.
> >> 
> > 
> > In the second use case, if user can enroll their own key to db either before
> > or after hardware shipping. And they don't need shim because they removed
> > Microsoft or OEM/ODM keys.  Why kernel can not provide a Kconfig option to
> > them for trusting db keys for verifying kernel module, or for IMA (using CA
> > in db)?
> > 
> > In the above use case for distro, partner doesn't need to re-compiler distro
> > kernel. They just need to re-sign distro kernel and modules. Which means
> > that the partner trusted distro. Then the partner's key in db can be used to
> > verify kernel image and also kernel module without shim involve.
> 
> If shim is used, the new machine keyring can be used to solve this problem. 
> This pull request [1] allows additional certificates to be loaded into the MOKList 
> without going through MokManager.  Have the end-user/partner create a 
> shim_certificate.efi containing their key. Then sign it with their DB key.  When 
> shim boots, it will validate shim_certificate.efi against the DB key and load the 
> key contained within it into the MOKList.  Now both module and kernel validation 
> can be performed with this key, since it is contained within the machine keyring.

And why would you go through that when your platform keyring already has
the key and you don't need shim for anything? This sounds a lot like "I
have a hammer and all these look like nails" thinking.

Sure, there is use for the machine keyring in the case you need it and
have it regardless of the kernel making any use of it for anything.
Artifically adding it because the kernel fails to work with the platform
keyring sounds backwards, though.

Thanks

Michal