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>
We want to support builds where there are no platform entropy
sources (`MBEDTLS_NO_PLATFORM_ENTROPY` enabled), and no custom entropy
sources (`MBEDTLS_ENTROPY_HARDWARE_ALT` disabled), but
`mbedtls_entropy_init()` sets up a working entropy without needing to add
sources manually with `mbedtls_entropy_add_source()`
(`MBEDTLS_NO_DEFAULT_ENTROPY_SOURCES` disabled) thanks to a nonvolatile seed
file injected outside the library's control (`MBEDTLS_ENTROPY_NV_SEED`
enabled).
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>
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>
As the definition of psa_pake_operation_s has
been moved the "xyt_t" structure types can not
be used anymore (defined later).
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
In crypto_extra.h, move PAKE size calculation macros,
the definition of psa_pake_cipher_suite_s and
psa_pake_operation_s just after PAKE type and values
definitions.
This aligns with the order of crypto header inclusions
in crypto.h: crypto_types.h, then crypto_values.h,
then crypto_sizes.h, and then crypto_struct.h.
Take care of keeping them outside of the pake Doxygen
group as they used to be.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
That way when API are declared, the types they use are defined.
This should resolve the issues related to psa_xyz_init functions
returning a structure described in #7087.
Signed-off-by: Ronald Cron <ronald.cron@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>
