A peripheral's reset also resets the ones it occupies, so a lock has to cover
both. Gate the ECDSA MPI lock on SOC_ECDSA_USES_MPI rather than the runtime
ecdsa_ll_is_mpi_required() and set that capability on C5, lock the Key Manager
path in esp_key_mgr.c, clean HMAC after its reset, and enable DS before the
primitives its reset covers.
ECDSA enable pulses a reset that also holds SHA in reset, and SHA shares
its DMA with AES. Key Manager enable pulses a reset that also covers the
XTS-AES flash encryption key-usage selector. Neither path was serialized
against those victims, so a hardware ECDSA/HMAC/DS operation could
corrupt a concurrent SHA/AES transfer or an in-flight encrypted flash
read.
- Take the SHA/AES lock inside esp_crypto_ecdsa_lock_acquire(), before
MPI, matching the DS lock order (sha_aes < mpi)
- Add esp_crypto_key_mgr_enable_periph_clk_no_reset() and switch ECDSA,
HMAC and DS to it; they only need the key-usage selector writable
- Hold esp_crypto_key_manager_lock across those clock enable/disable
pairs so selector writes stay serialized without resetting KM
esp_hmac_calculate() enabled and reset the Digital Signature (DS)
peripheral, but HMAC has no dependency on DS (the dependency runs the
other way: a DS operation uses HMAC/SHA).
The DS peripheral drives the RSA (MPI) accelerator internally, so pulsing
the DS reset also resets the RSA datapath. This coupling exists on every
target that has the DS peripheral: the MPI reset routine itself clears the
DS reset "otherwise RSA is held in reset".
esp_hmac_calculate() holds only the HMAC and SHA/AES locks, not the MPI
lock, so it can corrupt a concurrent RSA/MPI operation. On multi-core
targets (e.g. ESP32-P4, ESP32-S31, ESP32-S3) an HMAC on one core resets an
RSA op running on another core; on single-core targets (e.g. ESP32-C5) the
same corruption happens when an HMAC preempts an in-flight RSA op. The
result is a wrong RSA result or a crash in the computation.
Remove the DS peripheral enable/reset from the HMAC path. SHA, which HMAC
depends on, is enabled independently, so the HMAC output is unchanged.
This also drops a few redundant register writes.
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.
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.
- 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
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)
Encrypted flash write operation sometimes result in random corruption in
certain bytes. Root cause points to sudden current surge due to involvement of
encryption block overwhelming LDO supply. More details will be provided
in the ESP32-C5 SoC Errata document.
This fix limits the CPU clock to 160MHz for flash encryption enabled
case. Failing encrypted flash write tests could successfully pass in
this configuration. Going ahead, a dynamic clock adjustment in flash
driver will be considered to mitigate this issue.
