Alan,

You are absolutely right that registering client ID should normally be done once, preferably right after AllocModule.

The current design allows multiple updates to be made, and for this to be possible, we identify the one to be updated by it being the active one.

I do see an opportunity to extend this so that the last NS context to be Allocated can also be assumed to be the target of a registration in lieu of the active context if there isn't one. This way we keep the option to update ID when a context is active while also allow an easy and low overhead registration for the context that's latest to have been Allocated.

Is this an acceptable amendment?

Regards Miklos

-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of DeMars, Alan via TF-M Sent: 26 March 2019 00:00 To: tf-m@lists.trustedfirmware.org Subject: [TF-M] Please explain tfm_register_client_id() use case

As currently specified, I don't see a simple way to invoke the tfm_register_client_id() API ONLY ONCE for each NS client thread.

It appears that tfm_register_client_id() must be called after TZ_LoadContext_S() because the clientId provided by tfm_register_client_id() is always associated with the CURRENT NS MemoryId.

However, TZ_LoadContext_S() is designed to be called only when the NS OS actually switches to a new NS thread. This creates pressure for tfm_register_client_id() to be called during a NS thread switch. However, calling tfm_register_client_id() on EVERY NS context switch is redundant and CPU wasteful. Adding code to test whether tfm_register_client_id() has already been called for a particular NS thread also seems wasteful.

What seems natural to me is to add a MemoryId argument to tfm_register_client_id() so that the clientID can be mapped to the MemoryId provided by TZ_AllocModuleContext_S() right after TZ_AllocModuleContext_S() is called (ie only once).

Please correct my understanding of how tfm_register_client_id() is intended to be used if the above analysis is off base.

Alan