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): https://github.com/STMicroelectronics/STM32CubeL5/blob/master/Drivers/CMSIS/...
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.orgmailto: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.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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.orgmailto: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.commailto:Jamie.Fox@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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.orgmailto: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.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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
Hi Robert, Thanks for the clarification. I see what you mean now.
The trouble with every platform replicating architectural functionality is the same code is replicated across many platforms which is not good for several reasons. Centralising these common architectural initializations, in addition to benefits mentioned earlier, will allow to add more features and deliver security hardening to all TF-M platforms in a better way. For example, say in future we want to harden certain pieces of architectural initializations against glitch attacks, or say deliver a security fix which involves the architecture initialization, having it in a single place as part of architectural abstraction will greatly benefit the project.
As I mentioned earlier, I think overall this will reduce the porting effort required if more architectural bits are done commonly. I don't see why CMSIS-Core compliant device will not get the same benefit.
Best Regards Soby Mathew
From: Robert Rostohar Robert.Rostohar@arm.com Sent: 02 September 2020 16:49 To: Soby Mathew Soby.Mathew@arm.com; Ken Liu Ken.Liu@arm.com Cc: nd nd@arm.com; tf-m@lists.trustedfirmware.org Subject: RE: Changes to configure FPU at the architectural level in TF-M
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): https://github.com/STMicroelectronics/STM32CubeL5/blob/master/Drivers/CMSIS/...
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.orgmailto: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.commailto:Ken.Liu@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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.orgmailto: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.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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.orgmailto: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.commailto:Jamie.Fox@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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.orgmailto: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.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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
Hi Soby,
Thanks for the clarifications.
I understand now the motivation to use centralized initialization which sounds reasonable.
However, I do not agree that it will reduce the porting effort in regards to system files provided by vendors under CMSIS umbrella. To be fair, the required changes are minimal but the implementer of TF-M secure side will need to be aware of that detail (along with others). It would be good to document TF-M requirements for startup and system initialization in details.
I guess there are more benefits than drawbacks of the new approach.
Best regards, Robert
From: Soby Mathew Soby.Mathew@arm.com Sent: Thursday 3 September 2020 12:03 To: Robert Rostohar Robert.Rostohar@arm.com; Ken Liu Ken.Liu@arm.com Cc: nd nd@arm.com; tf-m@lists.trustedfirmware.org Subject: RE: Changes to configure FPU at the architectural level in TF-M
Hi Robert, Thanks for the clarification. I see what you mean now.
The trouble with every platform replicating architectural functionality is the same code is replicated across many platforms which is not good for several reasons. Centralising these common architectural initializations, in addition to benefits mentioned earlier, will allow to add more features and deliver security hardening to all TF-M platforms in a better way. For example, say in future we want to harden certain pieces of architectural initializations against glitch attacks, or say deliver a security fix which involves the architecture initialization, having it in a single place as part of architectural abstraction will greatly benefit the project.
As I mentioned earlier, I think overall this will reduce the porting effort required if more architectural bits are done commonly. I don't see why CMSIS-Core compliant device will not get the same benefit.
Best Regards Soby Mathew
From: Robert Rostohar <Robert.Rostohar@arm.commailto:Robert.Rostohar@arm.com> Sent: 02 September 2020 16:49 To: Soby Mathew <Soby.Mathew@arm.commailto:Soby.Mathew@arm.com>; Ken Liu <Ken.Liu@arm.commailto:Ken.Liu@arm.com> Cc: nd <nd@arm.commailto:nd@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Subject: RE: Changes to configure FPU at the architectural level in TF-M
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): https://github.com/STMicroelectronics/STM32CubeL5/blob/master/Drivers/CMSIS/...
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.orgmailto: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.commailto:Ken.Liu@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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.orgmailto: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.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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.orgmailto: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.commailto:Jamie.Fox@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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.orgmailto: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.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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
Hi Robert, Thanks for your comments and understanding, yes documentation is needed for this, and we will work on that.
If other platform owners have thoughts on consolidation of architecture init outside platform code inside generic architecture abstraction within TF-M, it would be good to hear that.
Best Regards Soby Mathew
From: Robert Rostohar Robert.Rostohar@arm.com Sent: 04 September 2020 07:52 To: Soby Mathew Soby.Mathew@arm.com; Ken Liu Ken.Liu@arm.com Cc: nd nd@arm.com; tf-m@lists.trustedfirmware.org Subject: RE: Changes to configure FPU at the architectural level in TF-M
Hi Soby,
Thanks for the clarifications.
I understand now the motivation to use centralized initialization which sounds reasonable.
However, I do not agree that it will reduce the porting effort in regards to system files provided by vendors under CMSIS umbrella. To be fair, the required changes are minimal but the implementer of TF-M secure side will need to be aware of that detail (along with others). It would be good to document TF-M requirements for startup and system initialization in details.
I guess there are more benefits than drawbacks of the new approach.
Best regards, Robert
From: Soby Mathew <Soby.Mathew@arm.commailto:Soby.Mathew@arm.com> Sent: Thursday 3 September 2020 12:03 To: Robert Rostohar <Robert.Rostohar@arm.commailto:Robert.Rostohar@arm.com>; Ken Liu <Ken.Liu@arm.commailto:Ken.Liu@arm.com> Cc: nd <nd@arm.commailto:nd@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Subject: RE: Changes to configure FPU at the architectural level in TF-M
Hi Robert, Thanks for the clarification. I see what you mean now.
The trouble with every platform replicating architectural functionality is the same code is replicated across many platforms which is not good for several reasons. Centralising these common architectural initializations, in addition to benefits mentioned earlier, will allow to add more features and deliver security hardening to all TF-M platforms in a better way. For example, say in future we want to harden certain pieces of architectural initializations against glitch attacks, or say deliver a security fix which involves the architecture initialization, having it in a single place as part of architectural abstraction will greatly benefit the project.
As I mentioned earlier, I think overall this will reduce the porting effort required if more architectural bits are done commonly. I don't see why CMSIS-Core compliant device will not get the same benefit.
Best Regards Soby Mathew
From: Robert Rostohar <Robert.Rostohar@arm.commailto:Robert.Rostohar@arm.com> Sent: 02 September 2020 16:49 To: Soby Mathew <Soby.Mathew@arm.commailto:Soby.Mathew@arm.com>; Ken Liu <Ken.Liu@arm.commailto:Ken.Liu@arm.com> Cc: nd <nd@arm.commailto:nd@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Subject: RE: Changes to configure FPU at the architectural level in TF-M
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): https://github.com/STMicroelectronics/STM32CubeL5/blob/master/Drivers/CMSIS/...
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.orgmailto: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.commailto:Ken.Liu@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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.orgmailto: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.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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.orgmailto: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.commailto:Jamie.Fox@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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.orgmailto: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.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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
tf-m@lists.trustedfirmware.org
-
Robert Rostohar -
Soby Mathew