GATT stack broadcasts notifications to every client app, so unregistered
gatt_if instances were flooding logs even when another app had registered
the handle. Only warn when no client app registered for the handle.
(cherry picked from commit c18c8dc5e7)
Co-authored-by: zhanghaipeng <zhanghaipeng@espressif.com>
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.
Default timeout for interrupt WDT was increased by default
on ESP32, due to some heap integrity check APIs taking a long
time on large PSRAMs and causing timeouts.
But this adjustment was only done for ESP32, not later chips,
even though they may experience the same issue.
Adjusted to have the same behavior on all chips with PSRAM
enabled, making it consistant with the docs.
Closes https://github.com/espressif/esp-idf/issues/18360
- `bootloader_flash_execute_command_common`: whitelist the flash command
opcodes the REE actually uses; reject the rest
- `spi_flash_hal_* services`: a forged `host->driver` could hijack TEE
control flow since the HAL dispatches through it, so swap
`host->driver` to a TEE-rodata vtable around each HAL call
- Deny partition table and bootloader writes by default and permit
bootloader writes only when explicitly enabled via
`CONFIG_SPI_FLASH_DANGEROUS_WRITE_ALLOWED` option
- Protect the TEE-assigned interrupt pin configuration against REE
- Validate nested DS context pointers in start/finish_sign and bound
the result copy to the SoC max signature size
- Fix the stack usage in service dispatcher argument parsing
- Forbid TKIP cipher suites for WPA3-Enterprise scan results
- Use reason 210 (NO_AP_FOUND_W_COMPATIBLE_SECURITY) when an AP is
found during a connecting scan but filtered out for incompatible
security
- Stop NAN timers from re-arming after esp_wifi_stop
Jin Cheng
ShenWeilong
Jiang Jiang Jian
morris
zhiweijian
Rahul Tank
Alexey Gerenkov
Sumeet Singh
Wang Meng Yang
Mahavir Jain
Roland Dobai
Chen Jichang
JiangGuangMingandCursor
Marius Vikhammer
yangfeng
Zhang Hai Peng
gaoxu
Alexey Lapshin
Aditya Patwardhan
Song Ruo Jing
harshal.patil
sibeibei
Laukik Hase
yanzihan@espressif.com
Sarvesh Bodakhe