Capsule GUIDs and LVFS

Capsule GUIDs and LVFS

[Ilias Apalodimas]

Hi,

Richard maintains LVFS & fwupd, commonly used for firmware upgrades.
We recently discussed the U-Boot status and supported devices since
fwupd supports capsule updates.
In order to be able to support capsule updates via LVFS manufacturers
should bind their GUIDs to their devices. 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.

Looking at the defined GUIDS for capsule updates defined in board
support files I found the following

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

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.

Advantech IMX8MP_RSB3720A1 b1251e89-384a-4635-a806-3aa0b0e9f965
Advantech IMX8MP_RSB3720A1_6G b5fb6f08-e142-4db1-97ea-5fd36b9be5b9

Compulab IMX8MM_CL_IOT_GATE 7a32a939-ab92-467b-9152-74771b95e646
Compulab MX8MM_CL_IOT_GATE_OPTEE_FIT 0bf1165c-1831-4864-945e-ac3d3848f499

Kontron KONTRON_PITX_IMX8M_FIT_IMAGE_GUID c898e959-5b1f-4e6d-88e0-40d45cca1399
Kontron KONTRON_SL_MX8MM_FIT_IMAGE_GUID d488e45a-4929-4b55-8c14-86cea2cd6629
Kontron KONTRON_SL28_FIT_IMAGE_GUID 86ebd44f-feb8-466f-8bb8-890618456d8b

Radxa ROCKPI_4B_IDBLOADER_IMAGE_GUID 02f4d760-cfd5-43bd-8e2d-a42acb33c660
Radxa ROCKPI_4B_UBOOT_IMAGE_GUID 4ce292da-1dd8-428d-a1c2-77743ef8b96e
Radxa ROCKPI_4C_IDBLOADER_IMAGE_GUID fd68510c-12d3-4f0a-b8d3-d879e1d3a540
Radxa ROCKPI_4C_UBOOT_IMAGE_GUID b81fb4ae-e4f3-471b-99b4-0b3da549ce13

Socionext DEVELOPERBOX_FIP_IMAGE_GUID 7d6dc310-52ca-43b8-b7b9-f9d6c501d108
Socionext DEVELOPERBOX_FIP_IMAGE_GUID2 880866e9-84ba-4793-a908-33e0b916f398

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

AMD/Xilinx XILINX_BOOT_IMAGE_GUID 20c5fba5-0171-457f-b9cd-f5129cd07228
AMD/Xilinx XILINX_UBOOT_IMAGE_GUID cf9ecfd4-938b-41c5-8551-1f883ab7dc18
ditto

Regards
/Ilias

Re: Capsule GUIDs and LVFS

[Michal Simek]

Hi,

On 4/25/24 08:19, Ilias Apalodimas wrote:
> Hi,
> 
> Richard maintains LVFS & fwupd, commonly used for firmware upgrades.
> We recently discussed the U-Boot status and supported devices since
> fwupd supports capsule updates.
> In order to be able to support capsule updates via LVFS manufacturers
> should bind their GUIDs to their devices. 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.
> 
> Looking at the defined GUIDS for capsule updates defined in board
> support files I found the following
> 
> 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
> 
> 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.
> 
> Advantech IMX8MP_RSB3720A1 b1251e89-384a-4635-a806-3aa0b0e9f965
> Advantech IMX8MP_RSB3720A1_6G b5fb6f08-e142-4db1-97ea-5fd36b9be5b9
> 
> Compulab IMX8MM_CL_IOT_GATE 7a32a939-ab92-467b-9152-74771b95e646
> Compulab MX8MM_CL_IOT_GATE_OPTEE_FIT 0bf1165c-1831-4864-945e-ac3d3848f499
> 
> Kontron KONTRON_PITX_IMX8M_FIT_IMAGE_GUID c898e959-5b1f-4e6d-88e0-40d45cca1399
> Kontron KONTRON_SL_MX8MM_FIT_IMAGE_GUID d488e45a-4929-4b55-8c14-86cea2cd6629
> Kontron KONTRON_SL28_FIT_IMAGE_GUID 86ebd44f-feb8-466f-8bb8-890618456d8b
> 
> Radxa ROCKPI_4B_IDBLOADER_IMAGE_GUID 02f4d760-cfd5-43bd-8e2d-a42acb33c660
> Radxa ROCKPI_4B_UBOOT_IMAGE_GUID 4ce292da-1dd8-428d-a1c2-77743ef8b96e
> Radxa ROCKPI_4C_IDBLOADER_IMAGE_GUID fd68510c-12d3-4f0a-b8d3-d879e1d3a540
> Radxa ROCKPI_4C_UBOOT_IMAGE_GUID b81fb4ae-e4f3-471b-99b4-0b3da549ce13
> 
> Socionext DEVELOPERBOX_FIP_IMAGE_GUID 7d6dc310-52ca-43b8-b7b9-f9d6c501d108
> Socionext DEVELOPERBOX_FIP_IMAGE_GUID2 880866e9-84ba-4793-a908-33e0b916f398
> 
> 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
> 
> AMD/Xilinx XILINX_BOOT_IMAGE_GUID 20c5fba5-0171-457f-b9cd-f5129cd07228

this is versal GUID

> AMD/Xilinx XILINX_UBOOT_IMAGE_GUID cf9ecfd4-938b-41c5-8551-1f883ab7dc18
> ditto

And this is ZYNQMP one but that's just a note.

What has to happen at least in our case when LVFS is used, we need to generate 
new GUIDs for every board because we can't use the same GUIDs for all boards.

Thanks,
Michal

Re: Capsule GUIDs and LVFS

[Michael Walle]

[-- Attachment #1: Type: text/plain, Size: 1282 bytes --]

Hi,

On Thu Apr 25, 2024 at 8:19 AM CEST, Ilias Apalodimas wrote:
> 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.

Thanks for taking care!

> Kontron KONTRON_PITX_IMX8M_FIT_IMAGE_GUID c898e959-5b1f-4e6d-88e0-40d45cca1399

This (board) should likely be dropped to lower maintenance burden as
it is EOL and "not recommended for new designs".

> Kontron KONTRON_SL_MX8MM_FIT_IMAGE_GUID d488e45a-4929-4b55-8c14-86cea2cd6629

This is probably (at least) the wrong name. SL is a
System-on-Module, a small PCB that will be soldered on a carrier
board and cannot run on it's own and a customer using that SoM will
likely have their own bootloader. There is, though the "BL" which is
the in-house board for this SoM.

Company name is "Kontron Electronics GmbH".

> Kontron KONTRON_SL28_FIT_IMAGE_GUID 86ebd44f-feb8-466f-8bb8-890618456d8b

Company name is "Kontron Europe GmbH".

Both entities belong to the Kontron Group, not sure how this is
handled in LVFS though.

-michael

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]

Re: Capsule GUIDs and LVFS

[Richard Hughes]

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

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

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

> 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'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,

Richard.

Re: Capsule GUIDs and LVFS

[Ilias Apalodimas]

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

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

Re: Capsule GUIDs and LVFS

[Richard Hughes]

On Thu, 25 Apr 2024 at 14:46, Ilias Apalodimas
<ilias.apalodimas@linaro.org> wrote:
> 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?

Right, I've added some of those to the spreadsheet "never" column.
They'll work for testing purposes but they can't be pushed to public
remotes.

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

Yup, we check that components with duplicate GUIDs don't have
different AppStream IDs or different sets of HWID requirements.

Richard.

Re: 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@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)

Re: Capsule GUIDs and LVFS

[Richard Hughes]

On Thu, 25 Apr 2024 at 16:16, Caleb Connolly <caleb.connolly@linaro.org> wrote:
> 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..

Yup, that works too -- on the assumption the compatible string is unique enough.

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

So that's kinda like Microsoft CHID, and I'm wondering why you
couldn't just use one of the GUIDs from `sudo fwupdtool hwids`
actually *as* the capsule GUID.

Richard.

Re: Capsule GUIDs and LVFS

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 741 bytes --]

On Thu, Apr 25, 2024 at 05:13:21PM +0100, Richard Hughes wrote:
> On Thu, 25 Apr 2024 at 16:16, Caleb Connolly <caleb.connolly@linaro.org> wrote:
> > 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..
> 
> Yup, that works too -- on the assumption the compatible string is unique enough.

This is where things are a little fun. In previous discussions, yes, the
machine compatible string should be unique. But it's not. Is it unique
enough for this case, today? No, since mechanism could be what's passing
the correct device tree to the OS. Might this in turn be what drives
people to fix the case? Maybe.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Capsule GUIDs and LVFS

[Ilias Apalodimas]

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)

Re: Capsule GUIDs and LVFS

[Ilias Apalodimas]

On Thu, Apr 25, 2024 at 09:18:31AM +0200, Michal Simek wrote:
> Hi,
>
> On 4/25/24 08:19, Ilias Apalodimas wrote:
> > Hi,
> >
> > Richard maintains LVFS & fwupd, commonly used for firmware upgrades.
> > We recently discussed the U-Boot status and supported devices since
> > fwupd supports capsule updates.
> > In order to be able to support capsule updates via LVFS manufacturers
> > should bind their GUIDs to their devices. 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.
> >
> > Looking at the defined GUIDS for capsule updates defined in board
> > support files I found the following
> >
> > 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
> >
> > 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.
> >
> > Advantech IMX8MP_RSB3720A1 b1251e89-384a-4635-a806-3aa0b0e9f965
> > Advantech IMX8MP_RSB3720A1_6G b5fb6f08-e142-4db1-97ea-5fd36b9be5b9
> >
> > Compulab IMX8MM_CL_IOT_GATE 7a32a939-ab92-467b-9152-74771b95e646
> > Compulab MX8MM_CL_IOT_GATE_OPTEE_FIT 0bf1165c-1831-4864-945e-ac3d3848f499
> >
> > Kontron KONTRON_PITX_IMX8M_FIT_IMAGE_GUID c898e959-5b1f-4e6d-88e0-40d45cca1399
> > Kontron KONTRON_SL_MX8MM_FIT_IMAGE_GUID d488e45a-4929-4b55-8c14-86cea2cd6629
> > Kontron KONTRON_SL28_FIT_IMAGE_GUID 86ebd44f-feb8-466f-8bb8-890618456d8b
> >
> > Radxa ROCKPI_4B_IDBLOADER_IMAGE_GUID 02f4d760-cfd5-43bd-8e2d-a42acb33c660
> > Radxa ROCKPI_4B_UBOOT_IMAGE_GUID 4ce292da-1dd8-428d-a1c2-77743ef8b96e
> > Radxa ROCKPI_4C_IDBLOADER_IMAGE_GUID fd68510c-12d3-4f0a-b8d3-d879e1d3a540
> > Radxa ROCKPI_4C_UBOOT_IMAGE_GUID b81fb4ae-e4f3-471b-99b4-0b3da549ce13
> >
> > Socionext DEVELOPERBOX_FIP_IMAGE_GUID 7d6dc310-52ca-43b8-b7b9-f9d6c501d108
> > Socionext DEVELOPERBOX_FIP_IMAGE_GUID2 880866e9-84ba-4793-a908-33e0b916f398
> >
> > 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
> >
> > AMD/Xilinx XILINX_BOOT_IMAGE_GUID 20c5fba5-0171-457f-b9cd-f5129cd07228
>
> this is versal GUID
>
> > AMD/Xilinx XILINX_UBOOT_IMAGE_GUID cf9ecfd4-938b-41c5-8551-1f883ab7dc18
> > ditto
>
> And this is ZYNQMP one but that's just a note.

Ah thanks, I know you already added the correct ones on the excel, pasting
the update list here as well

IMX8MP_RSB3720A1 b1251e89-384a-4635-a806-3aa0b0e9f965
IMX8MP_RSB3720A1_6G b5fb6f08-e142-4db1-97ea-5fd36b9be5b9
IMX8MM_CL_IOT_GATE 7a32a939-ab92-467b-9152-74771b95e646
IMX8MM_CL_IOT_GATE_OPTEE_FIT 0bf1165c-1831-4864-945e-ac3d3848f499
QEMU_ARM64_UBOOT_IMAGE 058b7d83-50d5-4c47-a195-60d86ad341c4
KONTRON_PITX_IMX8M_FIT_IMAGE_GUID c898e959-5b1f-4e6d-88e0-40d45cca1399
KONTRON_SL_MX8MM_FIT_IMAGE_GUID d488e45a-4929-4b55-8c14-86cea2cd6629
KONTRON_SL28_FIT_IMAGE_GUID 86ebd44f-feb8-466f-8bb8-890618456d8b
ROCKPI_4B_UBOOT_IMAGE_GUID 4ce292da-1dd8-428d-a1c2-77743ef8b96e
ROCKPI_4C_IDBLOADER_IMAGE_GUID fd68510c-12d3-4f0a-b8d3-d879e1d3a540
ROCKPI_4C_UBOOT_IMAGE_GUID b81fb4ae-e4f3-471b-99b4-0b3da549ce13
SANDBOX_UBOOT_IMAGE_GUID 09d7cf52-0720-4710-91d1-08469b7fe9c8
SANDBOX_UBOOT_ENV_IMAGE 5a7021f5-fef2-48b4-aaba-832e777418c0
SANDBOX_FIT_IMAGE_GUID 3673b45d-6a7c-46f3-9e60-adabb03f7937
DEVELOPERBOX_FIP_IMAGE_GUID 7d6dc310-52ca-43b8-b7b9-f9d6c501d108
DEVELOPERBOX_FIP_IMAGE_GUID2 880866e9-84ba-4793-a908-33e0b916f398
STM32MP_FIP_IMAGE_GUID 19d5df83-11b0-457b-be2c-7559c13142a5
XILINX_BOOT_IMAGE_GUID_ZYNQMP de6066e8-0256-4fad-8238-e406e274c4cf
XILINX_UBOOT_IMAGE_GUID_ZYNQMP cf9ecfd4-938b-41c5-8551-1f883ab7dc18
XILINX_BOOT_IMAGE_GUID_ZYNQ 1ba29a15-9969-40aa-b424-e86121618664
XILINX_UBOOT_IMAGE_GUID_ZYNQ 1a5178f0-87d3-4f36-ac63-3b31a23be305

Thanks
/Ilias
>
> What has to happen at least in our case when LVFS is used, we need to
> generate new GUIDs for every board because we can't use the same GUIDs for
> all boards.
>
> Thanks,
> Michal