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

[Caleb Connolly]

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)