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>
They can cause specific challenges when debugging, so move them out for
maintainers' convenience.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
They can cause specific challenges when debugging, so move them out for
maintainers' convenience.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The openssl version in the docker image doesn't support TLS 1.3, so we
can't run the test.
Signed-off-by: Max Fillinger <maximilian.fillinger@foxcrypto.com>
HKDF-Expand can produce at most 255 * hash_size bytes of key material,
so this limit applies to the TLS 1.3 key material exporter.
Signed-off-by: Max Fillinger <maximilian.fillinger@foxcrypto.com>
We were not making enough room. We want to move everything from the
place where we are going to insert the new record.
This was not causing failures because the code does not look at the
content after the inserted record, because it correctly returns an error
when seeing the inserted record. But as a matter on principle, the test
code should be doing what it says: just insert a new record but leave
a valid fragment after it.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This one is overly tight: TLS 1.3 actually only depends on
ChachaPoly || (AES && (GCM || CCM))
Furthermore, this should really be reflected in check_config.h.
Individual test cases should be able to just request PROTO_TLS1_3 and
know that there is ciphersuite that works.
However, resolving that seems out of scope for this PR. (It would also
involve updating depends.py for example.)
So, use a dependency that's stricted than necessary. IMO it's still good
enough as most configs we test will have ChachaPoly. However it would be
good to revisit this when a cleaner solution is implemented.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
