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.
The second stage bootloader no longer configures or locks PMP entries on
C5, C6, C61, H2 and P4; document the impact on non-ESP-IDF applications
launched by the ESP-IDF bootloader that relied on the bootloader-provided
PMP configuration.
Commit ab229a34 added PSRAM memory protection for ESP32-P4 rev < 3.0. It
consumed all 16 PMP entries and shifted the fixed LP-RAM (9-12 -> 11-14) and
peripheral (13 -> 15) entries to make room. Older bootloaders lock the
peripheral entry at its original index 13, so on a v5.3/v5.4 bootloader running
a newer application the LP-RAM entry that landed on the locked index 13 was
silently ignored, weakening LP-RAM protection.
Select the rev < 3.0 layout at runtime by probing whether the bootloader locked
the peripheral at entry 13:
- locked (v5.3/v5.4) -> default layout (LP-RAM 9-12, peripheral 13), no PSRAM
protection; these devices never had it (it was introduced in v5.5).
- free (v5.5+) -> PSRAM layout (flash/ext-RAM 6-10, LP-RAM 11-14,
peripheral 15) with full external-RAM protection; the peripheral entry at 15
matches the bootloader's lock.
This restores forward compatibility across all shipped rev < 3.0 bootloaders
without regressing PSRAM protection on the v5.5+ devices that already have it.
Chip revision >= 3.0 (32 PMP entries) is unaffected.
A PMP entry the (non-OTA-updatable) bootloader locks cannot be reconfigured
by the application until CPU reset, so the layout of the entries a shipped
bootloader locks is a bootloader<->application ABI that renumbering would
silently break on deployed devices.
On C5, C6, C61, H2 and P4 the bootloader now configures only the PMA invalid regions
and leaves PMP to the application.
On C5 the application programs the two ROM entries without a cfg reset:
v6.0/v6.1 bootloaders lock the TOR base entry at SOC_IROM_MASK_LOW, so on
such devices the TOR region above it spans the ROM text and must keep the
X bit those bootloaders left in the following unlocked entry, which
OR-only writes can never clear. With newer bootloaders the application
receives clean entries and the ROM data region gets the intended strict R
permission.
The Key Manager hardware peripheral in its current form needs further
design changes before it can be offered as a production feature.
Until a revised peripheral design is available, withdraw ESP-IDF
support for it on all Key Manager capable targets.
ESP32-C2 and ESP32-C61 have no RSA based Secure Boot V2 support, so the
CI configs that pin the RSA signing scheme and key fail the app signing
scheme/key check on these targets.
- flash_enc_wifi_2.data_partition_verification: add C2/C61 sdkconfig
overlays that switch to the ECDSA P-256 signing scheme and key (no
force-enable needed as Secure Boot V2 itself is not enabled here).
- on_update_no_sb_rsa: disable the build on targets without
SOC_SECURE_BOOT_V2_RSA, mirroring simple_ota_example, since this
config specifically exercises the RSA scheme.
The signing step (espsecure sign-data) derives the signature block type
from the key file itself, so selecting e.g. the RSA app signing scheme
with an ECDSA signing key produced a successfully built image that only
failed signature verification at boot.
Check the key at configure time and fail with a clear error when:
- the key family (RSA vs ECDSA) does not match the selected app signing
scheme
- the ECDSA curve does not match the selected ECDSA key size for the
ECDSA (V1/V2) schemes
- the key cannot be parsed as an unencrypted PEM private key
esp_crypto_shared_gdma_done() polled the AXI RX raw interrupt status
(in_done) but never cleared it, so after the first transfer the set bit
made every subsequent call return immediately without waiting.
The spiram-xip IROM/DROM alignment tests assumed the XIP region always
leaves an alignment gap before the next MMU page: they executed into the
gap and expected an instruction access fault followed by a register dump.
When the section ends exactly on an MMU page boundary there is no gap - the
device prints "<IROM/DROM> alignment gap not added into heap" and returns,
the framework restarts cleanly (esp_restart_noos, no panic), and the test
timed out waiting for a register dump.
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.
Audited every esp_* PSA driver against its corresponding software driver in
mbedtls/library (psa_crypto_cipher.c, psa_crypto_aead.c, psa_crypto_mac.c,
psa_crypto_hash.c, psa_crypto_ecp.c, psa_crypto_rsa.c) and fixed gaps in
workflow ownership, error-path cleanup, sensitive-data wiping, and BAD_STATE
gating per the PSA Crypto API spec.
esp_aes (cipher): fix padding oracle in cipher_finish by replacing leaky
branches with mbedtls_ct_* primitives; abort wipes the driver-level ctx,
not just the inner mbedtls_aes_context; setup routes errors through abort.
esp_aes_gcm (AEAD): zeroize the 16-byte full_tag scratch; restore the
*output_length = finish_output_size assignment that the SW reference keeps
for future ciphers; NULL the inner ctx pointer after free in abort; gate
update/finish on a live ctx with PSA_ERROR_BAD_STATE.
esp_ecdsa: keep abort-at-exit in the one-shot wrappers so the stack-copy
of the hash (needed for little-endian byte order on HW) is wiped per
PSA spec 6.3.3, drop the over-defensive public-key qx/qy wipes that the
SW driver does not perform.
esp_cmac / esp_hmac_transparent / esp_hmac_opaque (MAC): make abort
idempotent, route setup errors through abort, gate update/finish/
verify_finish on PSA_ERROR_BAD_STATE, wipe M_last and intermediate hmac[]
buffers on completion or HW failure. HMAC opaque gains alg + computed
fields to mirror the SW psa_crypto_mac.c state machine. HMAC transparent
explicitly aborts the inner SHA context before reusing it for the outer
hash.
esp_sha: switch the per-op live indicator to (sha_ctx != NULL) so the
public esp_sha_operation_type_t enum keeps its original ordinal values;
free + NULL sha_ctx on every error path; gate update/finish/clone on a
live ctx; wipe per-algorithm core/parallel-engine scratch buffers
(W[], A[], state) on HW-engine failure.
esp_md5: replace bare memset in abort with mbedtls_platform_zeroize.
esp_rsa_ds: complete() no longer frees sig_buffer (abort owns that);
start() routes failures through abort; asymmetric_decrypt funnels all
cleanup through a single exit: label. RSA-DS utilities wipe the
decrypted-plaintext scratch on v15 / OAEP unpad failure.
ESP32-C2 and ESP32-C61 have no RSA based Secure Boot V2 support
so the virt_sb_v2_and_fe configs cannot use the default RSA signing key.
Add target-specific sdkconfig overlays that switch to the ECDSA P-256 key;
on ESP32-C61 the ECDSA scheme must additionally be force-enabled
SECURE_BOOT_V2_ECDSA_INSECURE).
The "custom certificate bundle - weak hash" test relied on DigiCert
Global Root CA being present as a trust anchor in cacrt_all.pem (the
only SHA-1-self-signed root in the chain it loaded). The recent
cacrt_all.pem refresh moved that root to cacrt_deprecated.pem, so the
chain could no longer anchor and the test started failing.
On ESP32-P4 rev < 3.0, Key Manager is software-disabled, but the public
esp_key_mgr.h APIs had no runtime check.
Calls using HMAC/DS/PSRAM key types fell through to
HAL_ASSERT("Unsupported ...") paths in key_mgr_ll.h. Gate
each public API with key_mgr_ll_is_supported() and return
ESP_ERR_NOT_SUPPORTED cleanly instead.
The Key Manager holds a key usage register, thus, the Key Manager peripheral
clock must be enabled even for efuses-based key operations to route the
crypto operations to correctly to the efuses (default is Key Manager)
Instead of performing the cache-to-memory (C2M) operation on the output buffer,
even a cache invalidate (M2C) is sufficient to ensure that no write-back occurs
during the DMA write operation
The key_mgr_ll_set_xts_aes_key_len() function was incorrectly using
REG_SET_FIELD() with the key_len enum value directly. Since
KEYMNG_FLASH_KEY_LEN is a 1-bit register field (0=128-bit, 1=256-bit),
writing ESP_KEY_MGR_XTS_AES_LEN_128 (value 3) resulted in the LSB (1)
being stored, incorrectly configuring 256-bit mode.
Fixed by using a switch statement to properly map:
- ESP_KEY_MGR_XTS_AES_LEN_128 → REG_CLR_BIT (0)
- ESP_KEY_MGR_XTS_AES_LEN_256 → REG_SET_BIT (1)
Thus, matching the correct ESP32-C5 implementation.
when the external input and output buffers are unaligned.
This also fixes as a recursion loop that occurs when the size of the input
buffer is not aligned to dcache_line_size but is aligned to AES_BLOCK_BYTES
- Update the Key Manager key types to be generic
- Define a new enum to determine the length of the keys
- Refactor the Key Manager driver support generic key types and key lengths
- Also store key deployment mode in the key recovery info
harshal.patil
