hello Heinrich,

On Sat, 5 Dec 2020 at 15:01, Heinrich Schuchardt xypron.glpk@gmx.de wrote:

On 11/26/20 7:40 PM, Sughosh Ganu wrote:

...

The Qemu platform emulator generates a device tree blob and places it at the start of the dram, which is then used by u-boot. Use this dtb only if CONFIG_OF_BOARD is defined. This allows using a different device tree, using the CONFIG_OF_SEPARATE option. This dtb is attached to the u-boot binary as a u-boot-fdt.bin file

Dear Sughosh,

thank your for this series which will allow us to better demonstrate and test capsule updates.

I am not sure if the approach that you take at device-trees here is the right one.

On QEMU the device-tree is generated on the fly by the QEMU binary depending on which devices the user has specified.

Your idea is to replace this device-tree completely to be able to add extra elements (the EFI signature list, see patch 2/14). Thus a device-tree might be loaded that does not match the user selected devices.

An alternative approach would be to apply all additions to the device-tree as an FDT overlay (or fixup). This would allow the dynamic parts of the QEMU device-tree still to be passed through.

I will take a look at storing the public key as part of the fdt overlay, with a runtime fixup. Although, I think the issue that you are pointing to would be specific to Qemu and not other platforms. But I do see the merit in having the public-key certificate stored as part of an overlay. If I hit any issues while implementing this, I will get back to you. Thanks.

-sughosh

Could you, please, assess the pros and cons of the two approaches with respect to:

• usability for capsule updates
• applicability for non-QEMU systems
• integration of DTB overlays with FIT images for other use cases

Best regards

Heinrich

...

Signed-off-by: Sughosh Ganu sughosh.ganu@linaro.org

board/emulation/qemu-arm/qemu-arm.c | 2 ++ 1 file changed, 2 insertions(+)

diff --git a/board/emulation/qemu-arm/qemu-arm.c

b/board/emulation/qemu-arm/qemu-arm.c

...

index f18f2ed7da..e146d1cc50 100644 --- a/board/emulation/qemu-arm/qemu-arm.c +++ b/board/emulation/qemu-arm/qemu-arm.c @@ -89,11 +89,13 @@ int dram_init_banksize(void) return 0; }

+#if defined(CONFIG_OF_BOARD) void *board_fdt_blob_setup(void) { /* QEMU loads a generated DTB for us at the start of RAM. */ return (void *)CONFIG_SYS_SDRAM_BASE; } +#endif

void enable_caches(void) {

On 07.12.20 13:50, Heinrich Schuchardt wrote:

On 07.12.20 06:15, Sughosh Ganu wrote:

...

hello Heinrich,

On Sat, 5 Dec 2020 at 15:01, Heinrich Schuchardt <xypron.glpk@gmx.de mailto:xypron.glpk@gmx.de> wrote:

On 11/26/20 7:40 PM, Sughosh Ganu wrote:
> The Qemu platform emulator generates a device tree blob and places it
> at the start of the dram, which is then used by u-boot. Use this dtb
> only if CONFIG_OF_BOARD is defined. This allows using a different
> device tree, using the CONFIG_OF_SEPARATE option. This dtb is attached
> to the u-boot binary as a u-boot-fdt.bin file

Dear Sughosh,

thank your for this series which will allow us to better demonstrate and
test capsule updates.

I am not sure if the approach that you take at device-trees here is the
right one.

On QEMU the device-tree is generated on the fly by the QEMU binary
depending on which devices the user has specified.

Your idea is to replace this device-tree completely to be able to add
extra elements (the EFI signature list, see patch 2/14). Thus a
device-tree might be loaded that does not match the user selected
devices.

An alternative approach would be to apply all additions to the
device-tree as an FDT overlay (or fixup). This would allow the dynamic
parts of the QEMU device-tree still to be passed through.

I will take a look at storing the public key as part of the fdt overlay, with a runtime fixup. Although, I think the issue that you are pointing to would be specific to Qemu and not other platforms. But I do see the merit in having the public-key certificate stored as part of an overlay. If I hit any issues while implementing this, I will get back to you. Thanks.

-sughosh

OpenSBI can supply a device-tree to U-Boot. So this would be an equivalent case.

Best regards

Heinrich

<sng_>: "I am unable to think of a simple and elegant way to generate the overlay dtb, since this would require creation of a corresponding dts file, compiling it into a dtb and then using this on the platform."

Jean-Jacques' patch series introduced some of the necessary code:

[PATCH PATCH v6 00/13] Add support for applications of overlays in SPL https://lists.denx.de/pipermail/u-boot/2019-October/387653.html https://patchwork.ozlabs.org/project/uboot/list/?series=137810&state=%2A...

CONFIG_OF_OVERLAY_LIST is used to specify the overlays to be compiled. You will have to remove the CONFIG_SPL_LOAD_FIT_APPLY_OVERLAY and CONFIG_SPL_LOAD_FIT dependency.

Best regards

Heinrich

...

Could you, please, assess the pros and cons of the two approaches with
respect to:

* usability for capsule updates
* applicability for non-QEMU systems
* integration of DTB overlays with FIT images for other use cases

Best regards

Heinrich


>
> Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org
<mailto:sughosh.ganu@linaro.org>>
> ---
>   board/emulation/qemu-arm/qemu-arm.c | 2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/board/emulation/qemu-arm/qemu-arm.c
b/board/emulation/qemu-arm/qemu-arm.c
> index f18f2ed7da..e146d1cc50 100644
> --- a/board/emulation/qemu-arm/qemu-arm.c
> +++ b/board/emulation/qemu-arm/qemu-arm.c
> @@ -89,11 +89,13 @@ int dram_init_banksize(void)
>       return 0;
>   }
>
> +#if defined(CONFIG_OF_BOARD)
>   void *board_fdt_blob_setup(void)
>   {
>       /* QEMU loads a generated DTB for us at the start of RAM. */
>       return (void *)CONFIG_SYS_SDRAM_BASE;
>   }
> +#endif
>
>   void enable_caches(void)
>   {
>

On Sat, 5 Dec 2020 at 15:15, Heinrich Schuchardt xypron.glpk@gmx.de wrote:

On 11/26/20 7:40 PM, Sughosh Ganu wrote:

...

Scan the pci bus in board_init routine before scanning the virtio devices. This enumerates all the virtio devices, including devices found on the pci bus.

Signed-off-by: Sughosh Ganu sughosh.ganu@linaro.org

board/emulation/qemu-arm/qemu-arm.c | 8 ++++++++ 1 file changed, 8 insertions(+)

diff --git a/board/emulation/qemu-arm/qemu-arm.c

b/board/emulation/qemu-arm/qemu-arm.c

...

index e146d1cc50..b3d5b3d5c2 100644 --- a/board/emulation/qemu-arm/qemu-arm.c +++ b/board/emulation/qemu-arm/qemu-arm.c @@ -65,6 +65,14 @@ struct mm_region *mem_map = qemu_arm64_mem_map;

int board_init(void) {

• /*
  

•  * Scan the pci bus before calling virtio_init. This
  

•  * enumerates all virtio devices, including devices
  

•  * on the pci bus.
  

•  */
  

• pci_init();
  

This does not compile if CONFIG_PCI=n.

aarch64-linux-gnu-ld.bfd: board/emulation/qemu-arm/built-in.o: in function `board_init': board/emulation/qemu-arm/qemu-arm.c:74: undefined reference to `pci_init'

Cf. arch/arm/mach-mvebu/arm64-common.c-106-#ifdef CONFIG_DM_PCI board/socrates/socrates.c-134-#if defined(CONFIG_DM_PCI)

I found these lines in common/board_r.c:250

#ifdef CONFIG_PCI static int initr_pci(void) { if (IS_ENABLED(CONFIG_PCI_INIT_R)) pci_init();

     return 0;

} #endif

Would selecting CONFIG_PCI_INIT_R be enough to solve your problem?

Will check this out. Thanks.

-sughosh

On 11/26/20 7:41 PM, Sughosh Ganu wrote:

RFC 2315 Section 9.3 describes the message digesting process. The digest calculated depends on whether the authenticated attributes are present. In case of a scenario where the authenticated attributes are present, the message digest that gets signed and is part of the pkcs7 message is computed from the auth attributes rather than the contents field.

Check if the auth attributes are present, and if set, use the auth attributes to compute the hash that would be compared with the encrypted hash on the pkcs7 message.

Signed-off-by: Sughosh Ganu sughosh.ganu@linaro.org

Dear Takahiro,

Could you, please, review this patch.

Best regards

Heinrich

---

lib/crypto/pkcs7_verify.c | 37 ++++++++++++++++++++++++++----------- 1 file changed, 26 insertions(+), 11 deletions(-)

diff --git a/lib/crypto/pkcs7_verify.c b/lib/crypto/pkcs7_verify.c index 320ba49f79..58683ef614 100644 --- a/lib/crypto/pkcs7_verify.c +++ b/lib/crypto/pkcs7_verify.c @@ -50,8 +50,15 @@ static int pkcs7_digest(struct pkcs7_message *pkcs7, struct image_region regions[2]; int ret = 0;

• /* The digest was calculated already. */
• if (sig->digest)

• /*

• * [RFC2315 9.3]
  

• * If the authenticated attributes are present,
  

• * the message-digest is calculated on the
  

• * attributes present in the
  

• * authenticatedAttributes field and not just
  

• * the contents field
  

• */
  

• if (!sinfo->authattrs && sig->digest) return 0;

  if (!sinfo->sig->hash_algo)

@@ -63,17 +70,25 @@ static int pkcs7_digest(struct pkcs7_message *pkcs7, else return -ENOPKG;

• sig->digest = calloc(1, sig->digest_size);
• if (!sig->digest) {

• pr_warn("Sig %u: Out of memory\n", sinfo->index);
  

• return -ENOMEM;
  

• }

• /*

• * Calculate the hash only if the data is present.
  

• * In case of authenticated variable and capsule,
  

• * the hash has already been calculated on the
  

• * efi_image_regions and populated
  

• */
  

• if (pkcs7->data) {

• sig->digest = calloc(1, sig->digest_size);
  

• if (!sig->digest) {
  

• 	pr_warn("Sig %u: Out of memory\n", sinfo->index);
  

• 	return -ENOMEM;
  

• }
  
  

• regions[0].data = pkcs7->data;
• regions[0].size = pkcs7->data_len;

• regions[0].data = pkcs7->data;
  

• regions[0].size = pkcs7->data_len;
  
  

• /* Digest the message [RFC2315 9.3] */
• hash_calculate(sinfo->sig->hash_algo, regions, 1, sig->digest);

• /* Digest the message [RFC2315 9.3] */
  

• hash_calculate(sinfo->sig->hash_algo, regions, 1, sig->digest);
  

• }

  /* However, if there are authenticated attributes, there must be a

  • message digest attribute amongst them which corresponds to the

On 11/26/20 7:41 PM, Sughosh Ganu wrote:

Add support for setting the default values for mtd partitions on the platform for the nor flash. This would be used for updating the firmware image using uefi capsule update with the dfu mtd backend driver.

Signed-off-by: Sughosh Ganu sughosh.ganu@linaro.org

board/emulation/qemu-arm/qemu-arm.c | 70 +++++++++++++++++++++++++++++ include/configs/qemu-arm.h | 7 +++ 2 files changed, 77 insertions(+)

diff --git a/board/emulation/qemu-arm/qemu-arm.c b/board/emulation/qemu-arm/qemu-arm.c index b3d5b3d5c2..d5ed3eebaf 100644 --- a/board/emulation/qemu-arm/qemu-arm.c +++ b/board/emulation/qemu-arm/qemu-arm.c

Is this development really QEMU specific or is it something we would could reuse for other systems too? If yes, we should put it into another directory (drivers/mtd/ or drivers/dfu/).

Best regards

Heinrich

@@ -197,3 +197,73 @@ void flash_write32(u32 value, void *addr) { asm("str %" __W "1, %0" : "=m"(*(u32 *)addr) : "r"(value)); }

+#if defined(CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT)

+#include <mtd.h>

+static void board_get_mtdparts(const char *dev, const char *partition,

• 	       char *mtdids, char *mtdparts)
  

+{

• /* mtdids: "<dev>=<dev>, ...." */
• if (mtdids[0] != '\0')

• strcat(mtdids, ",");
  

• strcat(mtdids, dev);
• strcat(mtdids, "=");
• strcat(mtdids, dev);
• /* mtdparts: "mtdparts=<dev>:<mtdparts_<dev>>;..." */
• if (mtdparts[0] != '\0')

• strncat(mtdparts, ";", MTDPARTS_LEN);
  

• else

• strcat(mtdparts, "mtdparts=");
  

• strncat(mtdparts, dev, MTDPARTS_LEN);
• strncat(mtdparts, ":", MTDPARTS_LEN);
• strncat(mtdparts, partition, MTDPARTS_LEN);

+}

+void board_mtdparts_default(const char **mtdids, const char **mtdparts) +{

• struct mtd_info *mtd;
• struct udevice *dev;
• const char *mtd_partition;
• static char parts[3 * MTDPARTS_LEN + 1];
• static char ids[MTDIDS_LEN + 1];
• static bool mtd_initialized;
• if (mtd_initialized) {

• *mtdids = ids;
  

• *mtdparts = parts;
  

• return;
  

• }
• memset(parts, 0, sizeof(parts));
• memset(ids, 0, sizeof(ids));
• /* probe all MTD devices */
• for (uclass_first_device(UCLASS_MTD, &dev); dev;

•     uclass_next_device(&dev)) {
  

• debug("mtd device = %s\n", dev->name);
  

• }
• mtd = get_mtd_device_nm("nor0");
• if (!IS_ERR_OR_NULL(mtd)) {

• mtd_partition = MTDPARTS_NOR0;
  

• board_get_mtdparts("nor0", mtd_partition, ids, parts);
  

• put_mtd_device(mtd);
  

• }
• mtd = get_mtd_device_nm("nor1");
• if (!IS_ERR_OR_NULL(mtd)) {

• mtd_partition = MTDPARTS_NOR1;
  

• board_get_mtdparts("nor1", mtd_partition, ids, parts);
  

• put_mtd_device(mtd);
  

• }
• mtd_initialized = true;
• *mtdids = ids;
• *mtdparts = parts;
• debug("%s:mtdids=%s & mtdparts=%s\n", __func__, ids, parts);

+} +#endif /* CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT */ diff --git a/include/configs/qemu-arm.h b/include/configs/qemu-arm.h index 273fa1a7d7..69ff329434 100644 --- a/include/configs/qemu-arm.h +++ b/include/configs/qemu-arm.h @@ -32,6 +32,13 @@

#include <config_distro_bootcmd.h>

+#if defined(CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT) +#define CONFIG_SYS_MTDPARTS_RUNTIME +#endif

+#define MTDPARTS_NOR0 "64m(u-boot)\0" +#define MTDPARTS_NOR1 "64m(u-boot-env)\0"

• #define CONFIG_EXTRA_ENV_SETTINGS \ "fdt_high=0xffffffff\0" \ "initrd_high=0xffffffff\0" \

On Sat, 5 Dec 2020 at 16:01, Heinrich Schuchardt xypron.glpk@gmx.de wrote:

On 11/26/20 7:41 PM, Sughosh Ganu wrote:

...

The dfu framework uses the dfu_alt_info environment variable to get information that is needed for performing the firmware update. Set the dfu_alt_info for the platform to reflect the two mtd partitions created for the u-boot env and the firmware image.

Signed-off-by: Sughosh Ganu sughosh.ganu@linaro.org

I can't see anything QEMU specific in this patch. Why is the code under board/emulation/?

The device that the board wants to use to set the dfu_alt_info to would be very much board specific. For example, the dfu_alt_info is being set for the qemu platform for an mtd as the interface, with nor0 as the device. Different platforms might have different requirements, like the setting of the variable done for st platforms(board/st/common/stm32mp_dfu.c). I think this information is very much platform specific.

-sughosh

Best regards

Heinrich

...

---

board/emulation/qemu-arm/qemu-arm.c | 55 +++++++++++++++++++++++++++++ include/configs/qemu-arm.h | 1 + 2 files changed, 56 insertions(+)

diff --git a/board/emulation/qemu-arm/qemu-arm.c

b/board/emulation/qemu-arm/qemu-arm.c

...

index d5ed3eebaf..8cad54c76f 100644 --- a/board/emulation/qemu-arm/qemu-arm.c +++ b/board/emulation/qemu-arm/qemu-arm.c @@ -200,8 +200,63 @@ void flash_write32(u32 value, void *addr)

#if defined(CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT)

+#include <memalign.h> #include <mtd.h>

+#define MTDPARTS_LEN 256 +#define MTDIDS_LEN 128

+#define DFU_ALT_BUF_LEN SZ_1K

+static void board_get_alt_info(struct mtd_info *mtd, char *buf) +{

• struct mtd_info *part;
  

• bool first = true;
  

• const char *name;
  

• int len, partnum = 0;
  

• name = mtd->name;
  

• len = strlen(buf);
  

• if (buf[0] != '\0')
  

•         len += snprintf(buf + len, DFU_ALT_BUF_LEN - len, "&");
  

• len += snprintf(buf + len, DFU_ALT_BUF_LEN - len,
  

•                 "mtd %s=", name);
  

• list_for_each_entry(part, &mtd->partitions, node) {
  

•         partnum++;
  

•         if (!first)
  

•                 len += snprintf(buf + len, DFU_ALT_BUF_LEN - len,
  

";");

...

•         first = false;
  

•         len += snprintf(buf + len, DFU_ALT_BUF_LEN - len,
  

•                         "%s part %d",
  

•                         part->name, partnum);
  

• }
  

+}

+void set_dfu_alt_info(char *interface, char *devstr) +{

• struct mtd_info *mtd;
  

• ALLOC_CACHE_ALIGN_BUFFER(char, buf, DFU_ALT_BUF_LEN);
  

• if (env_get("dfu_alt_info"))
  

•         return;
  

• memset(buf, 0, sizeof(buf));
  

• /* probe all MTD devices */
  

• mtd_probe_devices();
  

• mtd = get_mtd_device_nm("nor0");
  

• if (!IS_ERR_OR_NULL(mtd))
  

•         board_get_alt_info(mtd, buf);
  

• env_set("dfu_alt_info", buf);
  

• printf("dfu_alt_info set\n");
  

+}

• static void board_get_mtdparts(const char *dev, const char *partition, char *mtdids, char *mtdparts) {

diff --git a/include/configs/qemu-arm.h b/include/configs/qemu-arm.h index 69ff329434..726f985d35 100644 --- a/include/configs/qemu-arm.h +++ b/include/configs/qemu-arm.h @@ -33,6 +33,7 @@ #include <config_distro_bootcmd.h>

#if defined(CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT) +#define CONFIG_SET_DFU_ALT_INFO #define CONFIG_SYS_MTDPARTS_RUNTIME #endif

On Mon, 7 Dec 2020 at 12:26, Heinrich Schuchardt xypron.glpk@gmx.de wrote:

On 12/7/20 6:42 AM, Sughosh Ganu wrote:

...

On Sat, 5 Dec 2020 at 16:01, Heinrich Schuchardt <xypron.glpk@gmx.de mailto:xypron.glpk@gmx.de> wrote:

On 11/26/20 7:41 PM, Sughosh Ganu wrote:
 > The dfu framework uses the dfu_alt_info environment variable to

get

...

 > information that is needed for performing the firmware update.
Set the
 > dfu_alt_info for the platform to reflect the two mtd partitions
 > created for the u-boot env and the firmware image.
 >
 > Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org
<mailto:sughosh.ganu@linaro.org>>

I can't see anything QEMU specific in this patch. Why is the code

under

...

board/emulation/?

The device that the board wants to use to set the dfu_alt_info to would be very much board specific. For example, the dfu_alt_info is being set for the qemu platform for an mtd as the interface, with nor0 as the device. Different platforms might have different requirements, like the setting of the variable done for st platforms(board/st/common/stm32mp_dfu.c). I think this information is very much platform specific.

In the function below you simply collect MTD partitions. Isn't this something that could be reused for other boards?

The function probes all mtd devices, but uses only the nor0 device for setting up of the dfu_alt_info variable. The other nor1 device is not used, since, on this platform configuration(non-secure boot), it has the u-boot environment. So which of the mtd devices to use for setting of the dfu_alt_info is very much platform specific.

On other boards (e.g. board/samsung/common/misc.c) CONFIG_SET_DFU_ALT_INFO controls if set_dfu_alt_info() exists. Should the same be done for QEMU ARM?

Yes, I can add a check for this on the lines that you mention. Will do.

Reading through patch 14/14 it is unclear to me how you control to which partition you write TF-A, SPL, U-Boot depending on which of these exists on the MTD device.

This gets added in patch 05/14. This sets the mtd partitions that are to be set for the platform. On this particular configuration of the platform(non-secure boot), the partition 1 is used for the u-boot image, and the partition 2 is used for the u-boot environment.

Wouldn't it make more sense to encode in the capsule to where it will be written?

We have discussed this earlier[1] that there is no way to encode the target device and partition information as part of the capsule, the way the capsule structure is defined by the uefi specification. That is the reason that it was decided to use the dfu backend for the update using the dfu_alt_info variable to indicate the partitions and device to be used for the update.

-sughosh

[1] - https://lists.denx.de/pipermail/u-boot/2020-May/411236.html

Best regards

Heinrich

...

-sughosh

Best regards

Heinrich

 > ---
 >   board/emulation/qemu-arm/qemu-arm.c | 55
+++++++++++++++++++++++++++++
 >   include/configs/qemu-arm.h          |  1 +
 >   2 files changed, 56 insertions(+)
 >
 > diff --git a/board/emulation/qemu-arm/qemu-arm.c
b/board/emulation/qemu-arm/qemu-arm.c
 > index d5ed3eebaf..8cad54c76f 100644
 > --- a/board/emulation/qemu-arm/qemu-arm.c
 > +++ b/board/emulation/qemu-arm/qemu-arm.c
 > @@ -200,8 +200,63 @@ void flash_write32(u32 value, void *addr)
 >
 >   #if defined(CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT)
 >
 > +#include <memalign.h>
 >   #include <mtd.h>
 >
 > +#define MTDPARTS_LEN         256
 > +#define MTDIDS_LEN           128
 > +
 > +#define DFU_ALT_BUF_LEN              SZ_1K
 > +
 > +static void board_get_alt_info(struct mtd_info *mtd, char *buf)
 > +{
 > +     struct mtd_info *part;
 > +     bool first = true;
 > +     const char *name;
 > +     int len, partnum = 0;
 > +
 > +     name = mtd->name;
 > +     len = strlen(buf);
 > +
 > +     if (buf[0] != '\0')
 > +             len += snprintf(buf + len, DFU_ALT_BUF_LEN - len,

"&");

...

 > +     len += snprintf(buf + len, DFU_ALT_BUF_LEN - len,
 > +                     "mtd %s=", name);
 > +
 > +     list_for_each_entry(part, &mtd->partitions, node) {
 > +             partnum++;
 > +             if (!first)
 > +                     len += snprintf(buf + len, DFU_ALT_BUF_LEN
- len, ";");
 > +             first = false;
 > +
 > +             len += snprintf(buf + len, DFU_ALT_BUF_LEN - len,
 > +                             "%s part %d",
 > +                             part->name, partnum);
 > +     }
 > +}
 > +
 > +void set_dfu_alt_info(char *interface, char *devstr)
 > +{
 > +     struct mtd_info *mtd;
 > +
 > +     ALLOC_CACHE_ALIGN_BUFFER(char, buf, DFU_ALT_BUF_LEN);
 > +
 > +     if (env_get("dfu_alt_info"))
 > +             return;
 > +
 > +     memset(buf, 0, sizeof(buf));
 > +
 > +     /* probe all MTD devices */
 > +     mtd_probe_devices();
 > +
 > +     mtd = get_mtd_device_nm("nor0");
 > +     if (!IS_ERR_OR_NULL(mtd))
 > +             board_get_alt_info(mtd, buf);
 > +
 > +     env_set("dfu_alt_info", buf);
 > +     printf("dfu_alt_info set\n");
 > +}
 > +
 >   static void board_get_mtdparts(const char *dev, const char
*partition,
 >                              char *mtdids, char *mtdparts)
 >   {
 > diff --git a/include/configs/qemu-arm.h

b/include/configs/qemu-arm.h

...

 > index 69ff329434..726f985d35 100644
 > --- a/include/configs/qemu-arm.h
 > +++ b/include/configs/qemu-arm.h
 > @@ -33,6 +33,7 @@
 >   #include <config_distro_bootcmd.h>
 >
 >   #if defined(CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT)
 > +#define CONFIG_SET_DFU_ALT_INFO
 >   #define CONFIG_SYS_MTDPARTS_RUNTIME
 >   #endif
 >
 >

On Tue, 8 Dec 2020 at 00:17, Tom Rini trini@konsulko.com wrote:

On Sat, Dec 05, 2020 at 11:31:49AM +0100, Heinrich Schuchardt wrote:

...

On 11/26/20 7:41 PM, Sughosh Ganu wrote:

...

The dfu framework uses the dfu_alt_info environment variable to get information that is needed for performing the firmware update. Set the dfu_alt_info for the platform to reflect the two mtd partitions created for the u-boot env and the firmware image.

Signed-off-by: Sughosh Ganu sughosh.ganu@linaro.org

I can't see anything QEMU specific in this patch. Why is the code under board/emulation/?

Best regards

Heinrich

...

---

board/emulation/qemu-arm/qemu-arm.c | 55

+++++++++++++++++++++++++++++

...

...

include/configs/qemu-arm.h | 1 + 2 files changed, 56 insertions(+)

diff --git a/board/emulation/qemu-arm/qemu-arm.c

b/board/emulation/qemu-arm/qemu-arm.c

...

...

index d5ed3eebaf..8cad54c76f 100644 --- a/board/emulation/qemu-arm/qemu-arm.c +++ b/board/emulation/qemu-arm/qemu-arm.c @@ -200,8 +200,63 @@ void flash_write32(u32 value, void *addr)

#if defined(CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT)

+#include <memalign.h> #include <mtd.h>

+#define MTDPARTS_LEN 256 +#define MTDIDS_LEN 128

+#define DFU_ALT_BUF_LEN SZ_1K

+static void board_get_alt_info(struct mtd_info *mtd, char *buf) +{

• struct mtd_info *part;
• bool first = true;
• const char *name;
• int len, partnum = 0;
• name = mtd->name;
• len = strlen(buf);
• if (buf[0] != '\0')

•       len += snprintf(buf + len, DFU_ALT_BUF_LEN - len, "&");
  

• len += snprintf(buf + len, DFU_ALT_BUF_LEN - len,

•               "mtd %s=", name);
  

• list_for_each_entry(part, &mtd->partitions, node) {

•       partnum++;
  

•       if (!first)
  

•               len += snprintf(buf + len, DFU_ALT_BUF_LEN - len,
  

";");

...

...

•       first = false;
  

•       len += snprintf(buf + len, DFU_ALT_BUF_LEN - len,
  

•                       "%s part %d",
  

•                       part->name, partnum);
  

• }

+}

+void set_dfu_alt_info(char *interface, char *devstr) +{

• struct mtd_info *mtd;
• ALLOC_CACHE_ALIGN_BUFFER(char, buf, DFU_ALT_BUF_LEN);
• if (env_get("dfu_alt_info"))

•       return;
  

• memset(buf, 0, sizeof(buf));
• /* probe all MTD devices */
• mtd_probe_devices();
• mtd = get_mtd_device_nm("nor0");
• if (!IS_ERR_OR_NULL(mtd))

•       board_get_alt_info(mtd, buf);
  

• env_set("dfu_alt_info", buf);
• printf("dfu_alt_info set\n");

+}

• static void board_get_mtdparts(const char *dev, const char

*partition,

...

...

                       char *mtdids, char *mtdparts)

{ diff --git a/include/configs/qemu-arm.h b/include/configs/qemu-arm.h index 69ff329434..726f985d35 100644 --- a/include/configs/qemu-arm.h +++ b/include/configs/qemu-arm.h @@ -33,6 +33,7 @@ #include <config_distro_bootcmd.h>

#if defined(CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT) +#define CONFIG_SET_DFU_ALT_INFO #define CONFIG_SYS_MTDPARTS_RUNTIME

First, CONFIG_SET_DFU_ALT_INFO is in Kconfig and needs to be enabled that way.

Will change in the next version.

Second, typically we just set the information in the environment part of the header. This is especially true if in both this case and the previous patch to add mtdparts, we don't really have this being dynamic? Or are we really expecting / supporting arbitrary sized flash as this is qemu? Thanks.

I am not sure I understand this. One thing that can be done is to move the setting of the mtd partitions to the Kconfig file, on similar lines to what is being done for the st platforms, e.g MTDPARTS_NOR0_TEE. I can move the mtd partition definitions to the Kconfig file if that is what you are asking for.

-sughosh

On Tue, 8 Dec 2020 at 17:50, Tom Rini trini@konsulko.com wrote:

On Tue, Dec 08, 2020 at 10:48:57AM +0530, Sughosh Ganu wrote:

...

On Tue, 8 Dec 2020 at 00:17, Tom Rini trini@konsulko.com wrote:

...

On Sat, Dec 05, 2020 at 11:31:49AM +0100, Heinrich Schuchardt wrote:

...

On 11/26/20 7:41 PM, Sughosh Ganu wrote:

...

The dfu framework uses the dfu_alt_info environment variable to get information that is needed for performing the firmware update. Set

the

...

...

...

...

dfu_alt_info for the platform to reflect the two mtd partitions created for the u-boot env and the firmware image.

Signed-off-by: Sughosh Ganu sughosh.ganu@linaro.org

I can't see anything QEMU specific in this patch. Why is the code

under

...

...

...

board/emulation/?

Best regards

Heinrich

...

---

board/emulation/qemu-arm/qemu-arm.c | 55

+++++++++++++++++++++++++++++

...

...

include/configs/qemu-arm.h | 1 + 2 files changed, 56 insertions(+)

diff --git a/board/emulation/qemu-arm/qemu-arm.c

b/board/emulation/qemu-arm/qemu-arm.c

...

...

index d5ed3eebaf..8cad54c76f 100644 --- a/board/emulation/qemu-arm/qemu-arm.c +++ b/board/emulation/qemu-arm/qemu-arm.c @@ -200,8 +200,63 @@ void flash_write32(u32 value, void *addr)

#if defined(CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT)

+#include <memalign.h> #include <mtd.h>

+#define MTDPARTS_LEN 256 +#define MTDIDS_LEN 128

+#define DFU_ALT_BUF_LEN SZ_1K

+static void board_get_alt_info(struct mtd_info *mtd, char *buf) +{

• struct mtd_info *part;
• bool first = true;
• const char *name;
• int len, partnum = 0;
• name = mtd->name;
• len = strlen(buf);
• if (buf[0] != '\0')

•       len += snprintf(buf + len, DFU_ALT_BUF_LEN - len, "&");
  

• len += snprintf(buf + len, DFU_ALT_BUF_LEN - len,

•               "mtd %s=", name);
  

• list_for_each_entry(part, &mtd->partitions, node) {

•       partnum++;
  

•       if (!first)
  

•               len += snprintf(buf + len, DFU_ALT_BUF_LEN -
  

len,

...

...

";");

...

...

•       first = false;
  

•       len += snprintf(buf + len, DFU_ALT_BUF_LEN - len,
  

•                       "%s part %d",
  

•                       part->name, partnum);
  

• }

+}

+void set_dfu_alt_info(char *interface, char *devstr) +{

• struct mtd_info *mtd;
• ALLOC_CACHE_ALIGN_BUFFER(char, buf, DFU_ALT_BUF_LEN);
• if (env_get("dfu_alt_info"))

•       return;
  

• memset(buf, 0, sizeof(buf));
• /* probe all MTD devices */
• mtd_probe_devices();
• mtd = get_mtd_device_nm("nor0");
• if (!IS_ERR_OR_NULL(mtd))

•       board_get_alt_info(mtd, buf);
  

• env_set("dfu_alt_info", buf);
• printf("dfu_alt_info set\n");

+}

• static void board_get_mtdparts(const char *dev, const char

*partition,

...

...

                       char *mtdids, char *mtdparts)

{ diff --git a/include/configs/qemu-arm.h

b/include/configs/qemu-arm.h

...

...

...

...

index 69ff329434..726f985d35 100644 --- a/include/configs/qemu-arm.h +++ b/include/configs/qemu-arm.h @@ -33,6 +33,7 @@ #include <config_distro_bootcmd.h>

#if defined(CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT) +#define CONFIG_SET_DFU_ALT_INFO #define CONFIG_SYS_MTDPARTS_RUNTIME

First, CONFIG_SET_DFU_ALT_INFO is in Kconfig and needs to be enabled that way.

Will change in the next version.

...

Second, typically we just set the information in the environment part of the header. This is especially true if in both

this

...

...

case and the previous patch to add mtdparts, we don't really have this being dynamic? Or are we really expecting / supporting arbitrary sized flash as this is qemu? Thanks.

I am not sure I understand this. One thing that can be done is to move

the

...

setting of the mtd partitions to the Kconfig file, on similar lines to

what

...

is being done for the st platforms, e.g MTDPARTS_NOR0_TEE. I can move the mtd partition definitions to the Kconfig file if that is what you are asking for.

Environment manipulation via C code is possible, but discouraged. What can be set via Kconfig should be set that way, and what can be put in the environment part of the header should be done that way. Does that help clarify?

Yes, that does clarify. I will move the settings of the partitions used for mtdparts in the Kconfig, similar to the way it is being done for the st platforms. Thanks.

-sughosh

On 11/26/20 7:41 PM, Sughosh Ganu wrote:

When building the capsule using scripts in edk2, an fmp header is added on top of the binary payload. Add a config option to indicate the presence of the header. When enabled, the pointer to the image needs to be adjusted as per the size of the header to point to the actual binary payload.

Why do we need a config option? Can't we detect the header?

Can we harmonize the capsule format in EDK II and U-Boot?

Best regards

Heinrich

Signed-off-by: Sughosh Ganu sughosh.ganu@linaro.org

lib/efi_loader/Kconfig | 7 +++++++ lib/efi_loader/efi_firmware.c | 12 ++++++++++++ 2 files changed, 19 insertions(+)

diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index 0d1b1b5356..55e4787e32 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -138,6 +138,13 @@ config EFI_CAPSULE_FIRMWARE_MANAGEMENT Select this option if you want to enable capsule-based firmware update using Firmware Management Protocol.

+config EFI_CAPSULE_FMP_HEADER

• bool "Capsule uses FMP header"
• depends on EFI_CAPSULE_FIRMWARE_MANAGEMENT
• help

•  Select this option if the capsule is built using the
  

•  scripts in edk2.
  

• config EFI_CAPSULE_FIRMWARE_FIT bool "FMP driver for FIT image" depends on EFI_CAPSULE_FIRMWARE_MANAGEMENT

diff --git a/lib/efi_loader/efi_firmware.c b/lib/efi_loader/efi_firmware.c index 7e56077383..6c97604d8b 100644 --- a/lib/efi_loader/efi_firmware.c +++ b/lib/efi_loader/efi_firmware.c @@ -385,10 +385,22 @@ efi_status_t EFIAPI efi_firmware_raw_set_image( if (!image) return EFI_EXIT(EFI_INVALID_PARAMETER);

• if (CONFIG_IS_ENABLED(EFI_CAPSULE_FMP_HEADER)) {

• /*
  

•  * 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 += 0x10;
  

• image_size -= 0x10;
  

• }

• if (dfu_write_by_alt(image_index - 1, (void *)image, image_size, NULL, NULL)) return EFI_EXIT(EFI_DEVICE_ERROR);

• printf("%s: Capsule update complete!\n", __func__); return EFI_EXIT(EFI_SUCCESS); }

On 11/26/20 7:41 PM, Sughosh Ganu wrote:

The pkcs7 header parsing functionality is pretty generic, and can be used by other features like capsule authentication. Make the function an extern, also changing it's name to efi_parse_pkcs7_header

Signed-off-by: Sughosh Ganu sughosh.ganu@linaro.org

include/efi_loader.h | 4 ++ lib/efi_loader/efi_signature.c | 85 +++++++++++++++++++++++++++++++ lib/efi_loader/efi_variable.c | 93 ++-------------------------------- 3 files changed, 93 insertions(+), 89 deletions(-)

diff --git a/include/efi_loader.h b/include/efi_loader.h index 76cd2b36f2..b9226208f5 100644 --- a/include/efi_loader.h +++ b/include/efi_loader.h @@ -810,6 +810,10 @@ bool efi_secure_boot_enabled(void); bool efi_image_parse(void *efi, size_t len, struct efi_image_regions **regp, WIN_CERTIFICATE **auth, size_t *auth_len);

+struct pkcs7_message *efi_parse_pkcs7_header(const void *buf,

• 			     size_t buflen,
  

• 			     u8 **tmpbuf);
  

• /* runtime implementation of memcpy() */ void efi_memcpy_runtime(void *dest, const void *src, size_t n);

diff --git a/lib/efi_loader/efi_signature.c b/lib/efi_loader/efi_signature.c index 79dee27421..9ab071b611 100644 --- a/lib/efi_loader/efi_signature.c +++ b/lib/efi_loader/efi_signature.c @@ -27,6 +27,91 @@ const efi_guid_t efi_guid_cert_x509_sha256 = EFI_CERT_X509_SHA256_GUID; const efi_guid_t efi_guid_cert_type_pkcs7 = EFI_CERT_TYPE_PKCS7_GUID;

#ifdef CONFIG_EFI_SECURE_BOOT +static u8 pkcs7_hdr[] = {

• /* SEQUENCE */
• 0x30, 0x82, 0x05, 0xc7,
• /* OID: pkcs7-signedData */
• 0x06, 0x09, 0x2a, 0x86, 0x48, 0x86, 0xf7, 0x0d, 0x01, 0x07, 0x02,
• /* Context Structured? */
• 0xa0, 0x82, 0x05, 0xb8,

Dear Takahiro,

From where are these magic numbers taken? Could you, please, provide a reference that we can add as a comment.

Best regards

Heinrich

+};

+/**

• • efi_parse_pkcs7_header - parse a signature in payload
• • @buf: Pointer to payload's value
• • @buflen: Length of @buf
• • @tmpbuf: Pointer to temporary buffer
• • Parse a signature embedded in payload's value and instantiate
• • a pkcs7_message structure. Since pkcs7_parse_message() accepts only
• • pkcs7's signedData, some header needed be prepended for correctly
• • parsing authentication data
• • A temporary buffer will be allocated if needed, and it should be
• • kept valid during the authentication because some data in the buffer
• • will be referenced by efi_signature_verify().
• • Return: Pointer to pkcs7_message structure on success, NULL on error
• */

+struct pkcs7_message *efi_parse_pkcs7_header(const void *buf,

• 			     size_t buflen,
  

• 			     u8 **tmpbuf)
  

+{

• u8 *ebuf;
• size_t ebuflen, len;
• struct pkcs7_message *msg;
• /*

• * This is the best assumption to check if the binary is
  

• * already in a form of pkcs7's signedData.
  

• */
  

• if (buflen > sizeof(pkcs7_hdr) &&

•    !memcmp(&((u8 *)buf)[4], &pkcs7_hdr[4], 11)) {
  

• msg = pkcs7_parse_message(buf, buflen);
  

• if (IS_ERR(msg))
  

• 	return NULL;
  

• return msg;
  

• }
• /*

• * Otherwise, we should add a dummy prefix sequence for pkcs7
  

• * message parser to be able to process.
  

• * NOTE: EDK2 also uses similar hack in WrapPkcs7Data()
  

• * in CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7VerifyCommon.c
  

• * TODO:
  

• * The header should be composed in a more refined manner.
  

• */
  

• EFI_PRINT("Makeshift prefix added to authentication data\n");
• ebuflen = sizeof(pkcs7_hdr) + buflen;
• if (ebuflen <= 0x7f) {

• EFI_PRINT("Data is too short\n");
  

• return NULL;
  

• }
• ebuf = malloc(ebuflen);
• if (!ebuf) {

• EFI_PRINT("Out of memory\n");
  

• return NULL;
  

• }
• memcpy(ebuf, pkcs7_hdr, sizeof(pkcs7_hdr));
• memcpy(ebuf + sizeof(pkcs7_hdr), buf, buflen);
• len = ebuflen - 4;
• ebuf[2] = (len >> 8) & 0xff;
• ebuf[3] = len & 0xff;
• len = ebuflen - 0x13;
• ebuf[0x11] = (len >> 8) & 0xff;
• ebuf[0x12] = len & 0xff;
• msg = pkcs7_parse_message(ebuf, ebuflen);
• if (IS_ERR(msg)) {

• free(ebuf);
  

• return NULL;
  

• }
• *tmpbuf = ebuf;
• return msg;

+}

/**

• efi_hash_regions - calculate a hash value

diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c index 0c689cfb47..ba0874e9e7 100644 --- a/lib/efi_loader/efi_variable.c +++ b/lib/efi_loader/efi_variable.c @@ -24,91 +24,6 @@ #include <asm/sections.h>

#ifdef CONFIG_EFI_SECURE_BOOT -static u8 pkcs7_hdr[] = {

• /* SEQUENCE */
• 0x30, 0x82, 0x05, 0xc7,
• /* OID: pkcs7-signedData */
• 0x06, 0x09, 0x2a, 0x86, 0x48, 0x86, 0xf7, 0x0d, 0x01, 0x07, 0x02,
• /* Context Structured? */
• 0xa0, 0x82, 0x05, 0xb8,

-};

-/**

• • efi_variable_parse_signature - parse a signature in variable
• • @buf: Pointer to variable's value
• • @buflen: Length of @buf
• • @tmpbuf: Pointer to temporary buffer
• • Parse a signature embedded in variable's value and instantiate
• • a pkcs7_message structure. Since pkcs7_parse_message() accepts only
• • pkcs7's signedData, some header needed be prepended for correctly
• • parsing authentication data, particularly for variable's.
• • A temporary buffer will be allocated if needed, and it should be
• • kept valid during the authentication because some data in the buffer
• • will be referenced by efi_signature_verify().
• • Return: Pointer to pkcs7_message structure on success, NULL on error
• */

-static struct pkcs7_message *efi_variable_parse_signature(const void *buf,

• 					  size_t buflen,
  

• 					  u8 **tmpbuf)
  

-{

• u8 *ebuf;
• size_t ebuflen, len;
• struct pkcs7_message *msg;
• /*

• * This is the best assumption to check if the binary is
  

• * already in a form of pkcs7's signedData.
  

• */
  

• if (buflen > sizeof(pkcs7_hdr) &&

•    !memcmp(&((u8 *)buf)[4], &pkcs7_hdr[4], 11)) {
  

• msg = pkcs7_parse_message(buf, buflen);
  

• if (IS_ERR(msg))
  

• 	return NULL;
  

• return msg;
  

• }
• /*

• * Otherwise, we should add a dummy prefix sequence for pkcs7
  

• * message parser to be able to process.
  

• * NOTE: EDK2 also uses similar hack in WrapPkcs7Data()
  

• * in CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7VerifyCommon.c
  

• * TODO:
  

• * The header should be composed in a more refined manner.
  

• */
  

• EFI_PRINT("Makeshift prefix added to authentication data\n");
• ebuflen = sizeof(pkcs7_hdr) + buflen;
• if (ebuflen <= 0x7f) {

• EFI_PRINT("Data is too short\n");
  

• return NULL;
  

• }
• ebuf = malloc(ebuflen);
• if (!ebuf) {

• EFI_PRINT("Out of memory\n");
  

• return NULL;
  

• }
• memcpy(ebuf, pkcs7_hdr, sizeof(pkcs7_hdr));
• memcpy(ebuf + sizeof(pkcs7_hdr), buf, buflen);
• len = ebuflen - 4;
• ebuf[2] = (len >> 8) & 0xff;
• ebuf[3] = len & 0xff;
• len = ebuflen - 0x13;
• ebuf[0x11] = (len >> 8) & 0xff;
• ebuf[0x12] = len & 0xff;
• msg = pkcs7_parse_message(ebuf, ebuflen);
• if (IS_ERR(msg)) {

• free(ebuf);
  

• return NULL;
  

• }
• *tmpbuf = ebuf;
• return msg;

-}

/**

• efi_variable_authenticate - authenticate a variable

@@ -215,10 +130,10 @@ static efi_status_t efi_variable_authenticate(u16 *variable, goto err;

/* ebuf should be kept valid during the authentication */

• var_sig = efi_variable_parse_signature(auth->auth_info.cert_data,

• 			       auth->auth_info.hdr.dwLength
  

• 				   - sizeof(auth->auth_info),
  

• 			       &ebuf);
  

• var_sig = efi_parse_pkcs7_header(auth->auth_info.cert_data,

• 			 auth->auth_info.hdr.dwLength
  

• 			 - sizeof(auth->auth_info),
  

• 			 &ebuf);
  

  if (!var_sig) { EFI_PRINT("Parsing variable's signature failed\n"); goto err;

On 11/26/20 7:41 PM, Sughosh Ganu wrote:

Add support for enabling uefi capsule authentication. This feature is enabled by setting the environment variable "capsule_authentication_enabled".

The following configs are needed for enabling uefi capsule update and capsule authentication features on the platform.

CONFIG_EFI_HAVE_CAPSULE_SUPPORT=y CONFIG_EFI_CAPSULE_ON_DISK=y CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT=y CONFIG_EFI_CAPSULE_FIRMWARE=y CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y CONFIG_EFI_CAPSULE_AUTHENTICATE=y

Dear Takahiro, dear Sughosh,

could you, please, provide a documentation for capsule updates in /doc/uefi.

Best regards

Heinrich

Signed-off-by: Sughosh Ganu sughosh.ganu@linaro.org

lib/efi_loader/efi_firmware.c | 37 ++++++++++++++++++++++++++++++++++- 1 file changed, 36 insertions(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_firmware.c b/lib/efi_loader/efi_firmware.c index 6c97604d8b..5e17b2ab5a 100644 --- a/lib/efi_loader/efi_firmware.c +++ b/lib/efi_loader/efi_firmware.c @@ -162,9 +162,16 @@ static efi_status_t efi_get_dfu_info( image_info[i].version_name = NULL; /* not supported */ image_info[i].size = 0; image_info[i].attributes_supported =

• 		IMAGE_ATTRIBUTE_IMAGE_UPDATABLE;
  

• 	IMAGE_ATTRIBUTE_IMAGE_UPDATABLE |
  

• 	IMAGE_ATTRIBUTE_AUTHENTICATION_REQUIRED;
  

  image_info[i].attributes_setting = IMAGE_ATTRIBUTE_IMAGE_UPDATABLE;

• /* Check if the capsule authentication is enabled */
  

• if (env_get("capsule_authentication_enabled"))
  

• 	image_info[0].attributes_setting |=
  

• 		IMAGE_ATTRIBUTE_AUTHENTICATION_REQUIRED;
  

• image_info[i].lowest_supported_image_version = 0; image_info[i].last_attempt_version = 0; image_info[i].last_attempt_status = LAST_ATTEMPT_STATUS_SUCCESS;

@@ -379,12 +386,40 @@ efi_status_t EFIAPI efi_firmware_raw_set_image( efi_status_t (*progress)(efi_uintn_t completion), u16 **abort_reason) {

• void *capsule_payload;

• efi_status_t status;

• efi_uintn_t capsule_payload_size;

• EFI_ENTRY("%p %d %p %ld %p %p %p\n", this, image_index, image, image_size, vendor_code, progress, abort_reason);

  if (!image) return EFI_EXIT(EFI_INVALID_PARAMETER);

• /* Authenticate the capsule if authentication enabled */

• if (IS_ENABLED(CONFIG_EFI_CAPSULE_AUTHENTICATE) &&

•    env_get("capsule_authentication_enabled")) {
  

• capsule_payload = NULL;
  

• capsule_payload_size = 0;
  

• status = efi_capsule_authenticate(image, image_size,
  

• 				  &capsule_payload,
  

• 				  &capsule_payload_size);
  

• if (status == EFI_SECURITY_VIOLATION) {
  

• 	printf("Capsule authentication check failed. Aborting update\n");
  

• 	return EFI_EXIT(status);
  

• } else if (status != EFI_SUCCESS) {
  

• 	return EFI_EXIT(status);
  

• }
  

• debug("Capsule authentication successfull\n");
  

• image = capsule_payload;
  

• image_size = capsule_payload_size;
  

• } else {

• debug("Capsule authentication disabled. ");
  

• debug("Updating capsule without authenticating.\n");
  

• }

• if (CONFIG_IS_ENABLED(EFI_CAPSULE_FMP_HEADER)) { /*

  • When building the capsule with the scripts in