Capsule GUIDs and LVFS
Caleb Connolly
caleb.connolly at linaro.org
Thu Apr 25 17:16:12 CEST 2024
Hi all,
On 25/04/2024 15:46, Ilias Apalodimas wrote:
> 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
I discussed an idea with Ilias to generate GUIDs dynamically based on
the board compatible/model, which seem to essentially just an
abstraction on this.. But I'm wondering now if it wouldn't be better to
do DMI matching.
Like, if we have a GUID of some specificity (OEM, ODM, mach, whatever),
and the DMI data (usually root compatible and model, but easily
extensible and overriden by board code) then we can do the exact same
matching, but with the added bonus of being easily able to tell what's
up if something doesn't match. Generating a GUID from this data makes it
way more difficult to figure out why the board doesn't match.
But the issue there I guess is that the EFI spec only allows for
identifying by GUID and not any other data...
>
>> 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.
So expanding on the above a bit, the idea Ilias and I brainstormed was
to use v5 GUIDs (which are deterministic based on a "salt" GUID and some
arbitrary data which is hashed together). We would use the board model
and compatible, as well as the firmware image name to generate these.
Then for every board we want to support in LVFS we just boot it, dump
the geenerated GUIDs, and use them. This makes changing the
model/compatible strings a little bit annoying but it's workable.
I feel like this is a "clever" solution to the issue of all these
hardcoded GUIDs (and needing to add new ones for every board, even if
the board otherwise requires no code changes in U-Boot). But it also
feels kinda ugly in how it's just a worse version of the DMI matching
fwupd can already do.
>
> 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.
--
// Caleb (they/them)
More information about the U-Boot
mailing list