Hi Chris,
NSCE interfaces are exported as functions which can be called by NS applications directly. When the exported functions are called by NS apps, there is no chance to route to the RTOS kernel.
One of the possible choices is to call NSCE API from RTOS kernel. So that RTOS kernel can directly pass the current NS client ID to secure world. And that’s the reason why secure code is required – to wait for call from RTOS kernel and update the NS client ID in secure world.
In the origin design, NSCE adds specific support on diverse use scenarios. But seems they are in little use, so later we can simplify the logic of NSCE.
Best regards, Xinyu
From: Chris.Brand--- via TF-M tf-m@lists.trustedfirmware.org Date: Wednesday, October 25, 2023 at 07:26 To: tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.org Subject: [TF-M] Non-secure client id management Hi,
Reading through https://tf-m-user-guide.trustedfirmware.org/integration_guide/non-secure_cli... I’m wondering why so much of the work is done in the secure world. Ultimately, the secure world relies on the non-secure world to tell it the client_id, directly or indirectly. Is there a good reason for the NCSE part to reside in the secure world, rather than the non-secure? Particularly as the document states that the non-secure RTOS may have a built-in “Secure Context Manager”, there may well be redundancy between that and NCSE that could be eliminated if the NCSE was in the NSPE. And the less code there is in the secure world, the less scope for vulnerabilities.
If client_ids themselves were passed from the NS to the S world, it would probably be very easy to use that same interface on the NS core in a dual core system, too.
Chris