Hi Robert,
The current architecture abstraction depends on the some CMSIS standard macros (like __FPU_USED) to be defined and if there are vendor tools which can generate the same system file, as long as they are using the standard macros, the architecture
abstraction should work alright if the generated file can be included. As Ken says, this makes architecture initialization uniform across platforms and provides the right settings to be applied for security. It also reduces the platform porting effort for
new platforms. Hence the move in such a direction.
If we allow a mechanism to allow the platform provided system file to be used rather than the default system file, will that suffice your requirement ?
Best Regards
Soby Mathew
From: TF-M <tf-m-bounces@lists.trustedfirmware.org>
On Behalf Of Ken Liu via TF-M
Sent: 02 September 2020 11:11
To: tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: Re: [TF-M] Changes to configure FPU at the architectural level in TF-M
Hi Robert,
Thanks for the comment, just want to double check if the guidelines for vendors who providing platform sources to a secure software covers the recommendations here:
https://lists.trustedfirmware.org/pipermail/tf-m/2020-June/001007.html
As far as we can see not all existing platforms set the registers required in the above recommendation (In Jamie’s second patch), so we are trying to provide an architecture-abstraction. Meanwhile, we would notify the
platform owner checking the platform-specific setting. After all platform vendor confirmed the setting of FPU we can leave this back to platform setting as you suggested - but secure firmware core logic still needs to check if platform set the FPU setting
correctly.
@Soby @Jamie, please update if I missed something.
BR
/Ken
From: TF-M <tf-m-bounces@lists.trustedfirmware.org>
On Behalf Of Robert Rostohar via TF-M
Sent: Wednesday, September 2, 2020 5:30 PM
To: Jamie Fox <Jamie.Fox@arm.com>;
tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: Re: [TF-M] Changes to configure FPU at the architectural level in TF-M
Hi Jamie,
I have concerns with moving FPU configuration from platform to architecture-abstraction layer.
FPU configuration is typically configured within system configuration files that are standardized in CMSIS and provided by device vendors.
Some vendors provide also tools that auto-generate the system file based on user configuration (ex: STM32CubeMX).
Therefore it would be better to leave the FPU configuration to the platform rather than moving it into architecture-abstraction.
Best regards,
Robert
From: TF-M <tf-m-bounces@lists.trustedfirmware.org>
On Behalf Of Jamie Fox via TF-M
Sent: Friday 28 August 2020 19:53
To: tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: [TF-M] Changes to configure FPU at the architectural level in TF-M
Hi all,
There is a change open for review that adds configuration of FPU-related registers to the architecture-abstraction layer in TF-M, and removes this same configuration from platform support files. The reasoning for this is that these registers
are defined by the Arm architecture, so FPU config can be unified for all platforms with the same architecture.
For Armv8-M, this also includes configuration to ensure that information is not leaked in FPU registers to NSPE when the SPE uses the FPU, and to permit the NSPE to access the FPU.
By default, TF-M will still be built without the FPU used in the SPE.
You can review the changes at:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5405
Arch: Add function to configure coprocessors
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5406
Platform: Remove platform-specific FPU config
It would be especially helpful if platform owners could check that they are happy with FPU config being moved out of the platform support files.
Kind regards,
Jamie