When MBEDTLS_HARDWARE_GCM is enabled, we ALT all the GCM functions that are
declared in mbedtls/gcm.h with our H/W port functions, due to which even
if non-AES ciphers such as ARIA, CAMELLIA, BLOWFISH, etc. are selected
for a GCM operation, we perform an AES-GCM operation, thus resulting into
an incorrect calculation.
Thus in such cases we need to fallback to the software definitions of
GCM.
Currently, it is not directly possible to pull in software definitions of GCM
related functions directly due to gcm_alt.h, but this commit renames the
functions by appending `_soft` to their names, thus making them look different
functions in all and thus they are made available to pull in during compilation.
The change is configrable using the config MBEDTLS_GCM_NON_AES_CIPHER_SOFT_FALLBACK.
As this config is enabled by default, building the mbedtls crypto library
(libmbedcrypto.a) with this change increases its size by ~2.5KB.
This is an initial version of the sbom.yml file for Espressif's mbedtls.
It's used by the esp-idf-sbom[1] tool to generate an SBOM file in the SPDX
format for esp-idf projects.
[1] - https://github.com/espressif/esp-idf-sbom
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
fix(sbom): add note about Espressif modifications
Since our mbedtls code is not a pure upstream version, let's add a note
about this in the SBOM manifest description, which will be included in
the generated SPDX file. We used the same approach e.g. for freertos.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
- `CMAKE_C_EXTENSIONS`: Enable/disable compiler-specific extensions
- `CMAKE_C_STANDARD`: Set C standard (C99, C11)
- These variables (as set in mbedtls) set the C standard to C99
for ESP-IDF as well, resulting in build errors related to
`asm volatile`
(cherry picked from commit e39975969d548572a39875ad29abd88b23285f94)
- ESP32C2 has a hardware ECC accelerator that supports NIST P-192 and NIST P-256 curves,
which can increase the performance of the point multiplication and point
verification operation.
- Provision is also added to fallback to software implementation in
case the curve is not from the supported curves
- Override ecp_mul_restartable_internal with accelerator
- Many ECC operations use the internal API ecp_mul_restartable_internal
instead of the public API mbedtls_ecp_mul for point multiplication.
This will improve the performance of all those parent operations as
well
(cherry picked from commit 0ecb27b9d88059e8980c8ae6e111283f5f2859f8)
For exponential mod (API mbedtls_mpi_exp_mod) operation, some ESP target
chips needs to have ability for both hardware and software implementation.
Hardware implementation provided performance advantage but it can only
support upto 3072 bit operations (e.g., ESP32-C3) and hence we fallback
to software implementation in such cases (e.g., 4096 bit operations).
Earlier this was handled using linker "--wrap" flag but that does not
work in all scenarios as API `mbedtls_mpi_exp_mod` is being used in
same tranlation (compilation unit).
This approach was found to be next best option with minimal changes in
mbedTLS library.
(cherry picked from commit ab3a845107377c6cdf148f86015cad94434a1f2e)
In some cases, we were calling `mbedtls_test_ssl_endpoint_free()` on an
uninitialized `mbedtls_test_ssl_endpoint` object if the test case failed
early, e.g. due to `psa_crypto_init()` failing. This was largely harmless,
but could have caused weird test results in case of failure, and was flagged
by Coverity.
Use a more systematic style for initializing the stack object as soon as
it's declared.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Now that Base64 validates the number of trailing equals, adjust the PEM test
case that has a Base64 payload with a wrong number of trailing equals, where
`mbedtls_pem_read_buffer()` now returns a different error code. I'm not sure
what the exact intent of the test was, so add a variant with trailing equals
as well.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Fix a race condition in `mbedtls_aes_ni_has_support()` with some compilers.
A compiler could hoist the assignment `done = 1` above the assignment to `c`,
in which case if two threads call `mbedtls_aes_ni_has_support()` at almost
the same time, they could be interleaved as follows:
Initially: done = 0, c = 0
thread A thread B
if (!done)
done = 1; # hoisted
if (!done)
return c & what; # wrong!
c = cpuid();
return c & what
This would lead to thread B using software AES even though AESNI was
available. This is a very minor performance bug. But also, given a very
powerful adversary who can block thread A indefinitely (which may be
possible when attacking an SGX enclave), thread B could use software AES for
a long time, opening the way to a timing side channel attack.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Correct base64 input (excluding ignored characters such as spaces) consists
of exactly 4*k, 4*k-1 or 4*k-2 digits, followed by 0, 1 or 2 equal signs
respectively.
Previously, any number of trailing equal signs up to 2 was accepted, but if
there fewer than 4*k digits-or-equals, the last partial block was counted in
`*olen` in buffer-too-small mode, but was not output despite returning 0.
Now `mbedtls_base64_decode()` insists on correct padding. This is
backward-compatible since the only plausible useful inputs that used to be
accepted were inputs with 4*k-1 or 4*k-2 digits and no trailing equal signs,
and those led to invalid (truncated) output. Furthermore the function now
always reports the exact output size in buffer-too-small mode.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Add unit tests covering cases where the number of digits plus equal signs is
not a multiple of 4. These are invalid inputs, but they are currently
accepted as long as the number of equal signs is at most 2.
The tests assert the current behavior, not behavior that is desirable.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Reinforce the unit test for `mbedtls_base64_decode()` with valid inputs to
systematically call the function with a smaller output buffer and with an
empty output buffer. Assert the reported necessary output length in those
cases.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
