With MBEDTLS_PSA_ASSUME_EXCLUSIVE_BUFFERS enabled, an in-place
psa_cipher_update() reaches the selected cipher implementation without
defensive buffer copies. The ESP AES PSA driver accepts an in-place
update of any length for CTR (PSA classifies CTR as a stream cipher, so
the driver's block_length is 1), but on targets without the AES
peripheral (e.g. ESP32-C61) the operation falls back to the mbedtls
builtin cipher layer, which rejects in-place updates whose length is
not a multiple of the block size (MBEDTLS_ERR_CIPHER_BAD_INPUT_DATA,
surfacing as PSA_ERROR_INVALID_ARGUMENT).
Round the in-place test length down to a block multiple when
CONFIG_MBEDTLS_HARDWARE_AES is not set; partial-block PSRAM coverage is
retained through the separate-buffer alignment tests.
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.
Both PSRAM layouts were mapped as a single RWX window, so everything in external
RAM - the heap included - was executable.
PSRAM used as data only is now RW, and under XIP-from-PSRAM it is split per
section as ESP32-P4 does: .text RX, .rodata read-only, and the MMU-page
alignment gaps and the reclaimed heap RW, so neither is executable.
Both describe the layout that esp_psram_init() produces, and the entries are
locked, so - again as on ESP32-P4 - they are only narrowed when
CONFIG_SPIRAM_PRE_CONFIGURE_MEMORY_PROTECTION says that layout applies. Without
it the application owns the region and PSRAM stays RWX.
The per-section entries cost one PMP entry more than the 16 available, so the CPU
subsystem and peripheral windows are chained as TOR entries, taking one entry
instead of three.
soc.h is corrected against the S31 bus address map: the peripheral window base
was 1 MB too low, and the LP peripheral top, derived from a register base plus a
size rather than from the map, was 16 KB short. SOC_NON_CACHEABLE_OFFSET_FLASH
is added.
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.
harshal.patil
