Support for arbitrary callbacks into PSA Crypto from within driver entry points

[adeaarm]

Suggested enhancement

Mbed TLS currently does not specify what is allowed and what is forbidden to be called from within a driver entry point implementing the PSA cryptoprocessor driver interface. For example, a driver entry point could be calling back into PSA Crypto to perform an arbitrary crypto operation, leading to another re-entry into a PSA Crypto API.

An example could be in the function psa_get_and_lock_key_slot() which interacts with the builtin key management system through psa_load_builtin_key_into_slot(), i.e. a function which accesses driver entry points again to load opaque keys (i.e. a builtin keys). This can lead to a situation where the state of the PSA Crypto APIs must remain consistent subject to re-entry. Generally speaking, this is something which can be related also to re-entrancy due to support for multithreading (even though currently the code is not thread-safe yet, in general, see this issue ).

So one particular problem connected to this (but not limited to this particular example in the general case) is that the PSA Crypto way of requiring an empty key slot to be filled with keys is not reentrant. An empty key slot is returned by psa_get_empty_key_slot() but is marked as occupied iff the type attribute is non-zero (see the source code ). This means that if a function which fills a slot is interrupted and re-entered it can be in a non-consistent state if a concurrent context has been trying to require and fill the same slot.

To summarise, this possible enhancement is directly connected to several topics:

• The programming model associated to PSA Crypto drivers entry points following the cryptoprocessor spec;
• The support for re-entrant code when multithreaded support is enabled
• More specifically, the concept of "occupied" slot during a slot request operation (e.g. a slot in the process of being filled can't be locked through mutual exclusion if the programming model of the drivers, for example, allows call backs into PSA Crypto, to avoid deadlocks). It's quite closely related to how PSA Crypto decides to evolve the interface for builtin keys.

Justification

Mbed TLS needs this to achieve eventually thread-safety in PSA Crypto, to support specific use cases and increase flexibility, to achieve a more mature support for the cryptoprocessor driver spec.