ESP_FAULT_ASSERT(C) was silently deleted by the optimizer when C is a cached
flag/status already proven by a preceding `if (!C) return/goto`: the compiler
folds C to a constant and drops all three checks, removing the fault-injection
protection with no warning.
In release/v5.x, esp_fault.h resides in the esp_hw_support (G1)
component, so the G0 components (hal, esp_rom) must not depend on it.
Copy its contents to esp_common as esp_fault_internal.h, keep
esp_fault.h as a compatibility wrapper around it, and switch the hal
and esp_rom ECDSA/ECC code to the internal header.
Prevent signature verification failures on targets that do not round hardware words
to 16-word boundaries (e.g. ESP32-S3, ESP32-C6, and ESP32-P4), where exponent blinding
can cause `num_words` to vary between calls, leading to reuse of an incorrectly sized
cached `Rinv`.
Perform modulo reduction on the base before size checks to allow RSA-4096
CRT (2048-bit exponentiations) to use the hardware accelerator instead of
falling back to software. Fix input validation, negative zero sign issues,
and early memory cleanup paths in esp_mpi_exp_mod()
Peers may report custom or non-standard codec UUIDs in AT+BAC alongside
CVSD/mSBC. Returning BTA_AG_CODEC_NONE on the first unknown entry
discarded already-parsed standard codecs. Log unknown UUIDs and continue
parsing so negotiated capabilities still reflect supported codecs.
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.
Replace argparse with rich-click and use esp_pylib.logger for
standardized console output and fatal error handling.
(cherry picked from commit 3a7896f2c5)
Co-authored-by: zhanghaipeng <zhanghaipeng@espressif.com>
Mahavir Jain
Jiang Jiang Jian
Island
Rahul Tank
Wang Meng Yang
Astha Verma
harshal.patil
Kapil Gupta
xiongweichao
Aditya Patwardhan
Zhang Hai Peng
morris
Song Ruo Jing
wuzhenghui
Jin Cheng
zhiweijian
ShenWeilong
Sumeet Singh