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.
- Even if the config MBEDTLS_HARDWARE_AES is enabled, we now support fallback
to software implementation of GCM operations when non-AES ciphers are used.
Updates config to define the new MBEDTLS_SSL_CID_TLS1_3_PAD_GRANULARITY
option, which replaced the previously used
MBEDTLS_SSL_CID_PADDING_GRANULARITY. The old option is continuing to be
used as the new one exceeds the maximum length for an option name in
esp-idf.
See https://github.com/Mbed-TLS/mbedtls/pull/4490 for more information.
Signed-off-by: Daniel Mangum <georgedanielmangum@gmail.com>
For ESP32-H2 case, the hardware k mode is always enforced through
efuse settings (done in startup code).
For ESP32-P4 case, the software k mode is not supported in the peripheral
itself and code was redundant.
Set max TLS version in the SSL context during setup phase. Dynamic
buffer feature overrides the `mbedtls_ssl_setup` API and hence
this change is required per upstream 3.5.0 codebase change.
Add changes to use fast_pbkdf2 as default for PMK calculations.
fast_pbkdf2 is significantly faster than current implementations
for esp chips.
Also removes unnecessary code for pbkdf-sha256 and pbkdf-sha512.
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.
fix: mbedtls_ecdsa_can_do was not being defined when ECDSA_SIGN_ALT is defined but ECDSA_VERIFY_ALT is not defined causing mbedtls_ecdsa_verify_restartable to always fail.
feature: initial version of the sbom.yml file
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
ADDITIONAL_MAKE_CLEAN_FILES is deprecated and only worked with make.
Replaced with the new ADDITIONAL_CLEAN_FILES (CMake 3.15) which also works with ninja.
