The function will be used by
mbedtls_ssl_read_early_data() as well.
Signed-off-by: Jerry Yu <jerry.h.yu@arm.com>
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Improve the definition of mbedtls_test_thread_t to assist adding future
threading implementations, when they happen.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
Make sure we hold the mutex whilst making several changes at the same
time, to prevent race condition on writing connected bits of data.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
It is useful to do this for the call in get_and_lock_key_slot.
Documenting that get_and_lock_key_slot_in_memory requires the mutex
is not part of this PR
Signed-off-by: Ryan Everett <ryan.everett@arm.com>
The goal is to test all the bignum's functions that accept a buffer
and its length and verify that they do not crash if a NULL pointer
is passed in as buffer and 0 length is specified.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Linux/Aarch64: support SHA acceleration detection with older libc
On Linux on aarch64 (64-bit ARMv8) processors, we use getauxval() to detect
whether the runtime environment supports SHA-256 or SHA-512 acceleration.
Some libc do not define the necessary HWCAP_xxx constants to analyze the
result of getauxval(), either because they don't bother or because they're
too old to recognize the values we need (for example, HWCAP_SHA2 appeared in
Glibc 2.24 and HWCAP_SHA512 appeared in Glibc 2.27). In such cases, assume
that the values are the same as in the kernel ABI and define the constants
manually.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Signed-off-by: Dave Rodgman <dave.rodgman@arm.com>
mbedtls_pk_get_psa_attributes() actually works without having initialized
the PSA subsystem, because it doesn't call any non-client PSA API functions.
But the function is only useful in conjunction with the PSA API: it's
meant to be followed by importing a key with the resulting attributes. We
don't advertize it to work without an up-and-running PSA subsystem, and
there's no need to test it without an up-and-running PSA subsystem as we
were (accidentally) doing.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Release: v23.06_API1.5_ADAC_EAC
This fixes all the issues that were previously added as exceptions.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
We do not require linearizability in the case of destroying a key in use.
Using a key and destroying it simultaneously will not cause any issues
as the user will only use the copy of the key in the slot.
Two simulatenous deletion calls to one key cannot interfere, the first caller
sets the slot's state to PENDING_DELETION, the second caller will back off.
Remove outdated comment about one key being in multiple slots, psa_open_key
does not put the key into a new slot.
Signed-off-by: Ryan Everett <ryan.everett@arm.com>
