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/1uPQmUrGA1KKsDPzGeg4xb2XOQEfsjDBBP9SQ...
Thanks! /Ilias
Thanks,
Richard.
-- // Caleb (they/them)