mbox series

[RFC,0/4] efi: CapsuleUpdate: support for dynamic GUIDs

Message ID 20240426-b4-dynamic-uuid-v1-0-e8154e00ec44@linaro.org
Headers show
Series efi: CapsuleUpdate: support for dynamic GUIDs | expand

Message

Caleb Connolly April 26, 2024, 2:19 p.m. UTC
As more boards adopt support for the EFI CapsuleUpdate mechanism, there
is a growing issue of being able to target updates to them properly. The
current mechanism of hardcoding UUIDs for each board at compile time is
unsustainable, and maintaining lists of GUIDs is similarly cumbersome.

In this series, I propose that we adopt v5 GUIDs, these are generated
by using a well-known salt GUID as well as board specific information
(like the model/revision), these are hashed together and the result is
truncated to form a new UUID.

The well-known salt GUID can be specific to the architecture (SoC
vendor), or OEM. Exact rules on how these are used (e.g. if vendors
should be told to generate their own for their products, and if that
can be added upstream, etc) will need to be decided.

Specifically, the following fields are used to generate a GUID for a
particular fw_image:

* namespace salt
* soc name
* board model (usually from dt root model property)
* board compatible (usually the first entry in the dt root compatible
  array).
* fw_image name (the string identifying the specific image, especially
  relevant for board that can update multiple images).

Once generated, the GUIDs can be printed with the "%pUs" format string,
these can then be stored externally to U-Boot.

The SoC name field might be controversial, it could be generated from
the last entry in the dt root compatible in most cases, or in some board
specific way. It might make sense to remove this field if it is
unfeasible for some boards.

== Usage ==

Boards can integrate dynamic UUID support as follows:

1. Adjust Kconfig to depend on EFI_CAPSULE_DYNAMIC_UUIDS if
   EFI_HAVE_CAPSULE_SUPPORT
2. Skip setting the fw_images image_type_id property.
3. In board_init() (or anywhere before the EFI subsystem is
   initialised), add a call to efi_capsule_update_info_gen_ids() with
   the board specific info.

== Limitations ==

* Changing GUIDs

The primary limitation with this approach is that if any of the source
fields change, so will the GUID for the board. It is therefore pretty
important to ensure that GUID changes are caught during development.

* Supporting multiple boards with a single image

This now requires having an entry with the GUID for every board which
might lead to larger UpdateCapsule images.

== Tooling ==

Not part of this RFC is a tool to generate the GUIDs outside of U-Boot.
I suspect this might be a requirement, but it makes sense to decide on
what fields we use first.

The tool should take in the salt, DTB, and a list of fw_image names. It
could also accept values to overwrite the individual fields if they
aren't derived from the DTB for some reason. It would then generate the
expected GUID.

A potential idea here would be to integrate this into the build system
so that it prints a warning if the GUID changes.

== TOOD ==

Missing from this RFC are unit tests for the dynamic UUID feature, these
will be implemented for future revisions.

I would appreciate any feedback on the above.

This follows a related discussion started by Ilias:
https://lore.kernel.org/u-boot/CAC_iWjJNHa4gMF897MqYZNdbgjFG8K4kwGsTXWuy72WkYLizrw@mail.gmail.com/

---
Caleb Connolly (4):
      lib: uuid: add UUID v5 support
      efi: add a helper to generate dynamic UUIDs
      doc: uefi: document dynamic GUID generation
      sandbox: switch to dynamic UUIDs

 arch/Kconfig                 |  1 +
 board/sandbox/sandbox.c      | 28 +++++++++++++++-------------
 doc/develop/uefi/uefi.rst    | 35 +++++++++++++++++++++++++++++++++++
 include/efi_loader.h         | 28 ++++++++++++++++++++++++++++
 include/uuid.h               | 16 ++++++++++++++++
 lib/Kconfig                  |  8 ++++++++
 lib/efi_loader/Kconfig       | 14 ++++++++++++++
 lib/efi_loader/efi_capsule.c | 33 +++++++++++++++++++++++++++++++++
 lib/uuid.c                   | 33 +++++++++++++++++++++++++++++++++
 9 files changed, 183 insertions(+), 13 deletions(-)
---
change-id: 20240422-b4-dynamic-uuid-1a5ab1486c27
base-commit: d097f9e1299a3bdb7de468f0d9bbc63932f461cd

// Caleb (they/them)

Comments

Ilias Apalodimas May 24, 2024, 5:55 a.m. UTC | #1
Hi Caleb

On Fri, 26 Apr 2024 at 17:19, Caleb Connolly <caleb.connolly@linaro.org> wrote:
>
> As more boards adopt support for the EFI CapsuleUpdate mechanism, there
> is a growing issue of being able to target updates to them properly. The
> current mechanism of hardcoding UUIDs for each board at compile time is
> unsustainable, and maintaining lists of GUIDs is similarly cumbersome.
>
> In this series, I propose that we adopt v5 GUIDs, these are generated
> by using a well-known salt GUID as well as board specific information
> (like the model/revision), these are hashed together and the result is
> truncated to form a new UUID.
>
> The well-known salt GUID can be specific to the architecture (SoC
> vendor), or OEM. Exact rules on how these are used (e.g. if vendors
> should be told to generate their own for their products, and if that
> can be added upstream, etc) will need to be decided.
>
> Specifically, the following fields are used to generate a GUID for a
> particular fw_image:
>
> * namespace salt
> * soc name
> * board model (usually from dt root model property)
> * board compatible (usually the first entry in the dt root compatible
>   array).
> * fw_image name (the string identifying the specific image, especially
>   relevant for board that can update multiple images).
>
> Once generated, the GUIDs can be printed with the "%pUs" format string,
> these can then be stored externally to U-Boot.
>
> The SoC name field might be controversial, it could be generated from
> the last entry in the dt root compatible in most cases, or in some board
> specific way. It might make sense to remove this field if it is
> unfeasible for some boards.
>
> == Usage ==
>
> Boards can integrate dynamic UUID support as follows:
>
> 1. Adjust Kconfig to depend on EFI_CAPSULE_DYNAMIC_UUIDS if
>    EFI_HAVE_CAPSULE_SUPPORT
> 2. Skip setting the fw_images image_type_id property.
> 3. In board_init() (or anywhere before the EFI subsystem is
>    initialised), add a call to efi_capsule_update_info_gen_ids() with
>    the board specific info.
>
> == Limitations ==
>
> * Changing GUIDs
>
> The primary limitation with this approach is that if any of the source
> fields change, so will the GUID for the board. It is therefore pretty
> important to ensure that GUID changes are caught during development.
>
> * Supporting multiple boards with a single image
>
> This now requires having an entry with the GUID for every board which
> might lead to larger UpdateCapsule images.
>
> == Tooling ==
>
> Not part of this RFC is a tool to generate the GUIDs outside of U-Boot.
> I suspect this might be a requirement, but it makes sense to decide on
> what fields we use first.

Yes, tooling would be good.

>
> The tool should take in the salt, DTB, and a list of fw_image names. It
> could also accept values to overwrite the individual fields if they
> aren't derived from the DTB for some reason. It would then generate the
> expected GUID.
>
> A potential idea here would be to integrate this into the build system
> so that it prints a warning if the GUID changes.
>

There's work being done in that direction as far as capsules are
concerned. Apart from the u-boot binary from your board, the build
system should also generate binaries

Thanks
/Ilias

> == TOOD ==
>
> Missing from this RFC are unit tests for the dynamic UUID feature, these
> will be implemented for future revisions.
>
> I would appreciate any feedback on the above.
>
> This follows a related discussion started by Ilias:
> https://lore.kernel.org/u-boot/CAC_iWjJNHa4gMF897MqYZNdbgjFG8K4kwGsTXWuy72WkYLizrw@mail.gmail.com/
>
> ---
> Caleb Connolly (4):
>       lib: uuid: add UUID v5 support
>       efi: add a helper to generate dynamic UUIDs
>       doc: uefi: document dynamic GUID generation
>       sandbox: switch to dynamic UUIDs
>
>  arch/Kconfig                 |  1 +
>  board/sandbox/sandbox.c      | 28 +++++++++++++++-------------
>  doc/develop/uefi/uefi.rst    | 35 +++++++++++++++++++++++++++++++++++
>  include/efi_loader.h         | 28 ++++++++++++++++++++++++++++
>  include/uuid.h               | 16 ++++++++++++++++
>  lib/Kconfig                  |  8 ++++++++
>  lib/efi_loader/Kconfig       | 14 ++++++++++++++
>  lib/efi_loader/efi_capsule.c | 33 +++++++++++++++++++++++++++++++++
>  lib/uuid.c                   | 33 +++++++++++++++++++++++++++++++++
>  9 files changed, 183 insertions(+), 13 deletions(-)
> ---
> change-id: 20240422-b4-dynamic-uuid-1a5ab1486c27
> base-commit: d097f9e1299a3bdb7de468f0d9bbc63932f461cd
>
> // Caleb (they/them)
>