Extend the CTR test data length to 6433 bytes so the trailing partial
block is exercised with external RAM buffers (which stalls the ESP32-S2
Crypto DMA on an unfixed driver), and add AES-GCM PSRAM tests verified
against internal RAM references.
The ESP32-S2 Crypto DMA in-channel stalls silently when a receive
descriptor list transitions from external to internal RAM. The AES
driver hits this when a PSRAM-output operation has a trailing partial
block, as the internal stream descriptor is linked after the external
RAM data descriptors.
- esp_aes_process_dma(): process the block-aligned part and the partial
block as two separate DMA operations, keeping each descriptor list
uniform
- crypto_dma_ll_reset(): also reset the in-channel (per the TRM receive
reset sequence), otherwise stale state from a preceding external-RAM
operation corrupts the next operation's output
The GCM DMA path is unaffected; it never operates on PSRAM buffers.
esp_crt_check_bundle() read the 4-byte certificate header (name_len,
key_len) via esp_crt_get_len() after only checking that the cert's
start offset lies inside the bundle, so a crafted bundle whose first
or last certificate starts within the final 3 bytes caused a transient
out-of-bounds read of up to 3 bytes before the extent check rejected
it. Require the whole header to lie inside the bundle before reading
it.
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.
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.
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.
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.
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.
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
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
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.
- 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
In case of ESP32-C5 and ESP32-C61, mmu_ids for PSRAM and Flash
MMU are the same due to their shared memory space. Thus, instead of
mmu_id we should use mmu_target_t.
harshal.patil
