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>
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>
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>
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>
The commented out tests cause crashes (in different ways) until the bug
is fixed; the first two test are passing already and are here mostly to
provide a reference point.
The bug report was using programs/x509/cert_write, but string_to_names()
is what it was really targetting, which is better for automated tests.
The strings used are a minor adapation of those from the report.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Partially undo "Use short initializers for multipart operation structures",
only in test functions that specifically aim to test initializers. In these
functions, do try with the short initializers, but alongside the standard
ones.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
When initializing a multipart or interruptible operation structure, use an
auxiliary function that doesn't initialize union members to all-bits-zero.
Context: on most compilers, initializing a union to `{0}` initializes it to
all bits zero; but on some compilers, the trailing part of members other
than the first is left uninitialized. This way, we can run the tests on any
platform and validate that the code would work correctly on platforms where
union initialization is short.
This commit makes a systematic replacement in `test_suite_psa_crypto.function`
and `test_suite_psa_crypto_driver_wrappers.function`, which gives good
enough coverage.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The goal of testing with GCC 15 is to validate fixes for
https://github.com/Mbed-TLS/mbedtls/issues/9814 . The bug is present in
multiple places, and some of them affect third-party drivers but not our
built-in implementation. (The bug is that driver contexts might not be
zero-initialized, but some of our built-in implementations happen not to
care about this.) Thus, enable the test drivers in the test component that
uses GCC 15, to gain the extra checks performed in the driver wrappers.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This is a new warning in GCC 15 that our code base triggers in many places.
Silence it for the time being.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
