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.
fix(bt/bluedroid): fixed the function prototype of the command handler of READ LOCAL SUPPORTED CODECS.
Closes BTQABR2023-888
See merge request espressif/esp-idf!51832
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.
Introduce a seq_cst closing gate shared by the runtime and the LBM:
submitters increment the reference count before checking the inited
flag, and deinit closes the gate and waits for the count to drain
before deleting tasks, timers, queues, or buffers. A producer either
observes shutdown or its reference is visible to the wait, which makes
ble_log_deinit safe while write APIs are still active.
Submitters no longer block on the queue while holding a reference: a
timeout-0 send that cannot queue recycles the transport so its data
survives for the next flush.
Extract ble_log_ref_count_try_acquire/wait into the utility layer and
gate every LBM writer through ble_log_lbm_ref_acquire. ble_log_deinit
now closes the LBM gate first (ble_log_lbm_close) instead of clearing
the enable flag.
Move transport ownership from the runtime to the LBM: submit and
recycle now hand the peripheral-owned flag explicitly instead of the
runtime reaching back into LBM buffers. The submit path never blocks
producers - a transport that cannot be queued is recycled immediately
so its data survives for the next flush.
Cross-context ownership accesses go through explicit atomic helpers:
release-store on recycle pairs with acquire-loads in the flush paths,
and the inflight high-water mark stays a relaxed CAS-max (a plain
volatile update races the runtime hook's statistics reads).
