Zephyr DFU subsystem incompatible with Espressif MCUBoot and Flash Encryption

[epneo-sebastianbaier]

Describe the bug

The Zephyr DFU subsystem is not compatible with the Espressif MCUBoot Port when Flash Encryption is enabled, as it is not possible (at least for the Espressif chip) to adjust the value of MCUBOOT_BOOT_MAX_ALIGN with Zephyr build-in options. There is also a discussion about this in the Zephyr Discord server.

Currently, a Zephyr Sysbuild with the Espressif MCUBoot Port is also not possible, which would possibly avoid or solve the problem.

According to a discussion in the Zephyr Discord, it should be possible to customize the MCUBOOT_BOOT_MAX_ALIGN define via the device tree and the write-block-size parameter of the flash. However, this does not work without Sybuild or with an Espressif chip.

In detail, the problem is caused by the fact that the Zephyr DFU subsystem also depends on the value of MCUBOOT_BOOT_MAX_ALIGN (which then differs between the application and the Espressif MCUBoot port), because it uses the bootutil of MCUBoot to write its header.

To Reproduce

1. Activate Flash Encryption in the Espressif MCUBoot port. (CONFIG_SECURE_FLASH_ENC_ENABLED=y)
2. Flash MCUBoot with activated Flash Encryption to an ESP32S3 chip, for example.
3. Flash any example that uses the Zephyr DFU subsystem to the controller.
4. Update the application via the Zephyr DFU subsystem.
5. The update will not be bootable.

Expected behavior

A possibility in Zephyr without Sysbuild to customize the Define MCUBOOT_BOOT_MAX_ALIGN so that the Zephyr DFU subsystem is compatible with the Espressif MCUBoot Port.

Impact

Manual patching of Zephyr to ensure compatibility.

Environment

• OS: Ubuntu 24.04.2 LTS within WSL2
• Toolchain: zephyr-sdk-0.17.0

[marekmatej]

hi @epneo-sebastianbaier FYI, the MCUboot Espressif port Zephyr integration is cooking here #87710

[marekmatej]

cc @almir-okato

[de-nordic]

Be careful here, because making direct dependency between MCUBOOT_BOOT_MAX_ALIGN and DTS entry write-block-size is basically definition of lasagna code, where unrelated subsystem directly picks configuration of other subsystem, bypassing layers in-between.

The write-block-size is a flash/rram/mram/whatever parameter not MCUboot parameter.

I do understand that we have a lot of lasagna code, also involving the write-block-size, and making it worse does not help,

[epneo-sebastianbaier]

hi @epneo-sebastianbaier FYI, the MCUboot Espressif port Zephyr integration is cooking here #87710

Thank you, rftafas from the Discord send me the PR in the MCUBoot project related. We will definitely use the MCUBoot Espressif Port with Zephyr Sysbuild and test the PR. Last time I checked, however, there was only the PR for the MCUBoot project.

Regardless of this, it should also be possible to set the value correctly if you don't use Sysbuild, whether this makes sense or not.

[epneo-sebastianbaier]

Be careful here, because making direct dependency between MCUBOOT_BOOT_MAX_ALIGN and DTS entry write-block-size is basically definition of lasagna code, where unrelated subsystem directly picks configuration of other subsystem, bypassing layers in-between.

The write-block-size is a flash/rram/mram/whatever parameter not MCUboot parameter.

I do understand that we have a lot of lasagna code, also involving the write-block-size, and making it worse does not help,

As far as I understand it, this is exactly the way with Nordic SoCs. So if I set write-block-size, it is adopted into the define MCUBOOT_BOOT_MAX_ALIGN.

[epneo-sebastianbaier]

Currently, I am simply working around the problem by defining a KConfig entry in our project called SECURE_FLASH_ENC_ENABLED. When I set this, MCUBOOT_BOOT_MAX_ALIGN is set correctly on Espressif projects in the DFU subsystem and in the MCUBoot Utils

[de-nordic]

As far as I understand it, this is exactly the way with Nordic SoCs. So if I set write-block-size, it is adopted into the define MCUBOOT_BOOT_MAX_ALIGN.

Yes. That is why

I do understand that we have a lot of lasagna code, also involving the write-block-size, and making it worse does not help,

and I am NOT happy about it at all.

[de-nordic]

Currently, I am simply working around the problem by defining a KConfig entry in our project called SECURE_FLASH_ENC_ENABLED. When I set this, MCUBOOT_BOOT_MAX_ALIGN is set correctly on Espressif projects in the DFU subsystem and in the MCUBoot Utils

Don't you want to rather expose the MCUBOOT_BOOT_MAX_ALIGN via Kconfig and allow it to be set via prj.conf and/or Kconfig logic.
Such exposure would also allow you to pass it via command line, for example from build ci or build scripts.

[almir-okato]

@epneo-sebastianbaier, when Flash Encryption from Espressif chips is enabled, writing to flash must be 32-byte aligned, it is a constraint from the flash controller. So on MCUboot Espressif Port once you enable Flash Encryption, the MCUBOOT_BOOT_MAX_ALIGN config is set to 32, also the imgtool signing must match this alignment as everything in flash will be encrypted, otherwise the headers and trailers may not be "readable/writable".

For now, could you try setting an DTS overlay file to your Zephyr project that defines write-block-size accordingly?

[epneo-sebastianbaier]

Currently, I am simply working around the problem by defining a KConfig entry in our project called SECURE_FLASH_ENC_ENABLED. When I set this, MCUBOOT_BOOT_MAX_ALIGN is set correctly on Espressif projects in the DFU subsystem and in the MCUBoot Utils

Don't you want to rather expose the MCUBOOT_BOOT_MAX_ALIGN via Kconfig and allow it to be set via prj.conf and/or Kconfig logic. Such exposure would also allow you to pass it via command line, for example from build ci or build scripts.

That's exactly what I'm doing. :-)

[epneo-sebastianbaier]

@epneo-sebastianbaier, when Flash Encryption from Espressif chips is enabled, writing to flash must be 32-byte aligned, it is a constraint from the flash controller. So on MCUboot Espressif Port once you enable Flash Encryption, the MCUBOOT_BOOT_MAX_ALIGN config is set to 32, also the imgtool signing must match this alignment as everything in flash will be encrypted, otherwise the headers and trailers may not be "readable/writable".

For now, could you try setting an DTS overlay file to your Zephyr project that defines write-block-size accordingly?

Hi @almir-okato, yes I know. That is also what I'm doing right now. I adjust the value of write-block-size to 32 bytes and MCUBOOT_BOOT_MAX_ALIGN is set through exposing the KConfig paramater with the prj.cong and project KConfig.

Nevertheless, this is not a nice solution. For one thing, the behavior of projects with (I haven't checked this for all manufacturers, of course) Nordic SoCs is different from that of Esprerssif-based projects.

For Nordic-based projects, setting write-block-size is enough to set MCUBOOT_BOOT_MAX_ALIGN to the same value, but not for Espressif.

Whether this is fundamentally not a nice solution, as @de-nordic says, I can't say.

In general, it would be nice if there was an (at least Espressif-specific) KConfig parameter that would automatically configure the Zephyr application to work with the Espressif MCUBoot port and flash encryption,