Hi TF-Mers,
Happy new year!
Till now, the core has evolved much and keep evolving. Let's take a breath before we go further, some updates are on the table and wait for comments. Most of the core changes will not affect the usage, but there do have interface related parts needs to be mentioned. Here are the overall topics for comments:
- SPM/core sources renaming and changes, I think this part won't affect user much except those who copied sources into your own project and do the integration.
- The HAL design is on the way, this part do affect the existing platform integration, please take apart in the discussions for this topic (The design would come first).
- Some interface sources changing. Those PSA APIs won't be changed, but the folder name and place may be updated so you may need to change your project setting.
We also got some new features, the design would go first and they would be merged after the update is done (Ideally ;)). Such as interrupt logic/test publish.
These changes are trying to make the platform integration easier, so your feedback is important before these changes take place. And, it also makes the contribution to core logic easier. If you find something is missing, feel free to propose it here and we can discuss how much we could cover.
The detailed topics would be sent one by one (avoid makes everyone too busy).
Please put comments ;)
Thanks
/Ken
Almost miss the link 😉
https://review.trustedfirmware.org/c/trusted-firmware-m/+/2964
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: Monday, December 30, 2019 6:45 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Initialize IPC SPM in handler mode
Hi,
The existing SPM initialization is done in thread mode with PSP, because library model needs to enumerate the partition initialization function in thread mode. And IPC SPM re-uses the code so it is get initialized in this mode, too.
For IPC SPM, it needs to initial thread context and push the initial EXC_RETURN context in each thread’s stack, and the veneer thread (which belongs to non-secure partition instance) re-uses the stack of initial thread mode. This may cause problem since SPM is manipulating the stack it is now standing on. It does not cause problem now is because SPM initialization is working at the low end of stack pointer while the thread context is written at high end stack bottom, and SPM initialization would not return to thread, it just enters PendSV and then go away.
So SPM must work under MSP to avoid touching his standing place – and, the used part of initial thread stack needs to be clean up, for security issues. Now we can’t find a better way to clean both the used PSP stack and the MSP stack, unless we clear the PSP manually while working with MSP, and do a EXC_RETURN from handler mode to reset the MSP stack usage by hardware.
The patches is on the way for this purpose – and follows the patches of jumping to ns without cmse call – cmse call consumes secure stack during the calling while we want a known stack position to identify the caller frames in handler mode.
Patches would come later (I am testing if it could on different platforms).
Thanks.
/Ken
