For certain data lengths, the last input descriptor was not getting appended
correctly and hence the EOF flag in the DMA descriptor link list was
set at incorrect location. This was resulting in the peripheral being
stalled expecting more data and eventually the code used to timeout
waiting for the AES completion interrupt.
Required configs for this issue:
CONFIG_MBEDTLS_HARDWARE_AES
CONFIG_SOC_AES_SUPPORT_DMA
This observation is similar to the issue reported in:
https://github.com/espressif/esp-idf/issues/10647
To recreate this issue, start the AES-GCM DMA operation with data length
12280 bytes and this should stall the operation forever.
In this fix, we are tracing the entire descriptor list and then appending the
extra bytes descriptor at correct position (as the last node).
DMA operation completion must wait until the last DMA descriptor
ownership has been changed to hardware, that is hardware is completed
the write operation for entire data. Earlier for the hardware GCM case,
the first DMA descriptor was checked and it could have resulted in some
race condition for non interrupt (MBEDTLS_AES_USE_INTERRUPT disabled) case.
SHA hardware DMA mode calculation had off-by-one error for specific
input lengths. This was causing last chunk of the input data not being
fed to the hardware accelerator and hence resulting in an incorrect
final result.
Closes: https://github.com/espressif/esp-idf/issues/11915
- Earlier, some intermediate return values were not stored and returned,
thus incorrect return values used to get transmitted to the upper layer of APIs.
- Also, zeroised the output buffer in case of error condition.
The number of the DMA descriptors allocated for certain length (e.g.,
8176) were not sufficient (off by 1 error). This used to result in the
dynamic memory corruption as the region was modified beyond the
allocated range.
This change fixes the DMA descriptor calculation part and allocates
sufficient DMA descriptors based on the data length alignment considerations.
Test has also been added to cover the specific scenario in the CI.
Closes https://github.com/espressif/esp-idf/issues/11310
Purpose:
This will allow for easily automating periodic updates to
"cacrt_all.pem" file.
Note:
For now newly created "cacrt_local.pem" contains single "DST Root CA X3"
which we are keeping to manage compatibility with endpoints like
"howsmyssl.com". Please note this Root CA is expired and is not part of
Mozilla’s NSS root certificate store.
- Fixed logs expecting different format specifier
- Updated ignore list for check_public_header test
- Updated functions ported from mbedTLS
- Fix for make-system build errors
- Removed code regarding MBEDTLS_DYNAMIC_FREE_PEER_CERT
(config was kept for backward compatibility)
- Combined mbedTLS v2.28.x related options under a separate Kconfig menu
In commit de22f3a4e5, combination of
hardware and software MPI (bignum) related approach was used to
work around chip (e.g. ESP32-C3) limitation of max 3072 bits support.
This was done using linker "--wrap" flag but since the relevant API is
being used in same translation (compilation unit), hardware mode was not
getting used in some cases (e.g., RSA key generation).
This commit modified internal mbedTLS API and makes software+hardware
combination deterministic.
