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.
- 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
- GCM operation in mbedtls used ECB, which calculated only 16 bytes of data each time.
- Therefore, when processing a large amount of data, it is necessary to frequently set hardware acceleration calculations,
- which could not make good use of the AES DMA function to improve efficiency.
- Hence, GCM implementation is replaced with CTR-based calculation which utilizes AES DMA to improve efficiency.
This function removes the following legacy atomic CAS functions:
From compare_set.h (file removed):
- compare_and_set_native()
- compare_and_set_extram()
From portmacro.h
- uxPortCompareSet()
- uxPortCompareSetExtram()
Users should call esp_cpu_compare_and_set() instead as this function hides the details
of atomic CAS on internal and external RAM addresses.
Due to the removal of compare_set.h, some missing header includes are also fixed in this commit.
1) Fix build issue in mbedtls
2) skip the public headers check in IDF
3)Update Kconfig Macros
4)Remove deprecated config options
5) Update the sha API according to new nomenclature
6) Update mbedtls_rsa_init usage
7) Include mbedtls/build_info.h instead of mbedtls/config.h
8) Dont include check_config.h
9) Add additional error message in esp_blufi_api.h
The following files were deleted:
- components/esp_hw_support/include/soc/cpu.h
- components/soc/esp32s3/include/soc/cpu.h
The following functions are deprecated:
- get_sp()
The following functions declared in soc/cpu.h are now moved to esp_cpu.h:
- esp_cpu_configure_region_protection()
The following functions declared in soc/cpu.h are now moved to components/xtensa/include/esp_cpu_utils.h:
- esp_cpu_process_stack_pc()
All files with soc/cpu.h inclusion are updated to include esp_cpu.h instead.
Signed-off-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
peripheral enable/disable usually should be managed by driver itself,
so make it as espressif private APIs, not recommended for user to use it
in application code.
However, if user want to re-write the driver or ports to other platform,
this is still possible by including the header in this way:
"esp_private/peripheral_ctrl.h"
Removed the old dynamically allocated GDMA channel approach.
It proved too unreliable as we couldn't not ensure consumers of the mbedtls
would properly free the channels after use.
Replaced by a single shared GDMA channel for AES and SHA, which won't be
released unless user specifically calls API for releasing it.
