smpmgr does not accept IMAGE_TLV_PUBKEY (0x02) when using CONFIG_BOOT_HW_KEY in zephyr

[TK5090]

Hello,
I am using smpmgr to flash new applications onto devices running MCUboot built with zephyr project.
When the firmware is built with CONFIG_BOOT_HW_KEY, the TLV section contains athe full public key entry defined as:

#define IMAGE_TLV_PUBKEY 0x02 /* public key */

However, when trying to use smpmgr.exe for an upgrade, it fails to validate the image with the following error:

smpmgr.exe --port COM8 --baudrate 38400 upgrade zephyr.signed.bin
Inspection of FW image failed: 1 validation error for ImageTLV
0
  Input should be 1, 16, 32, 33, 34, 35, 36, 48, 49, 50, 51, 64 or 80 [type=enum, input_value=2, input_type=int]
    For further information visit https://errors.pydantic.dev/2.12/v/enum

It seems that smpmgr does not recognize TLV type 0x02 (IMAGE_TLV_PUBKEY) as a valid enum value, even though it is part of the MCUboot specification when hardware key validation is used.

Is it possible to ignore this?

Expected behavior:

smpmgr should accept and correctly parse TLV entries with type 0x02 when CONFIG_BOOT_HW_KEY is enabled.

Edit:
Ok, I see that in the file smpclient/mcuboot.py in class IMAGE_TLV(IntEnum):
the header
#define IMAGE_TLV_PUBKEY 0x02 /* public key */

is missing :(

[JPHutchins]

The MCUBoot TLV types specification has been updated: https://docs.mcuboot.com/design.html#image-format

The TLV types need to be updated with the new entries, and existing entries should be confirmed as well:

smpclient/smpclient/mcuboot.py

Lines 61 to 90 in bf5787d

	@unique
	class IMAGE_TLV(IntEnum):
	"""Image trailer TLV types."""
	KEYHASH = 0x01
	"""hash of the public key"""
	SHA256 = 0x10
	"""SHA256 of image hdr and body"""
	RSA2048_PSS = 0x20
	"""RSA2048 of hash output"""
	ECDSA224 = 0x21
	"""ECDSA of hash output - Not supported anymore"""
	ECDSA_SIG = 0x22
	"""ECDSA of hash output"""
	RSA3072_PSS = 0x23
	"""RSA3072 of hash output"""
	ED25519 = 0x24
	"""ED25519 of hash output"""
	ENC_RSA2048 = 0x30
	"""Key encrypted with RSA-OAEP-2048"""
	ENC_KW = 0x31
	"""Key encrypted with AES-KW-128 or 256"""
	ENC_EC256 = 0x32
	"""Key encrypted with ECIES-P256"""
	ENC_X25519 = 0x33
	"""Key encrypted with ECIES-X25519"""
	DEPENDENCY = 0x40
	"""Image depends on other image"""
	SEC_CNT = 0x50
	"""security counter"""

An LLM should be able to complete this, including the docstrings.

It would be nice to add some fixtures - compiled FW with this TLV present - to prevent regressions, though it is low risk because the TLVs are so simple: https://github.com/intercreate/smpclient/blob/main/tests/test_mcuboot_tools.py

[JPHutchins]

Mmmm, I see that some "vendor defined" ranges are available. In the long run we'll probably have to add some means of injecting support, perhaps via a "map of decoder functions". Or simply report them by integer rather than enumeration.

[JPHutchins]

OK, better idea. There is precedent in the smp lib to use Pydantic's "left to right" validation, wherein the narrowest type is the "left most" member of the type. https://github.com/JPHutchins/smp/blob/95f3c5b555a2620e77c3053f41811e7495d145e0/smp/header.py#L103

So, I think this would be:

ImageTLVType = Annotated[Union[IMAGE_TLV,  int], Field(union_mode="left_to_right")]

And that would 1) support user-defined types and 2) prevent errors when new types are added to the spec.