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>
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>
This function, and mbedtls_psa_crypto_free, are not thread safe as they wipe slots
regardless of state. They are not part of the PSA Crypto API, untrusted applications
cannot call these functions in a crypto service.
In a service intergration, mbedtls_psa_crypto_free on the client cuts the communication
with the crypto service.
Signed-off-by: Ryan Everett <ryan.everett@arm.com>
Relies on get_and_lock_X being thread safe.
There are two mutex locks here, one in psa_get_and_lock...
Linearization point is the final unlock (or first lock on failure).
Signed-off-by: Ryan Everett <ryan.everett@arm.com>
There are two mutex locks here, the one performed in get_and_lock.. and the one performed outside.
Linearizes at the final unlock.
(This function is deprecated)
Signed-off-by: Ryan Everett <ryan.everett@arm.com>
`gcc-14` added a new `-Wcalloc-transposed-args` warning recently. It
detected minor infelicity in `calloc()` API usage in `mbedtls`:
In file included from /build/mbedtls/tests/include/test/ssl_helpers.h:19,
from /build/mbedtls/tests/src/test_helpers/ssl_helpers.c:11:
/build/mbedtls/tests/src/test_helpers/ssl_helpers.c: In function 'mbedtls_test_init_handshake_options':
/build/mbedtls/tests/include/test/macros.h:128:46:
error: 'calloc' sizes specified with 'sizeof' in the earlier argument
and not in the later argument [-Werror=calloc-transposed-args]
128 | (pointer) = mbedtls_calloc(sizeof(*(pointer)), \
| ^
Signed-off-by: Sergei Trofimovich <slyich@gmail.com>
Upon further consideration we think that a remote attacker close to the
victim might be able to have precise enough timing information to
exploit the side channel as well. Update the Changelog to reflect this.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Any timing variance dependant on the output of this function enables a
Bleichenbacher attack. It is extremely difficult to use safely.
In the Marvin attack paper
(https://people.redhat.com/~hkario/marvin/marvin-attack-paper.pdf) the
author suggests that implementations of PKCS 1.5 decryption that don't
include a countermeasure should be considered inherently dangerous.
They suggest that all libraries implement the same countermeasure, as
implementing different countermeasures across libraries enables the
Bleichenbacher attack as well.
This is extremely fragile and therefore we don't implement it. The use
of PKCS 1.5 in Mbed TLS implements the countermeasures recommended in
the TLS standard (7.4.7.1 of RFC 5246) and is not vulnerable.
Add a warning to PKCS 1.5 decryption to warn users about this.
Signed-off-by: Janos Follath <janos.follath@arm.com>
