Almost miss the link 😉

https://review.trustedfirmware.org/c/trusted-firmware-m/+/2964

/Ken

From: TF-M <tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: Monday, December 30, 2019 6:45 PM
To: tf-m@lists.trustedfirmware.org
Cc: nd <nd@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