Add vendor and image class UUID support #2409

tomchy · 2025-07-31T13:56:03Z

According to the PSA Platform Security Boot Guide:

R20_PSBG_MANIFEST: Each image manifest must contain the properties specified in Figure 2. It is permitted for
additional information to be included.

The manifest (which can be interpreted as image header and additional metadata stored inside TLVs) must include:

Image type: Specifically identifies the boot stage or peripheral. Also known as a purpose identifier. This field is not required if only one type of image is supported.
Product class: This can refer to a vendor ID, product ID, or a more specific identifier, such as the
Instance ID.

This PR introduces two identifiers to meet those requirements:

Image class ID, defined as RFC 9562 UUID Version 5, that may contain all: image type and product type values as input.
Image vendor ID, defined as RFC 9562 UUID Version 5, that provides the namespace for the image class ID, so two devices with the same type/product name will have different image class UUIDs.

boot/bootutil/src/image_validate.c

de-nordic · 2025-08-18T14:21:22Z

boot/bootutil/src/image_validate.c

+            if (len != sizeof(img_uuid_vid)) {
+                /* Vendor UUID is not valid. */
+                rc = -1;
+                goto out;
+            }
+
+            rc = LOAD_IMAGE_DATA(hdr, fap, off, img_uuid_vid.raw, len);
+            if (rc) {
+                goto out;
+            }


If it was decided to wrap uuid in fih, these should probably also report fih failure; i do not understand a difference between a failure in uuid check and inability to perform the check. And I know that we are inconsistent here, and maybe that is a good point to discuss it.

There is a translation logic, based on the rc value:

if (rc) { FIH_SET(fih_rc, FIH_FAILURE);

and the default value of uuid_vid_valid and uuid_cid_valid will either way mask the other failure reasons.

The difference is just that - inability (if possible) can report "incompatible image format" and the uuid check can report "invalid UUID value".
There is though no way to distinguish between those error reasons as there is just a single FIH_FAILURE error code.

out: seams can't mock success - it only could mock failure as a glith.

de-nordic · 2025-08-18T14:23:38Z

boot/bootutil/include/bootutil/image.h

@@ -142,6 +142,8 @@ extern "C" {
                                             * ...
                                             * 0xffa0 - 0xfffe
                                             */
+#define IMAGE_TLV_UUID_VID          0x80    /* Vendor unique identifier */


These go above comment explaining vendor specific ids. If these are vendor specific ids, then they have in-proper codes.

And should't really be here.

What do you mean by "comment explaining vendor specific ids"?

@tomchy move this just after #define IMAGE_TLV_COMP_DEC_SIZE 0x73 /* Compressed decrypted image size */ line.
@de-nordic Clarification: these are new MCUboot generic TLVs

de-nordic · 2025-08-18T14:27:44Z

boot/zephyr/mcuboot_uuid.c

+
+static fih_ret boot_uuid_compare(const struct image_uuid *uuid1, const struct image_uuid *uuid2)
+{
+        return fih_ret_encode_zero_equality(memcmp(uuid1->raw, uuid2->raw,


Are we sure we want to get fih heavy on uuid comparisons? What is the attack vector here? As far as i cen tell they are already protected tlvs and, as such, are signed with image, and why would you bypass uid check? You would have to bypass signature first.

The attack vector would be to install the FW not designed for a particular core as a result of glitching the UUID checks (skipping them or altering comparison results).

Honestly, I do not know where to draw a line between checks that should use FIH and checks that should not. The code was based on the way the security counter is implemented, thus by default it uses FIH routines.

nvlsianpu · 2025-08-29T13:53:49Z

boot/bootutil/include/bootutil/image.h

@@ -142,6 +142,8 @@ extern "C" {
                                             * ...
                                             * 0xffa0 - 0xfffe
                                             */
+#define IMAGE_TLV_UUID_VID          0x80    /* Vendor unique identifier */


@tomchy move this just after #define IMAGE_TLV_COMP_DEC_SIZE 0x73 /* Compressed decrypted image size */ line.
@de-nordic Clarification: these are new MCUboot generic TLVs

nvlsianpu · 2025-08-29T13:56:12Z

boot/bootutil/include/bootutil/mcuboot_uuid.h

+#define __MCUBOOT_UUID_H__
+
+/**
+ * @file uuid.h


@file mcuboot_uuid.c

nvlsianpu · 2025-08-29T14:56:11Z

boot/bootutil/src/image_validate.c

+            if (len != sizeof(img_uuid_vid)) {
+                /* Vendor UUID is not valid. */
+                rc = -1;
+                goto out;
+            }
+
+            rc = LOAD_IMAGE_DATA(hdr, fap, off, img_uuid_vid.raw, len);
+            if (rc) {
+                goto out;
+            }


out: seams can't mock success - it only could mock failure as a glith.

nvlsianpu · 2025-08-29T15:11:04Z

boot/zephyr/Kconfig

+	     identifier.
+	   - Raw UUID (i.e. 12345678-1234-5678-1234-567812345678)
+
+if MCUBOOT_UUID_CID


can we have as many entries as images number allowed for given mcuboot assembly?

Added dependency on UPDATEABLE_IMAGE_NUMBER Kconfig value.

Add a possibility to express vendor ID and image class ID inside image's TLVs. Signed-off-by: Tomasz Chyrowicz <[email protected]>

Allow to specify VID and CID for an image. Signed-off-by: Tomasz Chyrowicz <[email protected]>

Add a possibility to configure vendor ID and image class ID through Kconfig. Signed-off-by: Tomasz Chyrowicz <[email protected]>

tomchy requested review from nordicjm, de-nordic, davidvincze and d3zd3z as code owners July 31, 2025 13:56

tomchy mentioned this pull request Jul 31, 2025

modules: Add VID and CID Kconfigs zephyrproject-rtos/zephyr#93940

Open

tomchy force-pushed the feature/bootutil/NCSDK-34175_Add_vid_cid_support_upstream branch from ab8fffa to fc4c042 Compare July 31, 2025 14:33

de-nordic reviewed Aug 18, 2025

View reviewed changes

tomchy force-pushed the feature/bootutil/NCSDK-34175_Add_vid_cid_support_upstream branch from fc4c042 to 54dd37c Compare August 25, 2025 12:20

tomchy requested a review from de-nordic August 25, 2025 12:24

tomchy force-pushed the feature/bootutil/NCSDK-34175_Add_vid_cid_support_upstream branch from 54dd37c to 25b5c04 Compare August 28, 2025 10:56

nvlsianpu reviewed Aug 29, 2025

View reviewed changes

tomchy added 3 commits August 29, 2025 17:53

boot: Add VID and CID checks

23e22e0

Add a possibility to express vendor ID and image class ID inside image's TLVs. Signed-off-by: Tomasz Chyrowicz <[email protected]>

imgtool: Add support for VID and CID

818cb16

Allow to specify VID and CID for an image. Signed-off-by: Tomasz Chyrowicz <[email protected]>

zephyr: Add Kconfig-based VID and CID checks

09fa479

Add a possibility to configure vendor ID and image class ID through Kconfig. Signed-off-by: Tomasz Chyrowicz <[email protected]>

tomchy force-pushed the feature/bootutil/NCSDK-34175_Add_vid_cid_support_upstream branch from 25b5c04 to 09fa479 Compare August 29, 2025 15:54

tomchy requested a review from nvlsianpu August 29, 2025 16:01

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Add vendor and image class UUID support #2409

Add vendor and image class UUID support #2409

Uh oh!

tomchy commented Jul 31, 2025

Uh oh!

Uh oh!

Uh oh!

de-nordic Aug 18, 2025

Uh oh!

tomchy Aug 25, 2025

Uh oh!

nvlsianpu Aug 29, 2025

Uh oh!

de-nordic Aug 18, 2025

Uh oh!

de-nordic Aug 18, 2025

Uh oh!

tomchy Aug 25, 2025

Uh oh!

nvlsianpu Aug 29, 2025

Uh oh!

de-nordic Aug 18, 2025

Uh oh!

tomchy Aug 25, 2025

Uh oh!

nvlsianpu Aug 29, 2025

Uh oh!

nvlsianpu Aug 29, 2025

Uh oh!

nvlsianpu Aug 29, 2025

Uh oh!

nvlsianpu Aug 29, 2025

Uh oh!

tomchy Aug 29, 2025

Uh oh!

Uh oh!

Add vendor and image class UUID support #2409

Are you sure you want to change the base?

Add vendor and image class UUID support #2409

Uh oh!

Conversation

tomchy commented Jul 31, 2025

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!