[PATCH v3 0/7] efi: CapsuleUpdate: support for dynamic UUIDs

[Caleb Connolly]

On 05/06/2024 07:59, Heinrich Schuchardt wrote:
> On 5/31/24 15:50, Caleb Connolly 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. It is defined in the board defconfig so that vendors
>> can easily bring their own.
>>
>> Specifically, the following fields are used to generate a GUID for a
>> particular fw_image:
>>
>> * namespace salt
>> * 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).
>>
>> == 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. Generate a UUID and set CONFIG_EFI_CAPSULE_NAMESPACE_UUID in your
>>     defconfig.
> 
> Why should we have two alternatives?
> 
> If we have the dynamic UUIDs, please, get rid of static ones.

I don't think this is possible to do without the risk of breaking some 
boards. Can we assume that ALL existing capsule update image GUIDs are 
safe to just scrap?
> 
>>
>> == 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.
> 
> Do we have a test case were a capsule contains images that shall not be
> installed?
> 
>>
>> == Tooling ==
>>
>> This series introduces a new tool: genguid. This can be used to generate
>> the same GUIDs that the board would at runtime.
> 
>      the GUIDs that the board requires at runtime.
> 
> Best regards
> 
> Heinrich
> 
>>
>> This series follows a related discussion started by Ilias:
>> https://lore.kernel.org/u-boot/CAC_iWjJNHa4gMF897MqYZNdbgjFG8K4kwGsTXWuy72WkYLizrw@mail.gmail.com/
>>
>> ---
>> Changes in v3:
>> - Add manpage for genguid
>> - Add dedicated CONFIG_TOOLS_GENGUID option
>> - Minor code fixes addressing v2 feedback
>> - Link to v2: 
>> https://lore.kernel.org/r/20240529-b4-dynamic-uuid-v2-0-c26f31057bbe@linaro.org
>>
>> Changes in v2:
>> - Move namespace UUID to be defined in defconfig
>> - Add tests and tooling
>> - Only use the first board compatible to generate UUID.
>> - Link to v1: 
>> https://lore.kernel.org/r/20240426-b4-dynamic-uuid-v1-0-e8154e00ec44@linaro.org
>>
>> ---
>> Caleb Connolly (7):
>>        lib: uuid: add UUID v5 support
>>        efi: add a helper to generate dynamic UUIDs
>>        doc: uefi: document dynamic UUID generation
>>        sandbox: switch to dynamic UUIDs
>>        lib: uuid: supporting building as part of host tools
>>        tools: add genguid tool
>>        test: lib/uuid: add unit tests for dynamic UUIDs
>>
>>   arch/Kconfig                                       |   1 +
>>   board/sandbox/sandbox.c                            |  16 ---
>>   configs/sandbox_defconfig                          |   1 +
>>   configs/sandbox_flattree_defconfig                 |   1 +
>>   doc/develop/uefi/uefi.rst                          |  31 +++++
>>   doc/genguid.1                                      |  52 +++++++
>>   include/sandbox_efi_capsule.h                      |   6 +-
>>   include/uuid.h                                     |  21 ++-
>>   lib/Kconfig                                        |   8 ++
>>   lib/efi_loader/Kconfig                             |  23 +++
>>   lib/efi_loader/efi_capsule.c                       |   1 +
>>   lib/efi_loader/efi_firmware.c                      |  66 +++++++++
>>   lib/uuid.c                                         |  81 +++++++++--
>>   test/lib/uuid.c                                    |  88 ++++++++++++
>>   .../test_efi_capsule/test_capsule_firmware_fit.py  |   2 +-
>>   .../test_efi_capsule/test_capsule_firmware_raw.py  |   8 +-
>>   .../test_capsule_firmware_signed_fit.py            |   2 +-
>>   .../test_capsule_firmware_signed_raw.py            |   4 +-
>>   test/py/tests/test_efi_capsule/version.dts         |   6 +-
>>   tools/Kconfig                                      |   7 +
>>   tools/Makefile                                     |   3 +
>>   tools/binman/etype/efi_capsule.py                  |   2 +-
>>   tools/binman/ftest.py                              |   2 +-
>>   tools/genguid.c                                    | 154 
>> +++++++++++++++++++++
>>   24 files changed, 538 insertions(+), 48 deletions(-)
>> ---
>> change-id: 20240422-b4-dynamic-uuid-1a5ab1486c27
>> base-commit: 2e682a4a406fc81ef32e05c28542cc8067f1e15f
>>
>> // Caleb (they/them)
>>
> 

-- 
// Caleb (they/them)