- TF-M - lists.trustedfirmware.org

Re: [TF-M] Decouple NS specific code from TF-M NS interface

by David Hu

Hi all, The patch sets to decouple NS code from TF-M secure part have been merged. Sorry for the early merge as other pending patches depend on this patch set. Please rebase your patches if build reports an error about conflicting types of `tfm_ns_interface_init()`. Sorry for any inconvenience. If this decoupling brings any issue in NS integration with TF-M, sorry about the trouble and I'd appreciate it if you can share the issue details. Any further comment or suggestion is welcome. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Tuesday, April 27, 2021 11:50 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [Ask for review] Decouple NS specific code from TF-M NS interface Hi all, Thanks a lot for all your review and comments! I'd like to merge the patch sets *this Friday* if there is no further critical comment. Please feel free to continue to review and comment. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of David Hu via TF-M Sent: Thursday, April 15, 2021 4:12 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] [Ask for review] Decouple NS specific code from TF-M NS interface Hi all, May I ask you to take a look at the following patch set to decouple NS specific code from TF-M NS interface? https://review.trustedfirmware.org/q/topic:%22decouple-ns-interface%22+(sta… The decoupled NS code is moved from trusted-firmware-m repo to tf-m-tests repo, as an example of NS implementation. https://review.trustedfirmware.org/q/topic:%22add-ns-code%22+(status:open%2… The purpose of this change is to make it more flexible and simple to integrate NS OS with TF-M NS interface. Currently TF-M provides some reference implementations of NS interface for NS OS integration. However, it may have limitations during NS OS integration as various NS OSes/application usages prefer different implementations. Therefore, those NS OS specific code is removed from TF-M interface for NS clients in this patch set. The removed NS code includes NS interface lock ops, os wrappers and NS test specific implementation. Those NS code can be taken as an example in tf-m-tests. NS developers can follow or replace them during integration with TF-M, according to NS OS implementation and actual scenarios, without hacking trusted-firmware-m repo. This patch set doesn't change the current integration scheme. Instead, it exports the "tfm_ns_interface_dispatch()" API and enables NS OS to implement it according to NS OS and application specific requirement, such as NS interface lock operations. Any comment is welcome! Best regards, Hu Ziji

4 years, 7 months

1
0
0 0

Re: [TF-M] Technical Forum call - April 29

by Anton Komlev

Hi, We have no explicit items in the agenda. Let's use this chance to discuss any ongoing topics and questions like: * Planning repo restructuring * S <> NS decoupling * Pended PS reviews and a need for clarification * Your topic See you, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, April 21, 2021 11:40 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] Technical Forum call - April 29 Hi, The next Technical Forum is planned on Thursday, April 29 , 07:00-08:00 UTC (Asia time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

4 years, 7 months

1
0
0 0

Re: [TF-M] Supporting integrated Non-Secure RTOS applications that use the FPU

by Feder Liang

Hi, Ioannis Sorry for late response. I am out of office these two days. Thank you very much for sharing your problem here. As Keven mentioned, could you please report your problem on phabricator first with more details? This will be very helpful for us to analyze the problem you mentioned. 1. Which cortex-m core? 2. TF-M changeset you are using and compiler version. 3. Please list all changes you did for TF-M while integrated to your project. 4. More information about the crash: * IPC mode, right? Which isolation level? * Detail sequences of actions between NS and S when crash. * Lzay FP enabled? Crash when FPCCR_NS.LSPACT = 1 or something else? * Which PSA calls causes the crash, or all PSA calls? * How about the occurrence of crash? Always crash or sometimes? * Which fault entered? Value of registers and stack frame in memory at crash time are very useful for analysis. * ……., Other information if possible. The more information the better, please try to attached them in phabricator. Thank you. Best Regards Feder From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Glaropoulos, Ioannis via TF-M Sent: Thursday, April 22, 2021 3:24 PM To: Kevin Townsend (kevin.townsend(a)linaro.org) <kevin.townsend(a)linaro.org>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Supporting integrated Non-Secure RTOS applications that use the FPU Hi Kevin, Thanks for the link to the presentation 😊 I guess, then, Feder Liang, as the author of the presentation, should be able to provide some feedback on the questions I raised? Once more, I am stressing that our questions concern the usage of FPU in Non-Secure applications that integrate with TF-M today; it is not about future improvements for FPU support inside TF-M, which was (I guess) the main point of this presentation. Best, Ioannis From: Kevin Townsend <kevin.townsend(a)linaro.org<mailto:kevin.townsend@linaro.org>> Sent: Wednesday, April 21, 2021 8:03 PM To: Glaropoulos, Ioannis <Ioannis.Glaropoulos(a)nordicsemi.no<mailto:Ioannis.Glaropoulos@nordicsemi.no>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Supporting integrated Non-Secure RTOS applications that use the FPU On Wed, 21 Apr 2021 at 18:56, Glaropoulos, Ioannis via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: I would like to ask the community whether these issues have been raised in the past – and if so, please, inform me what the conclusions have been. Are there current activities that attempt to address the problems raised above? Not been able to fully utilize the FP context stacking in Non-Secure Zephyr applications that integrate with TF-M removes value of our TF-M based solutions. Thanks! I am looking forward to hearing the thoughts of the community. Hi Ioannis, The previous technical forum call did discuss FP usage ... I don't think you were on the call at the time, but the presentation and video can be viewed here, and should point to the people to follow up with here on the mailing list of on phabricator, etc. Presentation: https://www.trustedfirmware.org/docs/FP-support-in-TF-M.pdf<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.trust…> Video link(s) available here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.trust…> Best rehards, Kevin

4 years, 7 months

2
1
0 0

Re: [TF-M] [Ask for review] Decouple NS specific code from TF-M NS interface

by David Hu

Hi all, Thanks a lot for all your review and comments! I'd like to merge the patch sets *this Friday* if there is no further critical comment. Please feel free to continue to review and comment. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Thursday, April 15, 2021 4:12 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [Ask for review] Decouple NS specific code from TF-M NS interface Hi all, May I ask you to take a look at the following patch set to decouple NS specific code from TF-M NS interface? https://review.trustedfirmware.org/q/topic:%22decouple-ns-interface%22+(sta… The decoupled NS code is moved from trusted-firmware-m repo to tf-m-tests repo, as an example of NS implementation. https://review.trustedfirmware.org/q/topic:%22add-ns-code%22+(status:open%2… The purpose of this change is to make it more flexible and simple to integrate NS OS with TF-M NS interface. Currently TF-M provides some reference implementations of NS interface for NS OS integration. However, it may have limitations during NS OS integration as various NS OSes/application usages prefer different implementations. Therefore, those NS OS specific code is removed from TF-M interface for NS clients in this patch set. The removed NS code includes NS interface lock ops, os wrappers and NS test specific implementation. Those NS code can be taken as an example in tf-m-tests. NS developers can follow or replace them during integration with TF-M, according to NS OS implementation and actual scenarios, without hacking trusted-firmware-m repo. This patch set doesn't change the current integration scheme. Instead, it exports the "tfm_ns_interface_dispatch()" API and enables NS OS to implement it according to NS OS and application specific requirement, such as NS interface lock operations. Any comment is welcome! Best regards, Hu Ziji

4 years, 7 months

1
0
0 0

Temporary moving 'tfm_spm_hal_configure_default_isolation' out of FIH mointoring

by Ken Liu

Hi, We are refining the HAL logics for MMIO, so this legacy API 'tfm_spm_hal_configure_default_isolation', which is now monitored under FIH library would be out of monitoring for a while. The successors for this API would be added back after the refining is done, unless there are coming FIH updates. Moving this single function out of FIH monitoring won't trigger problems - in most of the cases this API just returns without actions as few partition has bound MMIOs. Thanks. /Ken

4 years, 7 months

1
0
0 0

[Partition and Build] Partition storage arrangement patches

by Ken Liu

Hi, As we planned some time ago in one of the Tech Forums about updating the partition storage (Search "TF-M Partition Storage Arrangement" here:https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ ), we have created several patches to complete this. Here in this mail is to broadcast that the partition storage would get updated after this patch, the loading process in SPM would be updated as well to provide: * Better modularization, especially for partitions. Now the partition info are put inside sections, hence there is no source level dependencies in SPM. When partitions get added/removed during one build it won't trigger a build of SPM library. * Clear interface for future expansion, such as other partition loading mechanism, for example, a partition saved in a non-XIP flash or else. But at current stage we still focus on storing partition in XIP based ROM. Some intermedia patches can't be perfect during the movement, so please focus on the final result of patch groups instead of focusing to make one of the staging patches perfect - we don't want to create a big patch hence some trade-off-like patches have to be there. The patches can be found here: https://review.trustedfirmware.org/q/topic:%22partition_storage%22+(status:… Feel free to comment and provide ideas! BR /Ken

4 years, 7 months

1
0
0 0

Re: [TF-M] Supporting integrated Non-Secure RTOS applications that use the FPU

by Anton Komlev

This is a test message. I know that Feder have posted to the list but message was not delivered. From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: Thursday, April 22, 2021 11:31 AM To: Glaropoulos, Ioannis <Ioannis.Glaropoulos(a)nordicsemi.no> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Supporting integrated Non-Secure RTOS applications that use the FPU On Thu, 22 Apr 2021 at 09:23, Glaropoulos, Ioannis <Ioannis.Glaropoulos(a)nordicsemi.no<mailto:Ioannis.Glaropoulos@nordicsemi.no>> wrote: Once more, I am stressing that our questions concern the usage of FPU in Non-Secure applications that integrate with TF-M today; it is not about future improvements for FPU support inside TF-M, which was (I guess) the main point of this presentation. Looking at this a bit further it is indeed a serious issue, since most modern applications are going to want to make use of the FPU. This prevents the FPU from being used inside NS interrupts as well. I’m not sure if there are currently any change requests that identify or fix this problem (I’ll look), but it’s something that should have some sort of test on the NS side, for sure. Do you mind filing the details on TF-M’s phabricator and it can more easily be tracked there? Thanks for bringing this up, Kevin

4 years, 8 months

1
0
0 0

Re: [TF-M] Supporting integrated Non-Secure RTOS applications that use the FPU

by Kevin Townsend

On Wed, 21 Apr 2021 at 18:56, Glaropoulos, Ioannis via TF-M < tf-m(a)lists.trustedfirmware.org> wrote: > I would like to ask the community whether these issues have been raised in > the past – and if so, please, inform me what the conclusions have been. Are > there current activities that attempt to address the problems raised above? > Not been able to fully utilize the FP context stacking in Non-Secure Zephyr > applications that integrate with TF-M removes value of our TF-M based > solutions. > > > > Thanks! I am looking forward to hearing the thoughts of the community. > > Hi Ioannis, The previous technical forum call did discuss FP usage ... I don't think you were on the call at the time, but the presentation and video can be viewed here, and should point to the people to follow up with here on the mailing list of on phabricator, etc. Presentation: https://www.trustedfirmware.org/docs/FP-support-in-TF-M.pdf Video link(s) available here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best rehards, Kevin

4 years, 8 months

2
2
0 0

Removal of the nRF5340 PDK platform

by Głąbek, Andrzej

Hello, As announced on March 3 (see https://lists.trustedfirmware.org/pipermail/tf-m/2021-March/001516.html) and in the absence of objections, the nRF5340 PDK platform (nordic_nrf/nrf5340pdk_nrf5340_cpuapp) has been deprecated in the v1.3.0 release and the release is the last one to support this platform. Today, the code and documentation related to this platform have been removed from TF-M. Best regards, Andrzej Głąbek

4 years, 8 months

1
0
0 0

Re: [TF-M] [Ask for review] Decouple NS specific code from TF-M NS interface

by Anton Komlev

Hi, Here is the proposal to restructure TF-M following the intention to split it on the essential part and supplementary items with better logical separation. The proposed new structure, composed from 4 repositories is following: 1. trusted-firmware-m (The essential TF-M core: SPM + PSA partitions and interface. Documentation) 2. tf-m-tests * regression * other test 3. tf-m-tools (additional tools and place for integration glue with 3rd party frameworks) * cmsis * fuzzer * Iat-verifier * ... 4. tf-m-extras (extra components, used in a specific case, but optional for common use) * examples i. NS ii. S * S-partitions - (3rd party production partitions) The questions to the community: 1. Any concern or dependency on the proposed restructure? 2. Shall we treat tests separately or as one of the extra component? Effectively the question are tests deserves a dedicated repo or a folder in tf-m-extra? 3. Better name for tf-m-extra? tf-m-apps? Looking for your comments, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Thursday, April 15, 2021 12:24 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [Ask for review] Decouple NS specific code from TF-M NS interface Thanks, David, The connected job is to rename tf-m-tests repo to something more general to keep supplementary code and not interfere it with TF-M core on secure side. The first candidate was tf-m-ns to reflect the collection of non-secure elements but it might confuse when using it for custom and examples of secure partitions. Thoughts and proposals for the repo naming are welcome. Regards, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of David Hu via TF-M Sent: Thursday, April 15, 2021 9:12 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] [Ask for review] Decouple NS specific code from TF-M NS interface Hi all, May I ask you to take a look at the following patch set to decouple NS specific code from TF-M NS interface? https://review.trustedfirmware.org/q/topic:%22decouple-ns-interface%22+(sta… The decoupled NS code is moved from trusted-firmware-m repo to tf-m-tests repo, as an example of NS implementation. https://review.trustedfirmware.org/q/topic:%22add-ns-code%22+(status:open%2… The purpose of this change is to make it more flexible and simple to integrate NS OS with TF-M NS interface. Currently TF-M provides some reference implementations of NS interface for NS OS integration. However, it may have limitations during NS OS integration as various NS OSes/application usages prefer different implementations. Therefore, those NS OS specific code is removed from TF-M interface for NS clients in this patch set. The removed NS code includes NS interface lock ops, os wrappers and NS test specific implementation. Those NS code can be taken as an example in tf-m-tests. NS developers can follow or replace them during integration with TF-M, according to NS OS implementation and actual scenarios, without hacking trusted-firmware-m repo. This patch set doesn't change the current integration scheme. Instead, it exports the "tfm_ns_interface_dispatch()" API and enables NS OS to implement it according to NS OS and application specific requirement, such as NS interface lock operations. Any comment is welcome! Best regards, Hu Ziji

4 years, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M