[PATCH v2 3/4] efi_capsule: Add a function to get the public key needed for capsule authentication

[AKASHI Takahiro <takahiro.akashi@linaro.org>]

Simon,

On Mon, Apr 12, 2021 at 08:35:25PM +0530, Sughosh Ganu wrote:
> Define a function which would be used in the scenario where the
> public key is stored on the platform's dtb. This dtb is concatenated
> with the u-boot binary during the build process. Platforms which have
> a different mechanism for getting the public key would define their
> own platform specific function under a different Kconfig symbol.
> 
> Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
> ---
> 
> Changes since V1:
> * Remove the weak function, and add the functionality to retrieve the
>   public key under the config symbol CONFIG_EFI_PKEY_DTB_EMBED.
> 
>  lib/efi_loader/efi_capsule.c | 43 +++++++++++++++++++++++++++++++-----
>  1 file changed, 38 insertions(+), 5 deletions(-)
> 
> diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
> index 2cc8f2dee0..d95e9377fe 100644
> --- a/lib/efi_loader/efi_capsule.c
> +++ b/lib/efi_loader/efi_capsule.c
> @@ -14,10 +14,13 @@
>  #include <mapmem.h>
>  #include <sort.h>
>  
> +#include <asm/global_data.h>
>  #include <crypto/pkcs7.h>
>  #include <crypto/pkcs7_parser.h>
>  #include <linux/err.h>
>  
> +DECLARE_GLOBAL_DATA_PTR;
> +
>  const efi_guid_t efi_guid_capsule_report = EFI_CAPSULE_REPORT_GUID;
>  static const efi_guid_t efi_guid_firmware_management_capsule_id =
>  		EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID;
> @@ -208,15 +211,45 @@ skip:
>  const efi_guid_t efi_guid_capsule_root_cert_guid =
>  	EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID;
>  
> -__weak int efi_get_public_key_data(void **pkey, efi_uintn_t *pkey_len)
> +#if defined(CONFIG_EFI_PKEY_DTB_EMBED)
> +int efi_get_public_key_data(void **pkey, efi_uintn_t *pkey_len)
>  {
> -	/* The platform is supposed to provide
> -	 * a method for getting the public key
> -	 * stored in the form of efi signature
> -	 * list
> +	/*
> +	 * This is a function for retrieving the public key from the
> +	 * platform's device tree. The platform's device tree has been
> +	 * concatenated with the u-boot binary.
> +	 * If a platform has a different mechanism to get the public
> +	 * key, it can define it's own kconfig symbol and define a
> +	 * function to retrieve the public key
>  	 */
> +	const void *fdt_blob = gd->fdt_blob;
> +	const void *blob;
> +	const char *cnode_name = "capsule-key";
> +	const char *snode_name = "signature";

# Again, "key" is not the best word to describe the value.

The syntax assumed here in a device tree (control FDT) is;
/ {
   signature {
       capsule-key = "...";
   };
   ...
};

"signature" node is already used as a directory to hold public keys
for FIT image verification (vboot).
(doc/uImage.FIT/signature.txt)

While it is unlikely that both EFI capsule authentication and
FIT image authentication are enabled at the same time, I'm a bit
concerned if the mixture of different contents might cause
some confusion.
For instance, "required-mode" which has nothing to do with UEFI capsule
may exist directly under "signagture."

Do you have any thoughts?

-Takahiro Akashi

> +	int sig_node;
> +	int len;
> +
> +	sig_node = fdt_subnode_offset(fdt_blob, 0, snode_name);
> +	if (sig_node < 0) {
> +		EFI_PRINT("Unable to get signature node offset\n");
> +		return -FDT_ERR_NOTFOUND;
> +	}
> +
> +	blob = fdt_getprop(fdt_blob, sig_node, cnode_name, &len);
> +
> +	if (!blob || len < 0) {
> +		EFI_PRINT("Unable to get capsule-key value\n");
> +		*pkey = NULL;
> +		*pkey_len = 0;
> +		return -FDT_ERR_NOTFOUND;
> +	}
> +
> +	*pkey = (void *)blob;
> +	*pkey_len = len;
> +
>  	return 0;
>  }
> +#endif /* CONFIG_EFI_PKEY_DTB_EMBED */
>  
>  efi_status_t efi_capsule_authenticate(const void *capsule, efi_uintn_t capsule_size,
>  				      void **image, efi_uintn_t *image_size)
> -- 
> 2.17.1
>