Re: Capsule GUIDs and LVFS

[Ilias Apalodimas <ilias.apalodimas@linaro.org>]

On Thu, Apr 25, 2024 at 05:16:12PM +0200, Caleb Connolly wrote:
> Hi all,
>
> On 25/04/2024 15:46, Ilias Apalodimas wrote:
> > Hi Richard,
> >
> > On Thu, 25 Apr 2024 at 15:28, Richard Hughes <hughsient@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.
>

The DMI matching would need extra code in the capsule update code as well and
I can't remember on top of my head how we fill the DMI in U-Boot.
The capsule specific GUID is supposed to find a function in the firmware
of how to update the specified partitions. We now use a generic function
for all the boards which points to DFU, so all a board has to do is define
the proper DFU string.
I do like the idea of unique GUIDs better myself, since it's easier to
match the ESRT tables etc. But I'd like to hear more from board maintainers

Thanks
/Ilias
> >
> > 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)