Capsule GUIDs and LVFS

[Caleb Connolly]

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)