Capsule GUIDs and LVFS

[Ilias Apalodimas]

Hi Richard,

On Thu, 25 Apr 2024 at 15:28, Richard Hughes <hughsient at gmail.com> wrote:
>
> 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.

In theory, yes but we don't have any of these check in u-boot and I'd
rather avoid them and do it properly

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

Exactly.

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

TBH those are GUIDs that are used by virtual devices. It wouldn't hurt
if someone reused those GUIDs but we can display a warning about it?

>
> > 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"

Ok thanks for the info. Is there also a check of "I have duplicate
GUIDs that aren't in the DMI list'?

>
> > 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 hope ST answers that, they are cc'ed

>
> 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!
/Ilias
>
> Thanks,
>
> Richard.