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>
These all follow a pattern of locking some key slot,
reading its contents, and then unregistering from reading the slot.
psa_copy_key also writes to another slot,
but calls the functions needed to be threadsafe.
Signed-off-by: Ryan Everett <ryan.everett@arm.com>
Between the call to psa_get_and_lock_key_slot and psa_unregister_read
we only read the contents of a slot which we are registered to read,
so no extra mutex taking is needed.
Signed-off-by: Ryan Everett <ryan.everett@arm.com>
There are at least 20 occurences in the current code where
we will need this pattern of code, so I thought it best to
put this in a function
Signed-off-by: Ryan Everett <ryan.everett@arm.com>
Document that callers must hold the key slot mutex.
Change the volatile key checking behaviour so that it
doesn't read the contents of non-FULL slots.
Signed-off-by: Ryan Everett <ryan.everett@arm.com>
These calls otherwise don't abide by our assertions about changing the slot.
psa_get_and_lock_key_slot, the only caller to these, handles the state
transitions already. It also changes the contents of the slot after these calls.
Signed-off-by: Ryan Everett <ryan.everett@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>
