- TF-M - lists.trustedfirmware.org

Re: [TF-M] [Request For Comments] Expose the NV counters under platform service.

by Raef Coles

I believe the reason this is being proposed is the transferal of secure storage (as opposed to protected storage) to an application root of trust partition. Such a partition would still require access to the NV counters, at least as far as I know. We ran into this issue while creating the patch to do the transferal, and Jamie suggested this was the most sensible fix. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Adrian Shaw via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 22 January 2020 18:38 To: tf-m(a)lists.trustedfirmware.org; Minos Galanakis Cc: nd Subject: Re: [TF-M] [Request For Comments] Expose the NV counters under platform service. Hi Minos, What are the use cases for Application Root of Trust services that need NV counters? The NV counters are used by the PSA Root of Trust for rollback protection of images and secure storage. There are usually very few available. Hence the question above. Adrian ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Minos Galanakis via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 22 January 2020 17:28 To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] [Request For Comments] Expose the NV counters under platform service. Hi, The Non-Volatile (NV) counters are a part of the PSA Root of Trust. In order to enable Applications residing in the Root of Trust partition to use the counters, an appropriate interface is needed. This proposal is to enhance the existing platform service, in order to expose a generic API aimed at providing access to Non-Volatile counters to applications residing in the Application Root of Trust. This implementation will not modify or affect the existing tfm_plat_nv_counters API or its’ platform specific implementation and will instead introduce a shim layer between a psa_call and the existing logic. All input, question or comments are greatly appreciated. Minos IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

4 years, 11 months

1
0
0 0

Re: [TF-M] [Request For Comments] Expose the NV counters under platform service.

by Adrian Shaw

Hi Minos, What are the use cases for Application Root of Trust services that need NV counters? The NV counters are used by the PSA Root of Trust for rollback protection of images and secure storage. There are usually very few available. Hence the question above. Adrian ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Minos Galanakis via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 22 January 2020 17:28 To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] [Request For Comments] Expose the NV counters under platform service. Hi, The Non-Volatile (NV) counters are a part of the PSA Root of Trust. In order to enable Applications residing in the Root of Trust partition to use the counters, an appropriate interface is needed. This proposal is to enhance the existing platform service, in order to expose a generic API aimed at providing access to Non-Volatile counters to applications residing in the Application Root of Trust. This implementation will not modify or affect the existing tfm_plat_nv_counters API or its’ platform specific implementation and will instead introduce a shim layer between a psa_call and the existing logic. All input, question or comments are greatly appreciated. Minos IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

4 years, 11 months

1
0
0 0

[Request For Comments] Expose the NV counters under platform service.

by Minos Galanakis

Hi, The Non-Volatile (NV) counters are a part of the PSA Root of Trust. In order to enable Applications residing in the Root of Trust partition to use the counters, an appropriate interface is needed. This proposal is to enhance the existing platform service, in order to expose a generic API aimed at providing access to Non-Volatile counters to applications residing in the Application Root of Trust. This implementation will not modify or affect the existing tfm_plat_nv_counters API or its’ platform specific implementation and will instead introduce a shim layer between a psa_call and the existing logic. All input, question or comments are greatly appreciated. Minos

4 years, 11 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - January 23

by Jamie Fox

Hi Anton, I would like to share some details about secure storage in TF-M. I can give an overview of what we have, how to use it and recent/in progress changes, and take questions on more in-depth topics. Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 13 January 2020 11:02 To: TF-M(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M Technical Forum call - January 23 Hello, Just noted (thanks to David) that January 23 is a day ahead of Lunar New Year so we may expect less interest to the forum from Asia. This is an opportunity to make the forum time US friendly on the next session. Preliminary suggest to have it Thursday, January 23rd at 17:00-18:00 UTC. Which a morning time in US. Again, please send your topics in respond to this mail. Experts and developers could be invited to answer specific questions asked in advance. Best regards, Anton Komlev 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: 09 January 2020 11:22 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] TF-M Technical Forum call - January 23 Dear All, The next session of the Technical Forum is planned in 2 weeks, Thursday, January 23rd at 7:00-8:00 UTC. Please treat this email and an early invitation for agenda topic collection. Any questions, proposals, concerns are all valid points for our open discussion so do not hesitate to share it. A big or complicated topics are worth to preliminary discussed over a mailing list. Best regards, Anton Komlev

4 years, 11 months

1
0
0 0

Re: [TF-M] [Request For Comments] apply "-fno-builtin" as default compiler flags

by Ken Liu

Hi, As mentioned, we have created the patch here to apply "-fno-builtin": https://review.trustedfirmware.org/c/trusted-firmware-m/+/3217 Will keep it there for a while for validation purpose. Please help to test this patch if you are run on non-default platforms (those not listed in the platform folder). Any comment can reply or put comments under the issue: https://developer.trustedfirmware.org/T653 Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M Sent: Thursday, January 9, 2020 4:42 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] [Request For Comments] apply "-fno-builtin" as default compiler flags Hi Thomas, Just for my understanding: * Does IAR provide a C std. lib as part of IAR toolchain package? * How the std C lib linked to the image? Does user provide an explicit flag which std. C lib to linked to the image? Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Thomas Törnblom via TF-M Sent: 08 January 2020 12:45 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] [Request For Comments] apply "-fno-builtin" as default compiler flags The IAR toolchain does not produce any special "builtin" calls and thus does not have any flag similar to "-fno-builtin". /Thomas Den 2020-01-08 kl. 03:53, skrev Ken Liu via TF-M: Hi, ï¿½ As TF-M needs runtime APIs so we are creating the Secure Partition runtime library, code is ready but we have not forwarded all necessary runtime APIs to the version TF-M implemented, this was caused by the toolchain optimization for built-in APIs, such as: ï¿½ - Forward printf(%s) to puts if there is only one string parameter. - ARMCLANG would forward memxxx API into an optimized variant. ï¿½ With the '-fno-builtin' flags set in the toolchain, this optimization would be disabled so that user just implement the same name built-in to replace the toolchain version. ï¿½ Please help to check these point before applying '-fno-builtin' and provide your feedback: ï¿½ - Could toolchains out of ARMCLANG and GNUARM have a similar flag? - Would it affect your project setting and how does it affect? ï¿½ Please help to feedback. I will keep this thread open for ~1 week and let's get a conclusion after this. ï¿½ Thanks! ï¿½ /Ken -- Thomas Tï¿½rnblom, Product Engineer IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

4 years, 11 months

1
0
0 0

Re: [TF-M] Code Protection between secure services

by Andrew Thoelke

> I was referring to the Code Protection between "PSA Root of Trust" and the "Secure Services". "Secure Services" is not a defined concept in the PSA-FF description of isolation. A "RoT Service" might run in the Application RoT or in the PSA RoT. In the response below I guess that you are referring to a Service that is running in a Secure Partition in the Application RoT? > From my understanding, in isolation level 2 code of the PSA Root of Trust should be not accessible by Secure Services. > This creates the practical problem that library code cannot be shared. > > Table 5 in PSA-FF describes "Optional Isolation Rules". Is my understanding correct that PSA-FF does not require code execution protection between "PSA Root of Trust" and the "Secure Services". At level 2 "Application Root of Trust _needs protection from_ PSA Root of Trust" (section 3.1.3) However, your reading of 3.14 and 3.1.5 is correct: - Protection of code is not mandatory in an implementation. - The only mandatory rule when implementing "needs protect from" is in table 4, which in this case requires that PSA RoT "private data" is not accessible to firmware executing in the Application RoT. So an implementation is permitted to share code (and its RO data) between PSA RoT, Application RoT and even NSPE; or to prevent sharing of code across one or more of those boundaries. - Andrew IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

4 years, 11 months

1
0
0 0

Code Protection between secure services

by Reinhard Keil

Sorry Andrew I was not precise enough. Maybe you can clarify again. I was referring to the Code Protection between "PSA Root of Trust" and the "Secure Services". >From my understanding, in isolation level 2 code of the PSA Root of Trust should be not accessible by Secure Services. This creates the practical problem that library code cannot be shared. Table 5 in PSA-FF describes "Optional Isolation Rules". Is my understanding correct that PSA-FF does not require code execution protection between "PSA Root of Trust" and the "Secure Services". Reinhard

4 years, 11 months

1
0
0 0

Re: [TF-M] Stuck in tfm_nspm_thread_entry() after "Initialize IPC SPM in handler mode"

by Ken Liu

Hi Andrej, I guess you are using the level2 configuration. This fault was caused by tfm_nspm_thread_entry is trying to call a function in the privileged area. This commit 'cba90782908626f955fe361f803558181a85c6fc' fixes this problem. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, January 21, 2020 12:14 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Stuck in tfm_nspm_thread_entry() after "Initialize IPC SPM in handler mode" Hello, Just want to check if this is a known issue. During synchronization to the latest TFM, TFM applications are stuck in the exception handler tfm_nspm_thread_entry ()=>MemManage_Handler(). This issue has been caused by commits (3.1.2020): 1. Revision: 5248af2d7b86775364a0e131eb80ac0330bc81fb Message: Core: Use naked function for ns jumping 1. Revision: 490281df3736b11b62e25bc98d3e2c6e4e10478c Message: Core: Initialize IPC SPM in handler mode The previous commit is fully OK (committed 2.1.2020): Revision: 93dabfd3a35faf9ed88285e09997491e93cefa5c Message: Core: Trigger a system reset for programmer error The commits do not have any changes in the linker files and no changes in target files, only the common and ARMv8 code. It's good to know if this is something known or met before. Thank you, Andrej

4 years, 11 months

1
0
0 0

Re: [TF-M] Move dual-cpu design document into code repo

by David Hu

Hi all, All the dual-cpu design documents are merged. Any further enhancement and simplification of the design 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: Thursday, January 16, 2020 10:10 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Move dual-cpu design document into code repo Hi all, We are moving dual-cpu design documents from trustedfirmware.org wiki pages into TF-M code repo. We convert the documents to rst format, fix some typos, update them to align with latest implementation. The patches have been reviewed for several rounds in https://review.trustedfirmware.org/q/topic:%22dualcpu-docs%22+(status:open%…. The documents patches will be merged soon by this week. Please comment on the patches if there is any serious issue in the design. Any suggestion or improvement is still welcome after the patches are merged! Best regards, Hu Ziji

4 years, 11 months

1
0
0 0

Stuck in tfm_nspm_thread_entry() after "Initialize IPC SPM in handler mode"

by Andrej Butok

Hello, Just want to check if this is a known issue. During synchronization to the latest TFM, TFM applications are stuck in the exception handler tfm_nspm_thread_entry ()=>MemManage_Handler(). This issue has been caused by commits (3.1.2020): 1. Revision: 5248af2d7b86775364a0e131eb80ac0330bc81fb Message: Core: Use naked function for ns jumping 1. Revision: 490281df3736b11b62e25bc98d3e2c6e4e10478c Message: Core: Initialize IPC SPM in handler mode The previous commit is fully OK (committed 2.1.2020): Revision: 93dabfd3a35faf9ed88285e09997491e93cefa5c Message: Core: Trigger a system reset for programmer error The commits do not have any changes in the linker files and no changes in target files, only the common and ARMv8 code. It's good to know if this is something known or met before. Thank you, Andrej

4 years, 11 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M