Hi,
We created a proposal to define a minimal set of compiler specific-definitions for SPM. The reason is to avoid many #ifdef inside SPM code.
Only limited definitions are defined. Platform sources need to use platform defined headers for these definitions, such as CMSIS headers.
Special usage such as 'weak' or 'noreturn' are forbidden inside SPM.
Please put comments for this change:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4211
Or reply here.
This is just an example patch, the follow up would apply this defined headers to all SPM sources.
Thanks
/Ken
Hi all,
In the current implementation, every secure function has an associated veneer function. Therefore, there are so many veneer functions in ‘tfm_veneers.c’, which have a similar prototype.
This would lead to:
* Waste of the veneer and secure function size – these APIs have a similar prototype, and they have unified NS dispatcher already.
* More secure functions lead to more veneers and potential re-configuration of the non-secure callable area.
This patch tries to unify the service entry so that:
* Similar function codes do not need to be duplicated.
* Keeping almost the same performance.
This is also an experiment patch to start the journey to the SFN model Andrew proposed. Let’s see the feedbacks and decide what to do in the next step.
https://review.trustedfirmware.org/c/trusted-firmware-m/+/4115
Please do feedback, especially the library model users – please check what kinds of the inconvenience it brings so that we can discuss the correct shape.
Here are some details in the patch:
Prototype of the unified veneer function:
psa_status_t tfm_sfc_call(uint32_t ctrl, psa_invec *in_vec, psa_outvec *out_vec);
where:
the uint32_t type parameter ‘ctrl’ is a pack of parameters - psa invec length, psa outvec length, and function identifier.
[8 bits for inlen][8 bits for outlen][16 bits for function identifier]
This is to avoid the condition that 5 parameters will cause re-wrapping of parameters.
Time cost and code size measurement:
github-tracking
Use the unified veneer
cost of a veneer call is 1264
cost of an interrupt is 941
veneer used 832B, region size 832B, 100%
cost of a veneer call is 1274
cost of an interrupt is 941
veneer used 64B, region size 832B, 7.69%
Thanks,
Mingyang
Hello,
I would like to understand the background behind roadmap item "Provisioning" that is mentioned here [1] (Slide 31) and here [2].
What provisioning functionality would we be talking here, is it provisioning as in "RoT provisioning", so more towards manufacturing as defined in the PSA security lifecycle, or provisioning when the device is in state "Secured", so more towards application specific-data? I would assume the latter, but couldn't find any more information on this subject. Any pointers would be highly appreciated.
Thanks for your help & kind regards,
Gernot
[1] https://static.linaro.org/connect/san19/presentations/san19-203.pdf
[2] https://developer.trustedfirmware.org/w/tf_m/planning/
Hi,
Even the ongoing HAL design abstracts all platform-specific operations, there are still some operations that need to be performed directly in TF-M, such as architecture-related operations.
These operations are common for all platforms, such as:
* generic assembler code for AAPCS based context management.
* assign attributes to specific functions.
These operations rely on compiler and architecture much instead of the platform. So, define a CORE-specific compiler configuration header file would be a straight requirement. With these unified headers, writing the architecture-specific code would be much safer because it won't involve hardcode compiler related changes. The minimal set of mandatory architecture registers is also planned to be defined.
Here send out a mail to collect for the feedbacks - is it worthy of doing this to decouple the architecture from the platform, or we can just re-use the platform provided headers?
Any comments are welcome:)
Best Regards,
Summer
