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>
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>
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>
