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).
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.
The CVE is applicable with Clang using LLVM's select-optimize feature. ESP-IDF uses GCC as default compiler and sets -Os as the default optimisation flag
By default MBEDTLS_FS_IO option in mbedtls uses the filesystem supported
added by vfs component.
If the vfs support is disabled by user then mbedtls raises a warning
that the filesystem realted operation shall always fail
This commit fixes the behaviour by enabling respective depedency check for the
MBEDTLS_FS_IO option
Closes https://github.com/espressif/esp-idf/issues/14409
The ECDSA peripheral before ECO5 of esp32h2 does not perform the ECDSA
sign operation in constant time. This allows an attacker to read the
power signature of the ECDSA sign operation and then calculate the
ECDSA key stored inside the eFuse. The commit adds a countermeasure
for this attack. In this case the real ECDSA sign operation is
masked under dummy ECDSA sign operations to hide its real power
signature
1) pre-shift GCM last4 to use 32-bit shift
On 32-bit architectures like Aarch32, RV32, Xtensa,
shifting a 64-bit variable by 32-bits is free,
since it changes the register representing half of the 64-bit var.
Pre-shift the last4 array to take advantage of this.
2) unroll first GCM iteration
The first loop of gcm_mult() is different from
the others. By unrolling it separately from the
others, the other iterations may take advantage
of the zero-overhead loop construct, in addition
to saving a conditional branch in the loop.
Disabling this config can reduce footprint for the cases where
mbedtls_strerror() is used and hence the debug strings are getting
pulled into the application image.
