The combination of the multi-byte loop with the single byte loop
confuses GCC 14.3's array bounds checker. When the loop size is
constant, check to see if it is a multiple of the multi-byte size and
bail early. As this will be evaluated at compile time, there should be
no run-time cost.
This change uses the __builtin_constant_p compile-time operation. To
check if that is supported, the change uses the existing
MBEDTLS_HAS_BUILTIN macro. That macro was defined later in
library/common.h than is needed for this change, so it was moved up to
join some other macros that looked similar.
Signed-off-by: Keith Packard <keithp@keithp.com>
Integrators in a client-server architecture need to provide this function on
the client side.
Fixesmbedtls/issues#10341.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This is meant to hold threading-related definitions that are not public, but
are used in the test framework.
To be populated later.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Don't test `make clean` at the toplevel, that would be too much work (we'd
need to support `$(RM)` in all makefiles, and arrange for `find` as well for
`clean_more_on_top`).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Fix `make lib GEN_FILES=` attempting to rebuild
`psa_crypto_driver_wrappers*` if the files' timestamps are older than their
dependencies. Turning off `GEN_FILES` is supposed to avoid that.
Fixes#10335.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Add a custom target that depends on crypto
generated files, and make both the static and
shared crypto libraries depend on it.
This ensures that when both libraries are built,
the files are not generated concurrently
by the static and shared library targets.
Do the same for the TLS libraries.
Signed-off-by: Ronald Cron <ronald.cron@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>
This is mostly unrelated to other commits in this PR, except for the
fact that one of the added X.509 tests revealed that with UBSan.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
When passed a zero-length val, the function was free-ing the buffer as
the documentation suggests:
* \param val_len The minimum length of the data buffer needed.
* If this is 0, do not allocate a buffer for the associated
* data.
* If the OID was already present, enlarge, shrink or free
* the existing buffer to fit \p val_len.
However it kept the previous length, leaving the val structure in the
corresponding item in the output list in an inconsistent state:
p == NULL but len != 0
As a result, functions that would try using this item in the list
(including the same function!) afterwards would trip an dereference the
NULL pointer.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
If we do not generate error.c, version_features.c, ...
then they are supposed to be in the source tree.
The CMake build get them from here and there is no
need for a symbolic link or a copy in the build tree.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
