Restore the use_secure_element field in esp_tls_cfg_t, esp_tls_cfg_server_t
and httpd_ssl_config_t, and esp_transport_ssl_use_secure_element(), as
deprecated no-ops so that existing code keeps compiling. Setting them now
fails at runtime with ESP_ERR_NOT_SUPPORTED, as the feature is accessed
via the esp_key_config_t interface. To be removed in the next major release.
No compile-time deprecation attribute on this release branch; the field and
function stay warning-free here and carry only documentation notes.
- esp_tls_mbedtls: require cert when PSA-backed server/client key is set
- esp_tls_mbedtls: drop redundant pk_init/x509_crt_init (calloc handles it)
- psa SE driver: copy callbacks/opaque_key by value (no lifetime coupling)
- psa SE driver: replace atomic CAS with simple null check on register
- psa SE driver: use sig_len from sign callback with bounds validation
- psa SE driver: validate pubkey_len returned by export_pubkey callback
- psa SE driver: check hash sub-alg in RSA PKCS1V15 branch of validate_request
- psa SE driver: align secure_element_register_callbacks doc with value-copy impl
- esp_https_server: initialize server_key in HTTPD_SSL_CONFIG_DEFAULT
- mbedtls: move SECURE_ELEMENT_DRIVER_ENABLED to esp_config.h for parity
with ESP_ECDSA_DRIVER_ENABLED; drop target_compile_definitions
- docs: fix esp_tls_cfg_t -> esp_http_client_config_t cross-reference
- docs: check psa_import_key() status in ESP-TLS PSA example
- hints/error_output: point at CONFIG_MBEDTLS_SECURE_ELEMENT_DRIVER_ENABLED
(cherry picked from commit 08b567ef3b)
Update esp_tls, esp_http_client docs and migration guide to reflect
the new esp_key_config_t interface and secure element PSA driver.
(cherry picked from commit 37808e2386)
Add generic secure element PSA driver with runtime callback registration.
Consolidate Kconfig into single MBEDTLS_SECURE_ELEMENT_DRIVER_ENABLED option.
Closes https://github.com/espressif/esp-idf/issues/18388
(cherry picked from commit 1c20f525b4)
Add async color convert coverage for direct RGB24/BGR24 byte-order swaps
and
thread both TX and RX CSC state through DMA2D transactions for future
extensibility.
Embed a 720p BGR raw asset and stream the encoded JPEG over UART so
this example no longer depends on SD card setup.
Add pytest coverage that reconstructs the JPEG from base64 output and
compares it against a checked-in golden image.
- Server can now start from any directory, not just a valid project dir
- Document project_dir argument available on all tools
- Add create-project tool to the list of available tools
Co-authored-by: Cursor <cursoragent@cursor.com>
Define per-target SDIO slave descriptor buffer limits in the LL layer and validate queued send buffers against the 4-byte aligned effective maximum. Update the public docs to describe the chip-dependent limit instead of hardcoding 4092 bytes.
Co-authored-by: Cursor <cursoragent@cursor.com>
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.
- security.rst: remove duplicated word in OTA encryption note
- tee.rst: remove duplicated word in memory allocation note
- flash-encryption.rst: drop redundant phrase and fix subject-verb agreement
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
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.
