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_iWjJNHa4gMF897MqYZNdbgjFG8K4kwGsTXWuy72Wk...
--- 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)