All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
To: Masahisa Kojima <masahisa.kojima@linaro.org>
Cc: u-boot@lists.denx.de, Heinrich Schuchardt <xypron.glpk@gmx.de>,
	Simon Glass <sjg@chromium.org>,
	Takahiro Akashi <takahiro.akashi@linaro.org>
Subject: Re: [PATCH v6 2/8] efi_loader: store firmware version into FmpState variable
Date: Tue, 23 May 2023 00:24:24 +0300	[thread overview]
Message-ID: <ZGvdiPTlTDgu0aR+@hera> (raw)
In-Reply-To: <20230519103214.1239656-3-masahisa.kojima@linaro.org>

Hi Kojima-san,

On Fri, May 19, 2023 at 07:32:08PM +0900, Masahisa Kojima wrote:
> Firmware version management is not implemented in the current
> FMP protocol.
> EDK II reference implementation capsule generation script inserts
> the FMP Payload Header right before the payload, FMP Payload Header
> contains the firmware version and lowest supported version.
>
> This commit utilizes the FMP Payload Header, reads the header and
> stores the firmware version into "FmpStateXXXX" EFI non-volatile variable.
> XXXX indicates the image index, since FMP protocol handles multiple
> image indexes.
> Note that lowest supported version included in the FMP Payload Header
> is not used. If the platform uses file-based EFI variable storage,
> it can be tampered. The file-based EFI variable storage is not the
> right place to store the lowest supported version for anti-rollback
> protection.
>
> This change is compatible with the existing FMP implementation.
> This change does not mandate the FMP Payload Header.
> If no FMP Payload Header is found in the capsule file, fw_version,
> lowest supported version, last attempt version and last attempt
> status is 0 and this is the same behavior as existing FMP
> implementation.
>
> Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
> ---
> Changed in v6:
> - only store the fw_version in the FmpState EFI variable
>
> Changes in v4:
> - move lines that are the same in both branches out of the if statement
> - s/EDK2/EDK II/
> - create print result function
> - set last_attempt_version when capsule authentication failed
> - use log_err() instead of printf()
>
> Changes in v3:
> - exclude CONFIG_FWU_MULTI_BANK_UPDATE case
> - set image_type_id as a vendor field of FmpStateXXXX variable
> - set READ_ONLY flag for FmpStateXXXX variable
> - add error code for FIT image case
>
> Changes in v2:
> - modify indent
>

[...]

> +/**
> + * efi_firmware_get_fw_version - get fw_version from FMP payload header
> + * @p_image:		Pointer to new image
> + * @p_image_size:	Pointer to size of new image
> + * @state		Pointer to fmp state
> + *
> + * Parse the FMP payload header and fill the fmp_state structure.
> + * If no FMP payload header is found, fmp_state structure is not updated.
> + *
> + */
> +static void efi_firmware_get_fw_version(const void **p_image,
> +					efi_uintn_t *p_image_size,
> +					struct fmp_state *state)
> +{
> +	const void *image = *p_image;
> +	efi_uintn_t image_size = *p_image_size;
> +	const struct fmp_payload_header *header;
> +	u32 fmp_hdr_signature = FMP_PAYLOAD_HDR_SIGNATURE;
> +
> +	header = image;
> +	if (header->signature == fmp_hdr_signature) {
> +		/* FMP header is inserted above the capsule payload */
> +		state->fw_version = header->fw_version;
>
> -	if (!memcmp(&header->signature, &fmp_hdr_signature,
> -		    sizeof(fmp_hdr_signature))) {
> -		/*
> -		 * When building the capsule with the scripts in
> -		 * edk2, a FMP header is inserted above the capsule
> -		 * payload. Compensate for this header to get the
> -		 * actual payload that is to be updated.
> -		 */
>  		image += header->header_size;
>  		image_size -= header->header_size;
>  	}

>
>  	*p_image = image;
>  	*p_image_size = image_size;

Can we get rid of the extra image/image_size here and move this inside the
if()?

> -	return EFI_SUCCESS;
> +}
> +
> +/**
> + * efi_firmware_verify_image - verify image

The name is a bit generic here, we need something which describes what
happens better.  The verification already happens in
efi_firmware_capsule_authenticate().
Maybe efi_prepare_capsule() or something like that ?

> + * @p_image:		Pointer to new image
> + * @p_image_size:	Pointer to size of new image
> + * @image_index		Image index
> + * @state		Pointer to fmp state
> + *
> + * Verify the capsule file
> + *
> + * Return:		status code
> + */
> +static
> +efi_status_t efi_firmware_verify_image(const void **p_image,
> +				       efi_uintn_t *p_image_size,
> +				       u8 image_index,
> +				       struct fmp_state *state)
> +{
> +	efi_status_t ret;
> +
> +	ret = efi_firmware_capsule_authenticate(p_image, p_image_size);
> +	efi_firmware_get_fw_version(p_image, p_image_size, state);
> +
> +	return ret;
>  }
>
>  /**
> @@ -331,6 +454,7 @@ efi_status_t EFIAPI efi_firmware_fit_set_image(
>  	u16 **abort_reason)
>  {
>  	efi_status_t status;
> +	struct fmp_state state = { 0 };
>
>  	EFI_ENTRY("%p %d %p %zu %p %p %p\n", this, image_index, image,
>  		  image_size, vendor_code, progress, abort_reason);
> @@ -338,13 +462,16 @@ efi_status_t EFIAPI efi_firmware_fit_set_image(
>  	if (!image || image_index != 1)
>  		return EFI_EXIT(EFI_INVALID_PARAMETER);
>
> -	status = efi_firmware_capsule_authenticate(&image, &image_size);
> +	status = efi_firmware_verify_image(&image, &image_size, image_index,
> +					   &state);
>  	if (status != EFI_SUCCESS)
>  		return EFI_EXIT(status);
>
>  	if (fit_update(image))
>  		return EFI_EXIT(EFI_DEVICE_ERROR);
>
> +	efi_firmware_set_fmp_state_var(&state, image_index);
> +
>  	return EFI_EXIT(EFI_SUCCESS);
>  }
>
> @@ -392,6 +519,7 @@ efi_status_t EFIAPI efi_firmware_raw_set_image(
>  {
>  	int ret;
>  	efi_status_t status;
> +	struct fmp_state state = { 0 };
>
>  	EFI_ENTRY("%p %d %p %zu %p %p %p\n", this, image_index, image,
>  		  image_size, vendor_code, progress, abort_reason);
> @@ -399,7 +527,8 @@ efi_status_t EFIAPI efi_firmware_raw_set_image(
>  	if (!image)
>  		return EFI_EXIT(EFI_INVALID_PARAMETER);
>
> -	status = efi_firmware_capsule_authenticate(&image, &image_size);
> +	status = efi_firmware_verify_image(&image, &image_size, image_index,
> +					   &state);
>  	if (status != EFI_SUCCESS)
>  		return EFI_EXIT(status);
>
> @@ -419,6 +548,8 @@ efi_status_t EFIAPI efi_firmware_raw_set_image(
>  			     NULL, NULL))
>  		return EFI_EXIT(EFI_DEVICE_ERROR);
>
> +	efi_firmware_set_fmp_state_var(&state, image_index);
> +
>  	return EFI_EXIT(EFI_SUCCESS);
>  }
>
> --
> 2.17.1
>

Thanks
/Ilias

  reply	other threads:[~2023-05-22 21:24 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-19 10:32 [PATCH v6 0/8] FMP versioning support Masahisa Kojima
2023-05-19 10:32 ` [PATCH v6 1/8] efi_loader: add the number of image entries in efi_capsule_update_info Masahisa Kojima
2023-05-22  7:34   ` Ilias Apalodimas
2023-05-22 20:42   ` Ilias Apalodimas
2023-05-19 10:32 ` [PATCH v6 2/8] efi_loader: store firmware version into FmpState variable Masahisa Kojima
2023-05-22 21:24   ` Ilias Apalodimas [this message]
2023-05-23  1:55     ` Masahisa Kojima
2023-05-28  8:39   ` Heinrich Schuchardt
2023-05-30  0:31     ` Masahisa Kojima
2023-05-19 10:32 ` [PATCH v6 3/8] efi_loader: versioning support in GetImageInfo Masahisa Kojima
2023-05-22 21:29   ` Ilias Apalodimas
2023-05-19 10:32 ` [PATCH v6 4/8] efi_loader: get lowest supported version from device tree Masahisa Kojima
2023-05-22 21:33   ` Ilias Apalodimas
2023-05-19 10:32 ` [PATCH v6 5/8] efi_loader: check lowest supported version Masahisa Kojima
2023-05-22 21:36   ` Ilias Apalodimas
2023-05-23  1:56     ` Masahisa Kojima
2023-05-19 10:32 ` [PATCH v6 6/8] mkeficapsule: add FMP Payload Header Masahisa Kojima
2023-05-22 21:29   ` Ilias Apalodimas
2023-05-19 10:32 ` [PATCH v6 7/8] doc: uefi: add firmware versioning documentation Masahisa Kojima
2023-05-22  0:35   ` Takahiro Akashi
2023-05-22  4:25     ` Masahisa Kojima
2023-05-19 10:32 ` [PATCH v6 8/8] doc: uefi: add anti-rollback documentation Masahisa Kojima
2023-05-22  0:27   ` Takahiro Akashi
2023-05-22  4:30     ` Masahisa Kojima
2023-05-22  4:32 ` [PATCH v6 0/8] FMP versioning support Masahisa Kojima
2023-05-28  8:54 ` Heinrich Schuchardt
2023-05-30  0:32   ` Masahisa Kojima

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZGvdiPTlTDgu0aR+@hera \
    --to=ilias.apalodimas@linaro.org \
    --cc=masahisa.kojima@linaro.org \
    --cc=sjg@chromium.org \
    --cc=takahiro.akashi@linaro.org \
    --cc=u-boot@lists.denx.de \
    --cc=xypron.glpk@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.