Ryan Everett

I have addressed the uncontroversial issues with this PR. The test coverage comments and HMAC comments may need some more discussion before a change can be made.

I am also not sure whether this needs a 3.6 backport. The ABI checker hasn't failed here, so perhaps it does.

There are some inefficiencies in the locking here. We hold the mutex for some operations which we do not strictly need to hold it for when loading persistent keys (see...

Just to clarify. Do not review the first 4 commits, these are part of a separate PR which has been approved.

I am reverting the changes to `psa_reserve_free_key_slot` and instead will wrap the call in a LOCK; call; UNLOCK; style. This is a minor change for this PR (since this function...

I used Github to try to bring this fork up to date with upstream/development (no conflicts) but it created a merge PR. Sorry about this. @paul-elliott-arm should I force push...

> Looks pretty good to me, however I am curious as to why the `psa_unregister_read() `in `psa_destroy_key()` remains unguarded. `psa_destroy_key` was covered by #8764, do you mean a different function?...

> > > Looks pretty good to me, however I am curious as to why the `psa_unregister_read() `in `psa_destroy_key()` remains unguarded. > > > > > > `psa_destroy_key` was covered...

> In the description it says > > > All calls to psa_register_read, psa_unregister_read, psa_key_slot_state_transition, psa_wipe_key_slot and psa_key_slot_has_readers are performed under the global mutex > > but there are a...