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