esp32c3 does not build with mcuboot and CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256

[tqjp]

Describe the bug
esp32c3 IRAM overflows when using mcuboot and CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256

To Reproduce
Adding

SB_CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y

to sysbuild.conf

Expected behavior
Build completes without errors.

Logs and console output

`.iram0.text' will not fit in region `iram_seg'

Environment (please complete the following information):

• OS: Ubuntu
• Zephyr 4.0.0

Additional context
Increasing BOOTLOADER_IRAM_SEG_LEN in zephyr/soc/espressif/esp32c3/memory.h similarly as described in #76566 for the esp32s3 to 0xb000 solves the issue.
Why isn't there a CONFIG setting or similar to set those values?

[github-actions]

Hi @tqjp! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

[zhang-wenchao]

#85288

[rftafas]

If this is the Zephyr port, the one built with --sysbuild, then secure boot it is not yet supported. This is the "software based" secureboot, and it is not on our roadmap. It could even be working, but we are not adding energy to test it due to Espressif port.

The SecurebootV2, the hardware backed option, is not on roadmap on our side for the Zephyr port.

I suggest using Espressif port for all of that.

[tqjp]

If this is the Zephyr port, the one built with --sysbuild, then secure boot it is not yet supported. This is the "software based" secureboot, and it is not on our roadmap. It could even be working, but we are not adding energy to test it due to Espressif port.

It does actually work, as you point out, but with the higher IRAM settings.
Do I understand this correctly, even checking images only once for FOTA is considered secure boot?
We are not doing a full stack secure boot with a signed mcuboot.

And what is meant with basic cyber security, see MCUBOOT (Zephyr port, basic cyber security) in #29394?

[rftafas]

Zephyr Port of MCUboot on ESP32 devices

MCUboot's Secure Boot (soft based) will prevent a bogus/hacked image to be loaded on the device. For example, the attacker tried to tamper, send a compromised image OTA to the device for update. The keys wouldn't match, no update will be made and device is safe (Cybersecurity). But one with a cable could go there and re-flash the device, including the bootloader. Or remove the Flash chip and copy its contents.

Ok, the smart will remind me that there is e-fuse option for disabling flashing - but that is irreversible for ALL, attackers and non-attackers. And it is ineffective against flash removal and copying.

IMPORTANT:

• For non-Espressif devices, check their doc. This info is specific to Espressif devices, NOT to overall MCUboot.
• This secure boot implementation is not supported. Could work, but we see no reason to do it because we have the Espressif port.

Espressif Port of MCUboot

Espressif Port uses hardware backed SecurebootV2, which offers physical and cyber security. You can't flash a bogus image, and don't need to burn e-fuses.

It also offers Flash Encryption, so only that specific ESP32 knows what is written to its flash - no attack by removing the flash chip. (This is on my favorite option: let the device randomly select its key and only it will know what it is written).

[tqjp]

Thank you for the detailed description. We will have a look at the Espressif Port then.

Although it seems that for the esp32s3 the change in memory.h has been made for exactly this reason (#76566). Probably that is why @zhang-wenchao submitted a similar pull request for the esp32-c3. And in #29394 the Zephyr port / basic cybersecurity is marked as implemented and supported, I guess this all adds to the confusion.

[rftafas]

Well, it is marked because MCUboot - Zephyr Port is indeed supported; it works, albeit without many features. The table there is better understood as an overview. It's always suggested to TIY ( try it youself :) ) and ask if tests show things are not as expected.

My suggestions is labeling this as feature request, as it was not intended to work. I'll ask to remove the cyber security and replace it with bootloader only for less confusion.

[zhang-wenchao]

I think this basic functionality is needed, although without secure boot, the existing implementation can provide basic protection for Bluetooth OTA after disabling debugging and disabling UART firmware downloads.

[tqjp]

I think this basic functionality is needed, although without secure boot, the existing implementation can provide basic protection for Bluetooth OTA after disabling debugging and disabling UART firmware downloads.

Try with zephyr v4.1.0-rc2. I just saw that the IRAM value has been increased a little bit since V4.0.0 and it seems to work, or at least it builds without errors, in our use case.

[rftafas]

I think this basic functionality is needed

It is already covered by Espressif Port.

Although we are pending the BT support on Espressif port, it is far more likely for us to add BT to Espressif Port than add any functionality in Zephyr Port.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.