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.
Set SECURE_BOOT_SHA384_EN when enabling ECDSA-P384 Secure Boot V2 on
ESP32-P4, as done on C5/H4/S31, so that ROM verifies the bootloader
using the SHA-384 scheme. The eFuse exists only on the rev >= v3.0
eFuse table, so the Kconfig option is gated on rev >= v3.0.
Previously the bootloader unconditionally revoked unused secure boot key
digest slots while permanently enabling secure boot on the first boot,
ignoring CONFIG_SECURE_BOOT_ALLOW_UNUSED_DIGEST_SLOTS. Now the config is
honored on this path too: when set, the unused digest slots are left
un-revoked. This is safe as long as the debug and download interfaces are
disabled.
Update the Kconfig help and the Secure Boot v2 guide (en and zh_CN)
accordingly.
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.
Wrap MWDT-related code under SOC_WDT_SUPPORTED so targets without a main
watchdog can compile.
Add SOC_RTC_WDT_SUPPORTED for RTC watchdog usage (bootloader, slow-clock
paths) and regenerate Kconfig.soc_caps.in. Bootloader RWDT setup stays
under SOC_RTC_WDT_SUPPORTED; MWDT flashboot teardown stays under
SOC_WDT_SUPPORTED.
ESP_INT_WDT, ESP_TASK_WDT_EN, and BOOTLOADER_WDT_ENABLE depend on
SOC_WDT_SUPPORTED where applicable. Build xt_wdt.c only when
SOC_XT_WDT_SUPPORTED. Provide no-op panic WDT helpers when
SOC_WDT_SUPPORTED is disabled.
Mostly helpful in testing scenarios. The newly added config
SECURE_BOOT_REQUIRE_ALREADY_ENABLED will ensure the SB feature must
already be enabled, otherwise the bootloader simply fails to boot.
- The API esp_flash_encryption_set_release_mode() by defualt programs
the XTS-AES pseudo round level efuse to level low but did not considered
any existing value that would have been programmed in the efuse bit.
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.
- Secure boot V2 verification failed when multiple keys are used to sign the bootloader
and the application is signed with a key other than the first key that is used to
sign the bootloader.
- The issue was introduced as a regression from the commit `ff16ce43`.
- Added a QEMU test for recreating the issue.
- Made SECURE_BOOT_FLASH_BOOTLOADER_DEFAULT independent of SECURE_BOOT_BUILD_SIGNED_BINARIES.
feat(bootloader_support): enabled RSA based secure boot scheme for ESP32C5 ECO1
Closes IDF-10453 and IDF-11441
See merge request espressif/esp-idf!35104
This commit enabled RSA based secure boot scheme for ESP32C5 ECO1 module.
This update also adds a check to ensure the selected secure boot scheme is
valid for ECO0 modules.
