The digest length and the condition that reserves it at the end of RTC RAM were
duplicated in seven places. Hold the reservation in a hidden Kconfig value that
is zero when the feature does not apply, so every consumer subtracts it
unconditionally, and derive ESP_SECURE_BOOT_DIGEST_LEN from it.
ECDSA based Secure Boot V2 is not functional for certain input vectors on
ESP32-C5/C61/H2/P4 and on the preview targets ESP32-H4/H21. RSA based Secure
Boot V2 is the recommended scheme where the SoC supports it. This issue will be
fixed in a future hardware ECO revision; more details will be shared through the
hardware errata document.
A new hidden Kconfig option SECURE_BOOT_V2_ECDSA_INSECURE marks the affected
mass-production SoCs (ESP32-C5/C61/H2/P4). On these SoCs, when hardware Secure
Boot V2 is enabled, the ECDSA (V2) signing scheme is no longer offered by
default; it must be turned on explicitly via SECURE_BOOT_V2_FORCE_ENABLE_ECDSA
under "Allow potentially insecure options" (CONFIG_SECURE_BOOT_INSECURE). App
signing without hardware Secure Boot is not affected. Note that ESP32-C61 has no
RSA based Secure Boot V2, so it has no Secure Boot scheme enabled by default.
The preview targets ESP32-H4 and ESP32-H21 mark ECDSA Secure Boot V2 as not
supported in their SoC capabilities instead of using the option above. As
ESP32-H4 has no other Secure Boot V2 scheme, Secure Boot is disabled entirely on
it; ESP32-H21 retains RSA based Secure Boot V2.
The security documentation keeps the ECDSA Secure Boot V2 content visible and
adds a warning describing the limitation (including that ECDSA Secure Boot V2 on
ESP32-C61 is not recommended for production). CI apps that exercise ECDSA Secure
Boot V2 on the affected SoCs set CONFIG_SECURE_BOOT_V2_FORCE_ENABLE_ECDSA
accordingly.
For secure update without secure boot case, the encryption length for
app image must consider signature block length as well. This was
correctly handled for secure boot case but not for secure update without
secure boot.
* Closes https://github.com/espressif/esp-idf/issues/12849
In former versions of ESP-IDF, the user custom memory data in the retained memory
was taken into account during the CRC calculation. This was changed in a later
commit, the custom memory was ignored, therefore this can seen as a breaking change.
This commit gives the possibility to choose between the former (legacy) or
new way of calculating the CRC.
CONFIG_BOOTLOADER_COMPILER_OPTIMIZATION_NONE doesnt really have many use cases, but it will
force us to keep increasing bootloader segment sizes just to allow for building this options.
Deprecate this config for new chips.
Currently, when flash encryption is enabled, the whole partition gets encrypted.
This can be optimised by encrypting only the app image instead of encrypting the whole partition.
Closes https://github.com/espressif/esp-idf/issues/12576
- This change will introduce a breaking change for SoCs with the HMAC
peripheral. Turning on flash encryption will no longer enable NVS
encryption automatically.
Closes https://github.com/espressif/esp-idf/issues/12549
