- TF-M - lists.trustedfirmware.org

by DeMars, Alan

Mention is made to "SPM_IDLE" in the Cooperative Scheduling Rules document: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… I'm struggling to understand section 8.3.5 which references SPM_IDLE but doesn't really define it. Is there more info on this topic? It appears to be a proposed solution for allowing other NS threads to be scheduled while the current NS thread is waiting for an asynchronous event in the secure service it has called. Alan

5 years, 8 months

1
0
0 0

memcpy variants

by Reinhard Keil

Just some minor observation: There are various variants of memory functions in tfm core * tfm_memory_utils.h defines a set of identical functions * tfm_core_utils.c/h has another set - functional equivalent with the C run-time library Why are these functions duplicated? It would be Ok if they address some additional security concerns (that I currently don't understand). But todays implementation just add complexity. Reinhard

5 years, 8 months

1
0
0 0

TrustZone initialisation procedure

by Reinhard Keil

Hi Ken, Hi Jonatan, Here is how I see it: * PPC, MPC control system wide the access rights; DMA and other bus masters cannot bypass * SAU controls the access rights on the Processing Element * MPU controls the access rights within a execution domain (secure, non-secure) The setup for TF-M should be: * Isolation Level 1: static SAU, PPC, MPC setup * Isolation Level 2: adds static MPU setup (for privilege, non-privilege separation - could be reflected in PPC, MPC when it is supported by the device) * Isolation Level 3: dynamic MPU setup (depending on the service executed) Changing PPC, MPC setup dynamically does not make sense, as in most devices DMA could bypass TF-M. If this schema is acceptable, TF-M could always assume correct setup of Isolation level 1. A static #define could reflect that. If you think it should be different, please explain why a different schema would add further security to the overall system. Reinhard

5 years, 8 months

1
0
0 0

Re: [TF-M] TrustZone initialisation procedure

by Ken Liu

Hi Jonatan, The enhancement of this TZ_SAU_Setup() sounds reasonable, and there are more background items to be considerate: * The SPM need to re-configure the isolation hardware dynamically under isolation level 3 while SPM scheduling, and MPC/PPC is potentially included. So I am not sure what the 'system isolation' mean in your mail, if you want a static initialization for all isolation settings then it will not work for SPM at least for the isolation level 3 design. If it includes the minimal security (and fundamental) setting while system booting and there are other functions to update the isolation setting later, it is do-able. * How does the parameter pass into this function? Because SPM needs to know the status of the existing isolation setting for some purposes (such as security checking), so there needs to be a way to let SPM know the isolation status. So if we do the fundamental security setup in SystemInit(), the advantage is the protection is already enabled between SystemInit() exits and SPM_Init() (There are platform init process in this stage). The cons are SPM may not check the isolation status. And if we do isolation in SPM_Init(), the advantage is SPM can know the status and the cons are Platform Init is not restricted (It could access anywhere). I would suggest not to propose the calling time strictly for this new enhanced API. I know cypress uses customized protection initialization mechanism so any ideas? BR /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Jonatan Antoni via TF-M Sent: Tuesday, March 3, 2020 11:09 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] TrustZone initialisation procedure Hi all, I am trying to align TrustZone initialisation procedure between TF-M and CMSIS. In CMSIS the approach from the early v8-M days is to have a "partition.h" file providing "TZ_SAU_Setup()" function. This function is called during low level "SystemInit()" which runs as part of the pre-main (called from ResetHandler and before running C lib init). In contrast TF-M calls "tfm_spm_hal_init_isolation_hw()" (which is similar to "TZ_SAU_Setup()" plus PPC/MPC configuration) during "tfm_core_init()" (which runs in secure "main()"). The advantage of "TZ_SAU_Setup()" is that this function is available by standard for all TrustZone devices. The shortcoming is it doesn't cover MPC/PPC configuration, yet. Ideally we can enhance CMSIS standard to offer a "TrustZone_Setup()" function (the name is still to be defined) that does all this. That would simplify the TF-M HAL to just one single function call that should be provided by each TrustZone-Device low level init code. The final question is: When does this function need to be called? Are you aware of any reason why we should not configure the "system isolation" already during low level init (pre-main)? This could simplify TF-M code even more. In TF-M we could simply rely on a properly configured TrustZone isolation before running any TF-M code. Cheers, Jonatan Antoni Senior Engineering Manager - CMSIS [Germany on Google Android 8.0] [United Kingdom on Google Android 8.0] Arm Germany GmbH Phone: +49 (0)89 262 029 618 | Fax: +49 (0)89 456 040-19 Email: jonatan.antoni(a)arm.com<mailto:jonatan.antoni@arm.com> | Visit: www.keil.com<http://www.keil.com > | Address: Bretonischer Ring 16, 85630 Grasbrunn, Germany Sitz der Gesellschaft: Grasbrunn | Handelsregister: München (HRB 175362) | USt-IdNr.: DE 187925309 Geschäftsführer: Joachim Krech, Reinhard Keil 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.

5 years, 8 months

1
0
0 0

TrustZone initialisation procedure

by Jonatan Antoni

Hi all, I am trying to align TrustZone initialisation procedure between TF-M and CMSIS. In CMSIS the approach from the early v8-M days is to have a "partition.h" file providing "TZ_SAU_Setup()" function. This function is called during low level "SystemInit()" which runs as part of the pre-main (called from ResetHandler and before running C lib init). In contrast TF-M calls "tfm_spm_hal_init_isolation_hw()" (which is similar to "TZ_SAU_Setup()" plus PPC/MPC configuration) during "tfm_core_init()" (which runs in secure "main()"). The advantage of "TZ_SAU_Setup()" is that this function is available by standard for all TrustZone devices. The shortcoming is it doesn't cover MPC/PPC configuration, yet. Ideally we can enhance CMSIS standard to offer a "TrustZone_Setup()" function (the name is still to be defined) that does all this. That would simplify the TF-M HAL to just one single function call that should be provided by each TrustZone-Device low level init code. The final question is: When does this function need to be called? Are you aware of any reason why we should not configure the "system isolation" already during low level init (pre-main)? This could simplify TF-M code even more. In TF-M we could simply rely on a properly configured TrustZone isolation before running any TF-M code. Cheers, Jonatan Antoni Senior Engineering Manager - CMSIS [Germany on Google Android 8.0] [United Kingdom on Google Android 8.0] Arm Germany GmbH Phone: +49 (0)89 262 029 618 | Fax: +49 (0)89 456 040-19 Email: jonatan.antoni(a)arm.com<mailto:jonatan.antoni@arm.com> | Visit: www.keil.com<http://www.keil.com > | Address: Bretonischer Ring 16, 85630 Grasbrunn, Germany Sitz der Gesellschaft: Grasbrunn | Handelsregister: München (HRB 175362) | USt-IdNr.: DE 187925309 Geschäftsführer: Joachim Krech, Reinhard Keil 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.

5 years, 8 months

1
0
0 0

Re: [TF-M] Call for a feedback on TF-M adaptation experience

by Andrej Butok

Hi Anton, > I am not sure if TF-M requires add/remove files Not physically, but in scope of a project. This is the fact from very beginning. > With this occasion let me remind that TF-M is an open source project where design proposal or code change are welcome from everyone. Yes, but it should be approved and pushed by leaders, otherwise it will not work, and the main leading force of PSA projects is ARM. After that, the approach should be followed by every committer. Thank you, Andrej From: Anton Komlev <Anton.Komlev(a)arm.com> Sent: Tuesday, March 3, 2020 3:24 PM To: Andrej Butok <andrey.butok(a)nxp.com> Cc: nd <nd(a)arm.com> Subject: RE: Call for a feedback on TF-M adaptation experience Hi Andrej, Thank you for your feedback! I am not sure if TF-M requires add/remove files for config change but have to agree that build system requires review and refactoring to be less restrictive and easy for integration. This is a valuable input for us for improvement planning and task prioritizing. With this occasion let me remind that TF-M is an open source project where design proposal or code change are welcome from everyone. Thanks again, Anton From: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>> Sent: 03 March 2020 13:31 To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: Call for a feedback on TF-M adaptation experience Hi Anton, The biggest inconvenience for us is the way which TFM is using CMAKE. The configuration is done on level of CMAKE - adding/deleting/renaming files based on project-level configuration. So it is difficult to use the original TFM as a component, required for SDKs and CMSIS packs. For every combination of parameters is needed to create a separate project. As it is not possible, we have to choose one typical configuration. For example, if a user need to change from Isolation2&IPC to Isolation1&Lib, it is not enough to change configuration parameters, he/she must manually to add/delete source files in the project. The improvement request: - platform-independent TFM source-code file set must be fixed for any TFM project. - optional functionality must be covered by #ifdef - NOT by adding/deleting files. - allow to change configuration parameters using a user-config file (e.g. as it's done for mbedTLS/Cypto). All these has no conflict with CMAKE and brings no limits to TFM. Please, do not ignore it. Thank you, Andrej Butok 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: Friday, February 7, 2020 2:13 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] Call for a feedback on TF-M adaptation experience Dear All, As I mentioned on yesterday's call, there is a concern on user experience related to TF-M use. To In order to understand and potentially improve it I am looking for a voice of partners who adopted TF-M project. Please share your experience and thoughts on parts which are good or might be done better to simplify TF-M integration with your project. You feedback will be very appreciated in any form - as a response to this mail or as a direct mail to me (anton.komlev(a)arm.com<mailto:anton.komlev@arm.com>) if it's more comfortable for you. Thank you in advance, Anton

5 years, 8 months

1
0
0 0

Re: [TF-M] PSA-Test Suite, 23 Crypto Tests failed

by Soby Mathew

On 02/03/2020 12:00, Andrej Butok via TF-M wrote: > Hi, > > So, I have submitted the mbedCryptoï¿½ issue > https://github.com/ARMmbed/mbed-crypto/issues/380 > > Several missed functions were implemented in the latest mbedCrypto. > Please read the comment. Hi Andrej, I will try to answer some of the questions. TF-M currently uses 3.0.1 tag of mbed-crypto and it has all the functions implemented in that version. We certainly need to be able to migrate to newer versions of mbed-crypto quicker and more easily. This is one of the things I will be looking into as part of the improving the crypto service implementation in TF-M. My current thoughts are that once mbed-crypto implements more of the other PSA crypto APIs, we could sync up TF-M to expose those APIs. > > They also need clarification about the PSA failed test: > > 1)ï¿½psa_asymmetric_encrypt does not have support for ECC keysï¿½ ï¿½ that's > true, the specification currently does not define any algorithm for > psa_asymmetric_encryptï¿½that uses ECC keys. What's the problem there? The PSA-ACK test need to fix this. I will highlight this issue to them. > 2) For the incorrect key derivation error codes, what are the > problematic inputs? There is an issue raised with mbed-crypto team discussing this issue here : https://github.com/ARMmbed/mbed-crypto/issues/175 As I understand, this needs to be fixed by mbed-crypto. > > 3) For ï¿½psa_generate_key generates incorrect key length for RSAï¿½, what > are the problematic inputs? > > Could you clarify or this is the PSA-Test-Suite task? The problematic input can be seen here : https://github.com/ARM-software/psa-arch-tests/blob/master/api-tests/dev_ap… This is a mismatch between the test and the crypto implementation. PSA ACK test project had been notified. I will be following up with them. > > BTW: > > 1) ï¿½mbedCrypto does not use the PSA test suite for testing (they have > own tests). Yes, that is true. > > 2) PSA Test Suite does not inform mbedCrypto about found PSA issues. There is some communication as seen by the issues referenced above, but can be better > > 3) TFM updates to the latest mbedCrypto have to be more often (ideally > after each mbedCrypto release). > > 4) Better synchronization between the PSA Projects is needed. > Yes, certainly. Although syncing to every mbed-crypto release is too much of an overhead for TF-M and the current plan is to sync up once mbed-crypto has resolved a sizeable amount of unimplemented APIs. We are open to contributions in this regard. Currently, all of them are moving targets, the PSA ACK tests, TF-M, mbed-crypto and the PSA specification. The mbed-crypto is moving towards PSA 1.0 whereas the PSA-ACK tests are targeting PSA 1.0 Beta3. This creates some of the mismatches. Once the APIs have stabilized, it should be a matter of picking up the latest mbed-crypto tag and everything should work as expected. Best Regards Soby Mathew > Thanks, > > Andrej Butok > > *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org> *On Behalf Of > *Andrej Butok via TF-M > *Sent:* Friday, February 28, 2020 1:20 PM > *To:* Anton Komlev <Anton.Komlev(a)arm.com> > *Cc:* tf-m(a)lists.trustedfirmware.org > *Subject:* Re: [TF-M] PSA-Test Suite, 23 Crypto Tests failed > > Hi Anton, > > OK. So this is the known issue. Is there any plan when it should be > implemented? > > As the test-log is used for a PSA certification, may we disable the > failed tests? > > BTW: As this is known issue, I did not notice it here > https://github.com/ARMmbed/mbed-crypto/issues?page=1&q=is%3Aissue+is%3Aopen… > <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> > > Thanks, > > Andrej > > *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:* Friday, February 28, 2020 12:14 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:* Re: [TF-M] PSA-Test Suite, 23 Crypto Tests failed > > Hello Andrej, > > As you noted, the main reason of test failures is unimplemented PSA > functions. Those functions are directly dependent on Embed-Crypto > library where they are missed or API is not adjusted. > > Recently TF-M was upgraded Embed-Crypto library from v1.0.0 to v3.0.1 > and will continue so, increasing test suite coverage. > > Best regards, > > Anton > > *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org > <mailto:tf-m-bounces@lists.trustedfirmware.org>> *On Behalf Of *Andrej > Butok via TF-M > *Sent:* 28 February 2020 09:46 > *To:* tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> > *Subject:* [TF-M] PSA-Test Suite, 23 Crypto Tests failed > > Hello, > > After update to the latest TFM and to the latest PSA-Test Suite, 23 > Crypto Tests are failed: > > ************ Crypto Suite Report ********** > > TOTAL TESTSï¿½ï¿½ï¿½ï¿½ : 61 > > TOTAL PASSEDï¿½ï¿½ï¿½ : 37 > > TOTAL SIM ERROR : 0 > > TOTAL FAILEDï¿½ï¿½ï¿½ : 23 > > TOTAL SKIPPEDï¿½ï¿½ : 1 > > ****************************************** > > The main reason is that many of PSA Crypto functions are not implemented > by TFM. > > Is there a plan to fix it? > > Thanks, > > Andrej >

5 years, 8 months

3
2
0 0

Re: [TF-M] Call for a feedback on TF-M adaptation experience

by David Hu

Hi Reinhard, Do you mind describing more details about separating single core v8M from dual core v7M? Do you require more documents or some improvement on code? Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: Monday, March 2, 2020 6:10 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Call for a feedback on TF-M adaptation experience Hi Anton, Hi Kevin, Thanks for starting this discussion. Let me give you my view on it. I think the problem can be structured in these parts: * Give documentation a better overall structure * Clearly separate single core v8M from dual core v7M * Describe the overall structure of the files and configuration options of TF-M * Describe resource requirements of TF-M core * Describe platform interfaces and provide templates * Describe how a Service is added to TF-M * Describe the tools/utilities that are used for TF-M While the debugging aspect raised by Kevin is relevant, it is a generic problem for all v8-M projects, not just for TF-M. I'm supportive to provide tools like pyOCD, but we need proper resourcing for it (maybe a separate project). It should be also noted that the industry works typically with tools like EWARM, MDK, or vendor specific tools like STCube or MCUxpresso. Hence we should not directly add too much tool-specific information to TF-M itself. Now let me give more context to each of the above topics. ---- Give documentation a better overall structure The Trusted Firmware-M documentation starts here: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… While this is already a User's Guide, it contains two more user's guides https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… For an outsider it is unclear where to start. Clearly separate single core v8M from dual core v7M This seems to be somewhat better now as it seems that below only refers to v8M single core: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… Describe the overall structure of the files and configuration options of TF-M I was looking for something like this: https://arm-software.github.io/CMSIS_5/RTOS2/html/pDirectory_Files.html https://arm-software.github.io/CMSIS_5/RTOS2/html/config_rtx5.html Describe resource requirements of TF-M core Take a look here to understand that request https://arm-software.github.io/CMSIS_5/RTOS2/html/pHardwareRequirements.html Important is also to document the interrupt behaviour (for both the secure and non-secure side). I know that this is tricky. For RTX we have this here: https://arm-software.github.io/CMSIS_5/RTOS2/html/cre_rtx_proj.html#cre_Usi… For TF-M this depends on a lot of other parameters. Describe platform interfaces and provide templates What I mean by that are the functions itself that are called by TF_M core. This is an example of the OS_Tick interface that RTX is using. TF-M core has similar interfaces to setup MPC, PPC, SAU, etc. https://arm-software.github.io/CMSIS_5/RTOS2/html/group__CMSIS__RTOS__TickA… Describe how a Service is added to TF-M Assume I have functions currently used in NS. What would be the process to move this functions into TF-M as a service. How does the API interface change, what modifications do I need (ideally I would like to have the same API interface after it). Are the any rules for the API interface itself. You could also provide an example for that, i.e. functions that read a PIN number from an secure keypad or open a DOOR depending on a verification. I know making a good product is hard and takes time. CMSIS is not perfect either. Let me know if you have any questions. Reinhard

5 years, 8 months

2
3
0 0

Re: [TF-M] PSA-Test Suite, 23 Crypto Tests failed

by Andrej Butok

Hi, So, I have submitted the mbedCrypto issue https://github.com/ARMmbed/mbed-crypto/issues/380 Several missed functions were implemented in the latest mbedCrypto. Please read the comment. They also need clarification about the PSA failed test: 1)"psa_asymmetric_encrypt does not have support for ECC keys" - that's true, the specification currently does not define any algorithm for psa_asymmetric_encrypt that uses ECC keys. What's the problem there? 2) For the incorrect key derivation error codes, what are the problematic inputs? 3) For "psa_generate_key generates incorrect key length for RSA", what are the problematic inputs? Could you clarify or this is the PSA-Test-Suite task? BTW: 1) mbedCrypto does not use the PSA test suite for testing (they have own tests). 2) PSA Test Suite does not inform mbedCrypto about found PSA issues. 3) TFM updates to the latest mbedCrypto have to be more often (ideally after each mbedCrypto release). 4) Better synchronization between the PSA Projects is needed. Thanks, Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Friday, February 28, 2020 1:20 PM To: Anton Komlev <Anton.Komlev(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] PSA-Test Suite, 23 Crypto Tests failed Hi Anton, OK. So this is the known issue. Is there any plan when it should be implemented? As the test-log is used for a PSA certification, may we disable the failed tests? BTW: As this is known issue, I did not notice it here https://github.com/ARMmbed/mbed-crypto/issues?page=1&q=is%3Aissue+is%3Aopen…<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> Thanks, Andrej 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: Friday, February 28, 2020 12:14 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: Re: [TF-M] PSA-Test Suite, 23 Crypto Tests failed Hello Andrej, As you noted, the main reason of test failures is unimplemented PSA functions. Those functions are directly dependent on Embed-Crypto library where they are missed or API is not adjusted. Recently TF-M was upgraded Embed-Crypto library from v1.0.0 to v3.0.1 and will continue so, increasing test suite coverage. Best regards, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M Sent: 28 February 2020 09:46 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] PSA-Test Suite, 23 Crypto Tests failed Hello, After update to the latest TFM and to the latest PSA-Test Suite, 23 Crypto Tests are failed: ************ Crypto Suite Report ********** TOTAL TESTS : 61 TOTAL PASSED : 37 TOTAL SIM ERROR : 0 TOTAL FAILED : 23 TOTAL SKIPPED : 1 ****************************************** The main reason is that many of PSA Crypto functions are not implemented by TFM. Is there a plan to fix it? Thanks, Andrej

5 years, 8 months

1
0
0 0

Call for a feedback on TF-M adaptation experience

by Reinhard Keil

Hi Anton, Hi Kevin, Thanks for starting this discussion. Let me give you my view on it. I think the problem can be structured in these parts: * Give documentation a better overall structure * Clearly separate single core v8M from dual core v7M * Describe the overall structure of the files and configuration options of TF-M * Describe resource requirements of TF-M core * Describe platform interfaces and provide templates * Describe how a Service is added to TF-M * Describe the tools/utilities that are used for TF-M While the debugging aspect raised by Kevin is relevant, it is a generic problem for all v8-M projects, not just for TF-M. I'm supportive to provide tools like pyOCD, but we need proper resourcing for it (maybe a separate project). It should be also noted that the industry works typically with tools like EWARM, MDK, or vendor specific tools like STCube or MCUxpresso. Hence we should not directly add too much tool-specific information to TF-M itself. Now let me give more context to each of the above topics. ---- Give documentation a better overall structure The Trusted Firmware-M documentation starts here: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… While this is already a User's Guide, it contains two more user's guides https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… For an outsider it is unclear where to start. Clearly separate single core v8M from dual core v7M This seems to be somewhat better now as it seems that below only refers to v8M single core: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… Describe the overall structure of the files and configuration options of TF-M I was looking for something like this: https://arm-software.github.io/CMSIS_5/RTOS2/html/pDirectory_Files.html https://arm-software.github.io/CMSIS_5/RTOS2/html/config_rtx5.html Describe resource requirements of TF-M core Take a look here to understand that request https://arm-software.github.io/CMSIS_5/RTOS2/html/pHardwareRequirements.html Important is also to document the interrupt behaviour (for both the secure and non-secure side). I know that this is tricky. For RTX we have this here: https://arm-software.github.io/CMSIS_5/RTOS2/html/cre_rtx_proj.html#cre_Usi… For TF-M this depends on a lot of other parameters. Describe platform interfaces and provide templates What I mean by that are the functions itself that are called by TF_M core. This is an example of the OS_Tick interface that RTX is using. TF-M core has similar interfaces to setup MPC, PPC, SAU, etc. https://arm-software.github.io/CMSIS_5/RTOS2/html/group__CMSIS__RTOS__TickA… Describe how a Service is added to TF-M Assume I have functions currently used in NS. What would be the process to move this functions into TF-M as a service. How does the API interface change, what modifications do I need (ideally I would like to have the same API interface after it). Are the any rules for the API interface itself. You could also provide an example for that, i.e. functions that read a PIN number from an secure keypad or open a DOOR depending on a verification. I know making a good product is hard and takes time. CMSIS is not perfect either. Let me know if you have any questions. Reinhard

5 years, 8 months

1
0
0 0

Re: [TF-M] PSA-Test Suite, 23 Crypto Tests failed

by Andrej Butok

Hi Anton, OK. So this is the known issue. Is there any plan when it should be implemented? As the test-log is used for a PSA certification, may we disable the failed tests? BTW: As this is known issue, I did not notice it here https://github.com/ARMmbed/mbed-crypto/issues?page=1&q=is%3Aissue+is%3Aopen… Thanks, Andrej From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Friday, February 28, 2020 12:14 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] PSA-Test Suite, 23 Crypto Tests failed Hello Andrej, As you noted, the main reason of test failures is unimplemented PSA functions. Those functions are directly dependent on Embed-Crypto library where they are missed or API is not adjusted. Recently TF-M was upgraded Embed-Crypto library from v1.0.0 to v3.0.1 and will continue so, increasing test suite coverage. Best regards, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M Sent: 28 February 2020 09:46 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] PSA-Test Suite, 23 Crypto Tests failed Hello, After update to the latest TFM and to the latest PSA-Test Suite, 23 Crypto Tests are failed: ************ Crypto Suite Report ********** TOTAL TESTS : 61 TOTAL PASSED : 37 TOTAL SIM ERROR : 0 TOTAL FAILED : 23 TOTAL SKIPPED : 1 ****************************************** The main reason is that many of PSA Crypto functions are not implemented by TFM. Is there a plan to fix it? Thanks, Andrej

5 years, 8 months

1
0
0 0

Re: [TF-M] PSA-Test Suite, 23 Crypto Tests failed

by Anton Komlev

Hello Andrej, As you noted, the main reason of test failures is unimplemented PSA functions. Those functions are directly dependent on Embed-Crypto library where they are missed or API is not adjusted. Recently TF-M was upgraded Embed-Crypto library from v1.0.0 to v3.0.1 and will continue so, increasing test suite coverage. Best regards, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 28 February 2020 09:46 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] PSA-Test Suite, 23 Crypto Tests failed Hello, After update to the latest TFM and to the latest PSA-Test Suite, 23 Crypto Tests are failed: ************ Crypto Suite Report ********** TOTAL TESTS : 61 TOTAL PASSED : 37 TOTAL SIM ERROR : 0 TOTAL FAILED : 23 TOTAL SKIPPED : 1 ****************************************** The main reason is that many of PSA Crypto functions are not implemented by TFM. Is there a plan to fix it? Thanks, Andrej

5 years, 8 months

1
0
0 0

Re: [TF-M] Call for a feedback on TF-M adaptation experience

by Kevin Townsend

Hi Anton, One particular difficulty I've encountered working with TF-M for the Zephyr certification demo app, and with the LPC55S69 port to upstream TF-M is the debugging experience with GDB and the dual execution environments. GDB can be quite powerful if you are familiar with it, but there is a definite learning curve, and the S and NS separation and the dual binary images (three with BL2) adds an additional degree of complexity. I think having a dedicated debugging tutorial around GDB would be very useful to people adopting TF-M and perhaps new to GDB, just to show how some basic debugging might happen, how to debug across the NS/S boundary, etc. For example, the '--tui' option for GDB may not be very well known, and it may be useful to highlight (see screenshots at the bottom of this issue: https://github.com/microbuilder/trusted-firmware-m/issues/1) Practical, step-by-step debugging documentation just seems like a good investment to help flatten this inevitable learning curve developing real-world solutions with TF-M? Best regards, Kevin On Thu, 27 Feb 2020 at 13:13, Anton Komlev via TF-M < tf-m(a)lists.trustedfirmware.org> wrote: > A kind reminder. > Your feedback is valuable all the time with no deadline defined. > > > > *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org> * On Behalf Of *Anton > Komlev via TF-M > *Sent:* 07 February 2020 13:13 > *To:* tf-m(a)lists.trustedfirmware.org > *Cc:* nd <nd(a)arm.com> > *Subject:* [TF-M] Call for a feedback on TF-M adaptation experience > > > > Dear All, > > > > As I mentioned on yesterday’s call, there is a concern on user experience > related to TF-M use. > > To In order to understand and potentially improve it I am looking for a > voice of partners who adopted TF-M project. > > Please share your experience and thoughts on parts which are good or might > be done better to simplify TF-M integration with your project. > > > > You feedback will be very appreciated in any form – as a response to this > mail or as a direct mail to me (anton.komlev(a)arm.com) if it’s more > comfortable for you. > > > > Thank you in advance, > > Anton > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m >

5 years, 8 months

2
1
0 0

PSA-Test Suite, 23 Crypto Tests failed

by Andrej Butok

Hello, After update to the latest TFM and to the latest PSA-Test Suite, 23 Crypto Tests are failed: ************ Crypto Suite Report ********** TOTAL TESTS : 61 TOTAL PASSED : 37 TOTAL SIM ERROR : 0 TOTAL FAILED : 23 TOTAL SKIPPED : 1 ****************************************** The main reason is that many of PSA Crypto functions are not implemented by TFM. Is there a plan to fix it? Thanks, Andrej

5 years, 8 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - March 5

by David Hu

Hi Anton, I'd like to share about the current design and draft implementation of TF-M Profile 1. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Tuesday, February 25, 2020 1:11 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - March 5 Dear All, The next Technical Forum is planned on Thursday, March 5 at 7:00-8:00 UTC. Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 8 months

1
0
0 0

Re: [TF-M] Call for a feedback on TF-M adaptation experience

by Anton Komlev

A kind reminder. Your feedback is valuable all the time with no deadline defined. From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 07 February 2020 13:13 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Call for a feedback on TF-M adaptation experience Dear All, As I mentioned on yesterday's call, there is a concern on user experience related to TF-M use. To In order to understand and potentially improve it I am looking for a voice of partners who adopted TF-M project. Please share your experience and thoughts on parts which are good or might be done better to simplify TF-M integration with your project. You feedback will be very appreciated in any form - as a response to this mail or as a direct mail to me (anton.komlev(a)arm.com<mailto:anton.komlev@arm.com>) if it's more comfortable for you. Thank you in advance, Anton

5 years, 8 months

1
0
0 0

Re: [TF-M] Update Crypto, SST and Attestation services to the latest versions

by Soby Mathew

Hi Everyone The below mentioned patches have been merged to TF-M master. The Open CI is also updated to pull in the right version of mbed-crypto (3.0.1) and it should now show results as expected. You may to have rebase your existing patches currently in review if you need to run CI tests. Best Regards Soby Mathew > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby > Mathew via TF-M > Sent: 18 February 2020 11:38 > To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> > Cc: nd <nd(a)arm.com> > Subject: [TF-M] Update Crypto, SST and Attestation services to the latest > versions > > Hi Everyone, > This is a heads up that there are patches in review which update the Crypto, > SST and Attestation services to latest versions of their respective specifications : > > 1. Crypto-service migration to Mbed Crypto 3.0.1 > > The patches is available here : > https://review.trustedfirmware.org/q/topic:%22crypto_update%22+(status:ope > n%20OR%20status:merged) > > This migrates the crypto service to the latest implementation of PSA > specification as implemented by mbed-crypto. > > 2. SST: Implement PSA Protected Storage 1.0 > > https://review.trustedfirmware.org/q/topic:%22sst-1.0- > update%22+(status:open%20OR%20status:merged) > > 3. Initial Attestation: Align interface to PSA API 1.0 > > https://git.trustedfirmware.org/trusted-firmware-m.git/commit/?h=feature- > psa-dev-api-update&id=b8d88ce6fb7c8e7301f32ab7f6b36dd796692f98 > > and > > https://git.trustedfirmware.org/trusted-firmware-m.git/commit/?h=feature- > psa-dev-api-update&id=12c02d16958c9dbd57a6bebe6f29b7a207355831 > > These patches are expected to be reviewed and merged back to the master in > the next couple of weeks. > > Best Regards > Soby Mathew > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 8 months

1
0
0 0

TF-M Technical Forum call - March 5

by Anton Komlev

Dear All, The next Technical Forum is planned on Thursday, March 5 at 7:00-8:00 UTC. Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 8 months

1
0
0 0

TF-M

by Konstantinos Chatzis

Hi all, As Anton already announced during last TF-M Tech Forums, we have recently started a deep review initiative for the TF-M project, with main focus to improve User Experience and reduce Onboarding Effort. The team is currently focusing on the following topics: * Repository and Housekeeping * Development Environment * Build System * Source tree structure and Abstraction Layers * Coding Rules * Documentation * Continuous Integration * Testing We are fully aware of the vast area the topics above cover but, focusing on the basic principles mentioned above, we intend to conclude to implementable solutions. It is therefore of significant importance that your individual or team's onboarding experience is shared with us and this mailing list. Please share any feedback based on your experience using and/or enhancing TF-M. Regards, Kostas 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.

5 years, 8 months

1
0
0 0

TF-M (PSA-Level) Fuzzing Tool

by Gary Morrison

Hi TF-Mers! Sincere apologies for the short notice, but at the next TF-M Tech Forum (in a few hours from now!), I will do a short presentation on a TF-M Fuzzing Tool that I’ve been working on for 2-3 months. Currently, it’s just a prototype, and I’ve only tested SST functionality so far, but we’re hoping we can get it out into the open-source arena soon, and get a little more brain power into improving its capabilities. (Apologies also that it’ll be at 1AM my time, out here in Austin, so please bear with me if I sound a little groggy! 😊) Hope you can join us! -- Gary Morrison gary.morrison(a)arm.com Principal SW Engineer Arm, Inc. Austin, TX. USA

5 years, 8 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - February 20

by Minos Galanakis

Hello all, I will be presenting about the use of "SFN" section for handling object placement in the Secure Side and how this may hide dragons. Regards, Minos Galanakis ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 11 February 2020 12:04 To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - February 20 Dear All, The next Open Technical Forum is planned on Thursday, February 20 at 7:00-8:00 UTC. Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 8 months

1
0
0 0

Update Crypto, SST and Attestation services to the latest versions

by Soby Mathew

Hi Everyone, This is a heads up that there are patches in review which update the Crypto, SST and Attestation services to latest versions of their respective specifications : 1. Crypto-service migration to Mbed Crypto 3.0.1 The patches is available here : https://review.trustedfirmware.org/q/topic:%22crypto_update%22+(status:open… This migrates the crypto service to the latest implementation of PSA specification as implemented by mbed-crypto. 2. SST: Implement PSA Protected Storage 1.0 https://review.trustedfirmware.org/q/topic:%22sst-1.0-update%22+(status:ope… 3. Initial Attestation: Align interface to PSA API 1.0 https://git.trustedfirmware.org/trusted-firmware-m.git/commit/?h=feature-ps… and https://git.trustedfirmware.org/trusted-firmware-m.git/commit/?h=feature-ps… These patches are expected to be reviewed and merged back to the master in the next couple of weeks. Best Regards Soby Mathew

5 years, 8 months

1
0
0 0

Call for review of dual-cpu test cases patches

by David Hu

Hi all, Thanks a lot for the reviews and support for dual-cpu multiple NS PSA client calls feature in TF-M. The patches were merged. Another patch set, which adds test cases for dual-cpu multiple NS PSA client calls, have also been reviewed several rounds in last 2 months, together with feature patches. I’d like to merge the test case patches *by this Thursday* if no further comment. Please help review https://review.trustedfirmware.org/q/topic:%22dualcpu-test-framework%22+(st… if you have interest. Any suggestion or comment 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: Wednesday, February 12, 2020 9:47 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Dual-cpu multiple NS PSA client calls feature Hi all, I’d like to submit the patches to enable multiple NS PSA client calls feature on dual-cpu system *by this week*, if no more comments. The patches have been reviewed for several rounds in last two months. Thanks a lot for all your reviews, comments and validation. The patch set can support NS side to start multiple outstanding PSA client calls concurrently, on dual-cpu system. The feature is enabled and verified on Cypress PSoC 64 platform. If you are interested, please take a look at https://review.trustedfirmware.org/q/topic:%22dualcpu-multi-client-call%22+…. The overall design is discussed in design documents https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/design_doc… and https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/design_doc… Comments and suggestions are still and always welcome. 😊 Thank you. Best regards, Hu Ziji

5 years, 8 months

1
0
0 0

[RFC] Update on SPRTL design document

by Ken Liu

Hi, There is something out of fashion in the first version SPRTL document, and the content is not well-formatted in a not ideal place. I updated parts of the document: - Re-format the document. - Fixes the descriptions for C runtime API, now we are re-using the headers, types and parts of toolchain library if possible. - Important change: Define a new 'SP Scratch' area and needs SPM cooperation to let the SPRTL can retrieve SP specific metadata. The new SP scratch area is used for resolving the context-based runtime API cannot retrieve the SP metadata problem since SPRTL is just a code. With this change, the SPRTL has a way to retrieve the SP metadata and then context-based runtime API is much easier in implementation. The patch is here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3457 And the issue: https://developer.trustedfirmware.org/T484 Thanks. /Ken

5 years, 8 months

1
0
0 0

Invitation: TF-M Tech Forum @ Every 2 weeks from 07:00 to 08:00 on Thursday from Thu 20 Feb to Fri 27 Mar (GMT) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. Title: TF-M Tech Forum This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Feel free to forward it to colleagues.Details of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h When: Every 2 weeks from 07:00 to 08:00 on Thursday from Thu 20 Feb to Fri 27 Mar United Kingdom Time Calendar: tf-m(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * tf-m(a)lists.trustedfirmware.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=MnZtamowZG5xZXQzNDdrZ… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-m(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M