Hi Soby,
Hi Ken,
Thanks for your replies.
As mentioned before, majority of device vendors already provide system files (CMSIS standard) which configure also FPU.
Take a look for example at the system file provided for STM32L5xx device family (part of STM32CubeL5 FW):
Porting TF-M to a new device should be even simpler when such files can be used directly (or with as less modifications as possible). I’m not just looking at the few platforms that are directly supported within TF-M repo but rather how
to reduce efforts to enable TF-M on any CMSIS-Core compliant device.
Note: If current system files provided by vendors do not properly configure security features then this should be highlighted.
Best regards,
Robert
From: TF-M <tf-m-bounces@lists.trustedfirmware.org>
On Behalf Of Soby Mathew via TF-M
Sent: Wednesday 2 September 2020 16:00
To: Ken Liu <Ken.Liu@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 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