Capsule GUIDs and LVFS
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
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
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
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
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/1uPQmUrGA1KKsDPzGeg4xb2XOQEfsjDBBP9SQ...
Thanks,
Richard.
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/1uPQmUrGA1KKsDPzGeg4xb2XOQEfsjDBBP9SQ...
Thanks! /Ilias
Thanks,
Richard.
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.
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/1uPQmUrGA1KKsDPzGeg4xb2XOQEfsjDBBP9SQ...
Thanks! /Ilias
Thanks,
Richard.
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.
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.
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)
participants (6)
-
Caleb Connolly -
Ilias Apalodimas -
Michael Walle -
Michal Simek -
Richard Hughes -
Tom Rini