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/1uPQmUrGA1KKsDPzGeg4xb2XOQEfsjDBBP9SQ...
Thanks,
Richard.