One fundamental reason for driving context changes from handler mode is to have privilege and isolation control when switching contexts. So it all boils down to the requirements of a particular deployment. If there is no compartmentalization and privilege control in NSPE, i.e. all NS threads and the OS have identical access policies to secure assets, it should be possible to lift this requirement and accept NSPE context change notifications that transition from NSPE to SPE in thread mode. This, however, only results in a performance improvement if SPE also bypasses handler mode for this operation, requiring slightly more than skin-deep modifications in TF-M to handle all possible (ab)uses of the secure context management feature. I think this can be a valid choice for a specific implementation, but support for this as a configuration switch in the upstream and threat modelling the alternate setting would be a stretch in our team's current roadmap.

/M

-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of DeMars, Alan via TF-M Sent: 13 February 2019 05:11 To: tf-m@lists.trustedfirmware.org Subject: [TF-M] tz_context APIs

Why do all the APIs declared in tz_context.h need to be called from NS Handler mode? Is this a hard requirement or can it be configured 'OFF'?

For performance reasons, our OS doesn't trap into handler mode to perform thread management like creation, scheduling, and context switching. Having to switch to handler mode without a very compelling reason seems like unnecessary overhead in performance-critical code.

Alan