Capsule GUIDs and LVFS

[Richard Hughes]

Hi all!

> Any ODM/OEM creating a board
> based on the original device must use his own
> GUIID to avoid confusion. If not we would end up with different
> devices reusing the same GUIDs and upgrading their firmware with a
> different one.

Yes and no. Of course it's never okay for vendor A to use the same
GUID as vendor B -- but if vendor A has two models of hardware (for
instance model C and model D) they can have the same capsule GUID if
the update can use a DMI match on the product SMBIOS key to identify
the system. Of course, it's much better if they have different GUIDs
in the ESRT to completely avoid the chance of the wrong firmware being
flashed on the wrong device.

> Richard, the following GUIDs should at least issue a warning in LVFS
> since they only work for QEMU & Sandbox internally.
> Sandbox SANDBOX_UBOOT_IMAGE_GUID 09d7cf52-0720-4710-91d1-08469b7fe9c8
> Sandbox SANDBOX_UBOOT_ENV_IMAGE 5a7021f5-fef2-48b4-aaba-832e777418c0
> Sandbox SANDBOX_FIT_IMAGE_GUID 3673b45d-6a7c-46f3-9e60-adabb03f7937
> QEMU QEMU_ARM_UBOOT_IMAGE_GUID f885b085-99f8-45af-847d-d514107a4a2c
> QEMU QEMU_ARM64_UBOOT_IMAGE 058b7d83-50d5-4c47-a195-60d86ad341c4

Are these GUIDs that should be "never allow a firmware to be moved to
the stable remote if it uses this GUID" or more "a firmware also needs
a DMI restriction before being allowed near stable"? I'd err on the
former for these.

> I've cc'ed all the people I could find in board specific MAINTAINER files.
> Can you respond to Richard with the proper company name & board name
> so we can bind the following GUIDs to a vendor properly?
> Richard any guidance on how this should be done properly is
> appreciated, since I am not too aware of LVFS internals.

The LVFS doesn't need "pre-registration" of GUIDs so to speak; we have
have two deny lists of GUIDs -- one for "this is never valid" and one
for the "this needs a DMI match"

> STMicroelectronics STM32MP_FIP_IMAGE_GUID 19d5df83-11b0-457b-be2c-7559c13142a5
> This seems to use the same GUID for multiple device variants. This
> needs to be fixed

Is the DMI data different? e.g. you can see the Windows CHIDs (we use
the same DMI restriction scheme as Window 10) using
ComputerHardwareIds.exe or on Linux using `sudo fwupdtool hwids`

I've created a spreadsheet of what we do now, please feel free to add
GUIDs (anybody!) to the correct column:
https://docs.google.com/spreadsheets/d/1uPQmUrGA1KKsDPzGeg4xb2XOQEfsjDBBP9SQjqh31Wc/edit?usp=sharing

Thanks,

Richard.