Yes, that idea would resolve the problem.
I’m not sure I understand the use case for multiple updates to a context’s client Id. What is the thought behind that?
Alan
On Mar 28, 2019, at 2:23 AM, Miklos Balint via TF-M tf-m@lists.trustedfirmware.org wrote:
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
-- TF-M mailing list TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m
That would be e.g. along the lines of policies being determined by NS privileged code that provides runtime updates to policies without having to negotiate changes with the secure-side "master" policy manager. For sure this is not needed in all cases, but I'm thinking why not provide the choice if it doesn't break the security model. This is again an option the system integrator can choose not to enable, in which case it could be removed from a particular deployment - or turned off in the build env. if a configuration option is provided in the upstream.
Regards Miklos
-----Original Message----- From: DeMars, Alan ademars@ti.com Sent: 28 March 2019 12:04 To: Miklos Balint Miklos.Balint@arm.com Cc: tf-m@lists.trustedfirmware.org; nd nd@arm.com Subject: Re: [EXTERNAL] Re: [TF-M] Please explain tfm_register_client_id() use case
Yes, that idea would resolve the problem.
I’m not sure I understand the use case for multiple updates to a context’s client Id. What is the thought behind that?
Alan
On Mar 28, 2019, at 2:23 AM, Miklos Balint via TF-M tf-m@lists.trustedfirmware.org wrote:
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
-- TF-M mailing list TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m
tf-m@lists.trustedfirmware.org
-
DeMars, Alan -
Miklos Balint