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>
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>
I'm just trying to have a shorter name to avoid repeating a long
expression. This is a job for a pointer, not copying a struct.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This version is incomplete. I failed to noticed it when adding a more
complete version, making the existing one redundant.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Since Mbed TLS 3.0, blinding is no longer optional in ECDSA.
`mbedtls_ecdsa_write_signature()` and
`mbedtls_ecdsa_write_signature_restartable()` error out if
`f_rng == NULL`. We forgot to update the function documentation.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In public functions that take `f_rng, p_rng` callbacks, link to the
documentation of the callback which is attached to the type name
`mbedtls_f_rng_t`.
Resolves#5868.
```
grep -l -w 'f_rng)' include | xargs perl -i -pe 's/\Qint (*f_rng)(void *, unsigned char *, size_t)\E/mbedtls_f_rng_t *f_rng/g'
```
and include `platform_util.h` where needed.
Signed-off-by: Gilles Peskine <Gilles.Peskine@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>
This merge was done by the '-s ours' strategy. The only purpose of this
merge is to bring the commit for the 3.6.3.1 release into the
mbedtls-3.6 history and make the CI pass.
Signed-off-by: Janos Follath <janos.follath@arm.com>
In functions that bypass the API functions and call an internal MAC setup
function directly, make sure to initialize the driver-specific part of the
context. This is a union, and initializing the union to `{0}` only
guarantees that the first member of the union is initialized, not
necessarily the member used by the driver. Most compilers do initialize the
whole union to all-bits-zero, but some don't. With compilers that don't, the
lack of initialization caused failures of the affected operations. This
affected one-shot MAC operations using the built-in implementation.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In functions that bypass the API functions and call the MAC driver wrapper
`psa_driver_wrapper_mac_sign_setup()` directly, make
sure to initialize the driver-specific part of the context. This is a union,
and initializing the union to `{0}` only guarantees that the first member of
the union is initialized, not necessarily the member used by the driver.
Most compilers do initialize the whole union to all-bits-zero, but some
don't. With compilers that don't, the lack of initialization caused failures
of the affected operations. This affected several key derivation operations.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In API functions that set up a multipart or interruptible operation, make
sure to initialize the driver-specific part of the context. This is a union,
and initializing the union to `{0}` only guarantees that the first member of
the union is initialized, not necessarily the member used by the driver.
Most compilers do initialize the whole union to all-bits-zero, but some
don't. With compilers that don't, the lack of initialization caused failures
of built-in MAC, interruptible-sign and interruptible-verify. It could also
cause failures for other operations with third-party drivers: we promise
that drivers' setup entry points receive a zero-initialized operation
structure, but this promise was not kept.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
That memory leak had been present ever since the san command-line
argument has been added.
Tested that the following invocation is now fully valgrind clean:
programs/x509/cert_write san=DN:C=NL,CN=#0000,CN=foo;DN:CN=#0000,O=foo,OU=bar,C=UK;IP:1.2.3.4;IP:4.3.2.1;URI:http\\://example.org/;URI:foo;DNS:foo.example.org;DNS:bar.example.org
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The runtime error was introduced two commits ago (while avoiding a
use-after-free). Now the programs run cleanly but still leak memory.
The memory leak is long pre-existing and larger than just DN components
(which are made temporarily slightly worse by this commit) and will be
fixed properly in the next commit.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The documentation doesn't say you can't call these functions more than
once on the same context, and if you do it shouldn't result in a memory
leak. Historically, the call to mbedtls_asn1_free_named_data_list() in
mbedtls_x509_string_to_names() (that was removed in the previous commit)
was ensuring that. Let's restore it where it makes sense. (These are the
only 3 places calling mbedtls_x509_string_to_names() in the library.)
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Now programs/x509/cert_write san="DN:CN=#0000;DN:CN=#0000" is no longer
crashing with use-after-free, instead it's now failing cleanly:
failed
! mbedtls_x509_string_to_names returned -0x2800 - X509 - Input invalid
That's better of course but still not great, will be fixed by future
commits.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@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>
