- TF-M - lists.trustedfirmware.org

Review on Firmware Update service in TF-M

by Sherry Zhang

Hi, I created the patchset of adding the Firmware Update service in TF-M feature branch. I would like to ask you to review this patchset if you are interested in it. Top of the patchset: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7883 Regards, Sherry Zhang

4 years, 9 months

1
0
0 0

Arm Firmware Framework for M 1.1 Extensions Alpha specification

by Andrew Thoelke

Hi all, The PSA Firmware Framework for M 1.1 Extensions specification is now published on Arm Developer. This document introduces a set of updates and extensions to the Arm® Platform Security Architecture Firmware Framework (FF-M) specification, designed to build on the capabilities provided in version 1.0. This is an initial ALPHA release in order to enable wider review and feedback on the changes proposed to be included in the v1.1 specification. At this quality level, the changes and interfaces defined are not stable enough for product development. When the proposed extensions are sufficiently stable to be classed as Beta, they will be integrated into the FF-M version 1.1 specification. The 1.1 Extensions document can be downloaded from: https://developer.arm.com/documentation/aes0039/latest Both the 1.0 Specification and the 1.1 Extensions document are linked from the main PSA architecture page: https://developer.arm.com/architectures/security-architectures/platform-sec… Ken and I have presented a number of times at last year's Tech Forums on the proposals in the specification, most recently I provided a summary of the whole document on 10th December 2020. If you have any feedback, please provide it to arm.psa-feedback(a)arm.com, or discuss the proposals here in the TF-M mailing list. Regards, Andrew

4 years, 9 months

1
0
0 0

Re: [TF-M] Technical Forum call - Jan 7

by Kevin Peng

I'd like give a proposal on how to manage the version of tf-m-tests repo in auto-download mode of the build system. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Monday, January 4, 2021 5:33 PM To: Anton Komlev <Anton.Komlev(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Technical Forum call - Jan 7 Hi Anton, I'd like to give a brief introduction to TF-M generic threat model. Best regards, Hu Ziji 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: Monday, January 4, 2021 5:30 PM To: 'tf-m(a)lists.trustedfirmware.org' <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 - Jan 7 Hello, The next Technical Forum is planned on Thursday, January 7 at 6:00-07: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, 9 months

2
3
0 0

Re: [TF-M] [RFC] Static linker scripts for level 1 and 2 isolation

by Ken Liu

I think the link needs to be updated into: https://review.trustedfirmware.org/q/topic:%22static_linker_scripts%22+(sta… This would make the components arrangement more simpler than using a templating. But for level 3 we still have to using a templating as now there is no 'foreach' like functionalities supported in the ld/sct/icf. /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raef Coles via TF-M Sent: Wednesday, January 13, 2021 11:44 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] Static linker scripts for level 1 and 2 isolation Hi everyone I'd like to request comments on an upcoming change to the linker scripts. Because of some recent changes to the memory layout for level 1 and level 2 isolation, it's now possible to avoid the generation step via tfm_parse_manifest_lists.py for those linker files. This means that the files are static and have been committed into the source tree (as they used to be). We anticipate this change will make integrating TF-M into non-cmake buildsystems easier, as it will avoid one of the places where files need to be generated at build-time. The reason this is an RFC is that it is a potentially breaking change, but only for integrators _not_ using the cmake buildsystem. Currently the linker uses a large variety of pattern matches to organise the partition symbols, with these patterns being defined in the tfm_manifest_list.yaml. After this change, the linker will only look for two patterns: `*app_rot_partition*` and `*psa_rot_partition*` With the intention that the secure partitions will be compiled into a static library, where the filename is (for example) `libtfm_psa_rot_partition_crypto.a`. The cmake buildsystem will be updated to generate these filenames, but other integrators will need to adjust their compilation steps else the linking will fail. Any comments or concerns would be appreciated. Patches can be found at: https://review.trustedfirmware.org/q/topic:%23static_linker_scripts%22 Raef -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 9 months

1
0
0 0

Technical Forum call - January 21

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, January 21 at 15:00-16:00 UTC (US 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, 9 months

1
0
0 0

[RFC] Static linker scripts for level 1 and 2 isolation

by Raef Coles

Hi everyone I'd like to request comments on an upcoming change to the linker scripts. Because of some recent changes to the memory layout for level 1 and level 2 isolation, it's now possible to avoid the generation step via tfm_parse_manifest_lists.py for those linker files. This means that the files are static and have been committed into the source tree (as they used to be). We anticipate this change will make integrating TF-M into non-cmake buildsystems easier, as it will avoid one of the places where files need to be generated at build-time. The reason this is an RFC is that it is a potentially breaking change, but only for integrators _not_ using the cmake buildsystem. Currently the linker uses a large variety of pattern matches to organise the partition symbols, with these patterns being defined in the tfm_manifest_list.yaml. After this change, the linker will only look for two patterns: `*app_rot_partition*` and `*psa_rot_partition*` With the intention that the secure partitions will be compiled into a static library, where the filename is (for example) `libtfm_psa_rot_partition_crypto.a`. The cmake buildsystem will be updated to generate these filenames, but other integrators will need to adjust their compilation steps else the linking will fail. Any comments or concerns would be appreciated. Patches can be found at: https://review.trustedfirmware.org/q/topic:%23static_linker_scripts%22 Raef

4 years, 9 months

1
0
0 0

[RFC] Variable naming refinement in manifest tool

by Kevin Peng

Hi all, I made a patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7817> to refine the variable naming in manifest tooling, specifically the "manifest.manifest" in templates. I'm changing it to "partition.manifest" which should be more accurate and easy understanding. Broadcasting here for anyone has out-of-tree templates. And any comments are welcome. Best Regards, Kevin

4 years, 9 months

1
0
0 0

Re: [TF-M] TF-M generic threat model

by David Hu

Hi Antonio, Thanks a lot for reviewing the threat model and bringing up this topic. To fully mitigate the threat you mentioned, NSPE shall enforce NS tasks isolation and assign/manage NS identifications. IMHO, It mainly relies on non-secure side implementation. Therefore that threat can be covered in the scope of another threat model against NS side. TF-M is trying to figure out how to assist NSPE to manage and transfer NS identifications. Any suggestion or comment is welcome and helpful! 😊 Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio Ken IANNILLO via TF-M Sent: Wednesday, December 30, 2020 7:13 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] TF-M generic threat model Hi Hu, I read the threat model and I have a question regarding a potential threat. I’m not sure it should belong to this generic threat model or it is already included in one of those presented. The scenario is the following: a NS App X uses a RoT Service that store data private to X. Another NS App Y can fool the SPE to impersonate X and retrieve its private data. For example, X save a value in the secure storage and Y retrieves this value. TF-M prevents this using non secure client identification mechanism. This is a classic confused deputy problem. Can this be considered a threat in this model or should it belong to another model/TOE? Best, -- Antonio Ken Iannillo Research Scientist – SEDAN group SnT – Interdisciplinary Centre for Security, Reliability and Trust UNIVERSITÉ DU LUXEMBOURG CAMPUS KIRCHBERG 29, avenue John F. Kennedy L-1855 Luxembourg Kirchberg T +352 46 66 44 9660 https://akiannillo.github.io/

4 years, 10 months

2
2
0 0

Re: [TF-M] Technical Forum call - Jan 7

by David Hu

Hi Anton, I'd like to give a brief introduction to TF-M generic threat model. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Monday, January 4, 2021 5:30 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] Technical Forum call - Jan 7 Hello, The next Technical Forum is planned on Thursday, January 7 at 6:00-07: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, 10 months

1
0
0 0

Technical Forum call - Jan 7

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, January 7 at 6:00-07: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, 10 months

1
0
0 0

[RFC] Remove unused section 'TFM_UNPRIV_DATA'

by Ken Liu

Hi, The existing section 'TFM_UNPRIV_DATA' now holds nothing - it was designed for holding some data belong to the unprivileged code block, while now the unprivileged code is required as read-only and no place for its read-write data. Remove this section as it is unused; also remove those code objects exists in the unprivileged code section but has read-write data: 'platform_retarget_dev.o' and 'device_definition.o'. This patch changes some sources inside the platforms, so the platform owner please help to check if that matters: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7754 Thanks. /Ken

4 years, 10 months

1
1
0 0

Re: [TF-M] TF-M generic threat model

by Antonio Ken IANNILLO

Hi Hu, I read the threat model and I have a question regarding a potential threat. I’m not sure it should belong to this generic threat model or it is already included in one of those presented. The scenario is the following: a NS App X uses a RoT Service that store data private to X. Another NS App Y can fool the SPE to impersonate X and retrieve its private data. For example, X save a value in the secure storage and Y retrieves this value. TF-M prevents this using non secure client identification mechanism. This is a classic confused deputy problem. Can this be considered a threat in this model or should it belong to another model/TOE? Best, -- Antonio Ken Iannillo Research Scientist – SEDAN group SnT – Interdisciplinary Centre for Security, Reliability and Trust UNIVERSITÉ DU LUXEMBOURG CAMPUS KIRCHBERG 29, avenue John F. Kennedy L-1855 Luxembourg Kirchberg T +352 46 66 44 9660 https://akiannillo.github.io/

4 years, 10 months

1
0
0 0

Re: [TF-M] RFC on changes to install directory structure

by Xinyu Zhang

Hi Raef, Please merge this patch for CI together with your patches. https://review.trustedfirmware.org/c/ci/tf-m-ci-scripts/+/7755 BR, Xinyu -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raef Coles via TF-M Sent: Tuesday, December 29, 2020 7:56 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] RFC on changes to install directory structure Hi everyone I'd like to request for comment on some changes to the TF-M installed files. Since this is an interface change (though minor), changes to it might cause issues with existing TF-M integrations. The current install directory looks like: install ├── export │ └── tfm └── outputs This doesn't give any useful information about what is contained in each directory. The proposed replacement is: install ├── image_signing ├── interface └── outputs Where the contents of `export/tfm` have been moved into `interface`, which better captures the contents of that directory. `image_signing` is new in the patchset, and contains the scripts, layouts and keys needed to sign an NS image. The final improvement in the patchset is the ability to control the location of the `install` directory via TFM_INSTALL_PATH which could be useful for integrators. Feedback would be appreciated if you feel that these new directory names could be improved, or if this change would cause significant breakage for your TF-M integration. Patchset here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7398/6 Raef -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 10 months

1
0
0 0

RFC on changes to install directory structure

by Raef Coles

Hi everyone I'd like to request for comment on some changes to the TF-M installed files. Since this is an interface change (though minor), changes to it might cause issues with existing TF-M integrations. The current install directory looks like: install ├── export │ └── tfm └── outputs This doesn't give any useful information about what is contained in each directory. The proposed replacement is: install ├── image_signing ├── interface └── outputs Where the contents of `export/tfm` have been moved into `interface`, which better captures the contents of that directory. `image_signing` is new in the patchset, and contains the scripts, layouts and keys needed to sign an NS image. The final improvement in the patchset is the ability to control the location of the `install` directory via TFM_INSTALL_PATH which could be useful for integrators. Feedback would be appreciated if you feel that these new directory names could be improved, or if this change would cause significant breakage for your TF-M integration. Patchset here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7398/6 Raef

4 years, 10 months

1
0
0 0

Changes to TF-M NS interface build

by David Hu

Hi all, Happy holiday! I'd like to let you know that non-secure interface build has been moved from TF-M to tf-m-tests in following patches: TF-M: https://review.trustedfirmware.org/q/topic:%22move-ns-api%22+(status:open%2… Tf-m-tests: https://review.trustedfirmware.org/q/topic:%22add-ns-api%22+(status:open%20… After that change, the .c files under TF-M interface/src are built during non-secure side build. It aligns with the actual process of NS integration with TF-M. Moreover, non-secure specific flags, which control TF-M NS interface, can be configured and managed in non-secure side build, without affecting TF-M secure part. Please modify tf-m-tests app/CMakeLists.txt for future changes to non-secure interface build. Thanks. Best regards, Hu Ziji

4 years, 10 months

1
0
0 0

Re: [TF-M] Discuss how to support secure Flash in TF-M

by David Hu

Hi Poppy, Some rough ideas about secure Flash support in TF-M. IMHO, there can be two options: 1. Based on ITS service Secure Flash acts as the flash driver at the backend of ITS service. The secure Flash driver can invoke Crypto secure service instead of mbedTLS to avoid building two duplicates of mbedTLS library. The cryptographic operation and key management are implemented in secure Flash driver and can be transparent to ITS service while some initialization can be necessary. But it cannot support persistent keys otherwise it will generate a circular dependency between ITS and Crypto services. 1. Based on PS service With PS service, the cryptographic operations can be implemented by PS crypto steps, such as encryption and authentication. Secure Flash driver only covers communication with remote device. We don’t have to worry about the circular dependency with Crypto service. However, there are some limitations of PS service currently: * PS service cannot support multiple asset keys for cryptography. * PS service cannot work alone without ITS service. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Edward Yang via TF-M Sent: Monday, December 21, 2020 1:22 PM To: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>> Cc: Julien Su <juliensu(a)mxic.com.tw<mailto:juliensu@mxic.com.tw>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Aaron Zhu <AaronZhu(a)mxic.com.cn<mailto:AaronZhu@mxic.com.cn>>; TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] Discuss how to support secure Flash in TF-M Hi Jamie, >As I understand it, one of the uses of the secure flash is to store crypto keys, so the dependency from Crypto to the secure flash needs to be kept. The crypto keys you mentioned in your previous reply are the crypto keys used to encrypt the communication channel between host MCU with the secure Flash? Or the secrets such as (public/private)key pairs used in TLS protocol? If the former,I think these keys may be stored in NVM memories such as OTP or internal flash of MCU,and these keys can be loaded and imported as transient keys in RAM with a key handle during such as secure boot, then we can call PSA Crypto service with these key handles, in this case, the dependency from Crypto to secure flash doesn't exist. Best Regards, Poppy Wu 吴偏偏 Macronix Microelectronics (Suzhou) Co.,Ltd 旺宏微电子（苏州）有限公司 No. 55, Su Hong Xi Road ,SIP, Suzhou, PRC, 215021 苏州工业园区苏虹西路55号 Tel: 86-512-62580888 EXT: 3147 Fax: 86-512-62585399 ZIP: 215021 http://www.mxic.com.cn<http://www.mxic.com.cn/> Poppy Wu/CHINA/MXIC 2020/12/16 14:20 To Edward Yang <EdwardYang(a)mxic.com.cn<mailto:EdwardYang@mxic.com.cn>> cc Subject Re: [TF-M] Discuss how to support secure Flash in TF-MLink<Notes://cnmail01/482583DD001E2E02/DABA975B9FB113EB852564B5001283EA/6BDCE39917970ADF4825863F00689523> Hi Jamie, Thank you for your reply. You are right,the secure Flash can be used to store sensitive information like TLS private keys,in this application, during TLS handshake,Crypto service depends on secure Flash driver to get these private keys,so the dependency from Crypto to the secure flash needs to be kept. And you mentioned implementation of crypto functions varies depending on the platform(some platforms have hardware crypto module while the others have to depend on software crypto library), platfrom without HW crypto module could use AES encrypt/decrypt functions from a software crypto library (e.g. Mbed TLS). As I understand, currently tfm Crypto service also uses Mbed TLS as the backend software crypto library by default. I am wondering if secure Flash driver could call this Mbed TLS library APIs (such as mbedtls_aes_encrypt（）) directly? Best Regards, Poppy Wu 吴偏偏 Macronix Microelectronics (Suzhou) Co.,Ltd 旺宏微电子（苏州）有限公司 No. 55, Su Hong Xi Road ,SIP, Suzhou, PRC, 215021 苏州工业园区苏虹西路55号 Tel: 86-512-62580888 EXT: 3147 Fax: 86-512-62585399 ZIP: 215021 http://www.mxic.com.cn<http://www.mxic.com.cn/> Jamie Fox via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent by: "TF-M" <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> 2020/12/16 03:02 Please respond to Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>> To Edward Yang <EdwardYang(a)mxic.com.cn<mailto:EdwardYang@mxic.com.cn>> cc nd <nd(a)arm.com<mailto:nd@arm.com>>, "tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>" <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject Re: [TF-M] Discuss how to support secure Flash in TF-M Hi, The trouble with calling the PSA Crypto functions from your secure flash driver is that it will create a circular dependency between the ITS service and the Crypto service. Crypto uses ITS to store its keys, but then the secure flash driver calls the Crypto service again to encrypt the data. These circular dependencies between partitions are forbidden in TF-M. As I understand it, one of the uses of the secure flash is to store crypto keys, so the dependency from Crypto to the secure flash needs to be kept. That means the dependency on the Crypto service in the secure flash driver needs to be avoided. I think ideally the best way to do this would be to use hardware crypto functions available in the platform instead of PSA Crypto APIs inside the flash driver, but if no crypto hardware is available then you could use AES encrypt/decrypt functions from a software crypto library (e.g. Mbed TLS). Hope that helps. Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Edward Yang via TF-M Sent: 15 December 2020 10:08 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Discuss how to support secure Flash in TF-M Dear all, I would like to discuss how to add secure Flash support in TF-M. Firstly, I want to describe the motivation of adding secure Flash support in TF-M. Currently ARM TF-M provides protected storage service(PS service for short) to implement security protection on external normal storage, however this type external normal storage is still vulnerable to unauthorized physical modifications/erasing and cloning.Macronix and other Flash memory suppliers have developed secure Flash products to enhance the security in external flash devices. Secure Flash enables mutual authentication between itself and host MCU/SoC and only permits the authorised host to perform access, besides, the communication channel between host MCU/SoC and secure Flash is protected by encryption, authentication, data scrambling, and frame sequencing with monotonic counters as shown below, so the secure Flash provides dependable defense against unauthorised access, man-in-the-middle, replay, sniffing and other security threats. [cid:image001.gif@01D6D91C.DAC89B20] If we port TF-M to a platform which uses secure Flash as external flash,then secure Flash driver should be added to TF-M.However,compared with nomal external flash driver,secure Flash driver needs extra crypto functions(such as calling AES crypto functions to encrypt/decrypt data), if the secure Flash driver is placed in platform folder in TF-M code structure as a backend of ITS service, I don't know whether secure Flash driver is allowed to call Crypto service(such as psa_aead_encrypt(), psa_aead_decrypt() )directly.If not, are there any other solutions to perform crypto operations in secure Flash driver? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd Tel: 86-512-62580888 EXT: 3147 Fax: 86-512-62585399 ZIP: 215021 http://www.mxic.com.cn<http://www.mxic.com.cn/> CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================-- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as it attachments from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

4 years, 10 months

1
0
0 0

Re: [TF-M] TF-M generic threat model

by David Hu

Hi all, I’d like to merge the generic threat model by the end of this week if no further comment. I’m also going to give a brief introduction to TF-M threat modeling in future technical forum. 😊 Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Thursday, December 10, 2020 9:37 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M generic threat model Hi all, A generic threat model of TF-M has been uploaded to gerrit. It is a key step in TF-M Threat Modeling. Please help review the threat model document via the link below. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7492 Any question or comment is welcome! Best regards, Hu Ziji

4 years, 10 months

1
0
0 0

Discuss how to support secure Flash in TF-M

by Edward Yang

Hi Jamie, >As I understand it, one of the uses of the secure flash is to store crypto keys, so the dependency from Crypto to the secure flash needs to be kept. The crypto keys you mentioned in your previous reply are the crypto keys used to encrypt the communication channel between host MCU with the secure Flash? Or the secrets such as (public/private)key pairs used in TLS protocol? If the former,I think these keys may be stored in NVM memories such as OTP or internal flash of MCU,and these keys can be loaded and imported as transient keys in RAM with a key handle during such as secure boot, then we can call PSA Crypto service with these key handles, in this case, the dependency from Crypto to secure flash doesn't exist. Best Regards, Poppy Wu 吴偏偏 Macronix Microelectronics (Suzhou) Co.,Ltd 旺宏微电子（苏州）有限公司 No. 55, Su Hong Xi Road ,SIP, Suzhou, PRC, 215021 苏州工业园区苏虹西路55号 Tel: 86-512-62580888 EXT: 3147 Fax: 86-512-62585399 ZIP: 215021 http://www.mxic.com.cn Poppy Wu/CHINA/MXIC 2020/12/16 14:20 To Edward Yang <EdwardYang(a)mxic.com.cn> cc Subject Re: [TF-M] Discuss how to support secure Flash in TF-MLink Hi Jamie, Thank you for your reply. You are right,the secure Flash can be used to store sensitive information like TLS private keys,in this application, during TLS handshake,Crypto service depends on secure Flash driver to get these private keys,so the dependency from Crypto to the secure flash needs to be kept. And you mentioned implementation of crypto functions varies depending on the platform(some platforms have hardware crypto module while the others have to depend on software crypto library), platfrom without HW crypto module could use AES encrypt/decrypt functions from a software crypto library (e.g. Mbed TLS). As I understand, currently tfm Crypto service also uses Mbed TLS as the backend software crypto library by default. I am wondering if secure Flash driver could call this Mbed TLS library APIs (such as mbedtls_aes_encrypt（）) directly? Best Regards, Poppy Wu 吴偏偏 Macronix Microelectronics (Suzhou) Co.,Ltd 旺宏微电子（苏州）有限公司 No. 55, Su Hong Xi Road ,SIP, Suzhou, PRC, 215021 苏州工业园区苏虹西路55号 Tel: 86-512-62580888 EXT: 3147 Fax: 86-512-62585399 ZIP: 215021 http://www.mxic.com.cn Jamie Fox via TF-M <tf-m(a)lists.trustedfirmware.org> Sent by: "TF-M" <tf-m-bounces(a)lists.trustedfirmware.org> 2020/12/16 03:02 Please respond to Jamie Fox <Jamie.Fox(a)arm.com> To Edward Yang <EdwardYang(a)mxic.com.cn> cc nd <nd(a)arm.com>, "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Subject Re: [TF-M] Discuss how to support secure Flash in TF-M Hi, The trouble with calling the PSA Crypto functions from your secure flash driver is that it will create a circular dependency between the ITS service and the Crypto service. Crypto uses ITS to store its keys, but then the secure flash driver calls the Crypto service again to encrypt the data. These circular dependencies between partitions are forbidden in TF-M. As I understand it, one of the uses of the secure flash is to store crypto keys, so the dependency from Crypto to the secure flash needs to be kept. That means the dependency on the Crypto service in the secure flash driver needs to be avoided. I think ideally the best way to do this would be to use hardware crypto functions available in the platform instead of PSA Crypto APIs inside the flash driver, but if no crypto hardware is available then you could use AES encrypt/decrypt functions from a software crypto library (e.g. Mbed TLS). Hope that helps. Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: 15 December 2020 10:08 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Discuss how to support secure Flash in TF-M Dear all, I would like to discuss how to add secure Flash support in TF-M. Firstly, I want to describe the motivation of adding secure Flash support in TF-M. Currently ARM TF-M provides protected storage service(PS service for short) to implement security protection on external normal storage, however this type external normal storage is still vulnerable to unauthorized physical modifications/erasing and cloning.Macronix and other Flash memory suppliers have developed secure Flash products to enhance the security in external flash devices. Secure Flash enables mutual authentication between itself and host MCU/SoC and only permits the authorised host to perform access, besides, the communication channel between host MCU/SoC and secure Flash is protected by encryption, authentication, data scrambling, and frame sequencing with monotonic counters as shown below, so the secure Flash provides dependable defense against unauthorised access, man-in-the-middle, replay, sniffing and other security threats. If we port TF-M to a platform which uses secure Flash as external flash,then secure Flash driver should be added to TF-M.However,compared with nomal external flash driver,secure Flash driver needs extra crypto functions(such as calling AES crypto functions to encrypt/decrypt data), if the secure Flash driver is placed in platform folder in TF-M code structure as a backend of ITS service, I don't know whether secure Flash driver is allowed to call Crypto service(such as psa_aead_encrypt(), psa_aead_decrypt() )directly.If not, are there any other solutions to perform crypto operations in secure Flash driver? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd Tel: 86-512-62580888 EXT: 3147 Fax: 86-512-62585399 ZIP: 215021 http://www.mxic.com.cn CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================-- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m ============================================================================ CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as it attachments from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

4 years, 10 months

1
0
0 0

Discuss how to support secure Flash in TF-M

by Edward Yang

Hi Jamie, Thank you for your reply. You are right,the secure Flash can be used to store sensitive information like TLS private keys,in this application, during TLS handshake,Crypto service depends on secure Flash driver to get these private keys,so the dependency from Crypto to the secure flash needs to be kept. And you mentioned implementation of crypto functions varies depending on the platform(some platforms have hardware crypto module while the others have to depend on software crypto library), platfrom without HW crypto module could use AES encrypt/decrypt functions from a software crypto library (e.g. Mbed TLS). As I understand, currently tfm Crypto service also uses Mbed TLS as the backend software crypto library by default. I am wondering if secure Flash driver could call this Mbed TLS library APIs (such as mbedtls_aes_encrypt（）) directly? Best Regards, Poppy Wu 吴偏偏 Macronix Microelectronics (Suzhou) Co.,Ltd 旺宏微电子（苏州）有限公司 No. 55, Su Hong Xi Road ,SIP, Suzhou, PRC, 215021 苏州工业园区苏虹西路55号 Tel: 86-512-62580888 EXT: 3147 Fax: 86-512-62585399 ZIP: 215021 http://www.mxic.com.cn Jamie Fox via TF-M <tf-m(a)lists.trustedfirmware.org> Sent by: "TF-M" <tf-m-bounces(a)lists.trustedfirmware.org> 2020/12/16 03:02 Please respond to Jamie Fox <Jamie.Fox(a)arm.com> To Edward Yang <EdwardYang(a)mxic.com.cn> cc nd <nd(a)arm.com>, "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Subject Re: [TF-M] Discuss how to support secure Flash in TF-M Hi, The trouble with calling the PSA Crypto functions from your secure flash driver is that it will create a circular dependency between the ITS service and the Crypto service. Crypto uses ITS to store its keys, but then the secure flash driver calls the Crypto service again to encrypt the data. These circular dependencies between partitions are forbidden in TF-M. As I understand it, one of the uses of the secure flash is to store crypto keys, so the dependency from Crypto to the secure flash needs to be kept. That means the dependency on the Crypto service in the secure flash driver needs to be avoided. I think ideally the best way to do this would be to use hardware crypto functions available in the platform instead of PSA Crypto APIs inside the flash driver, but if no crypto hardware is available then you could use AES encrypt/decrypt functions from a software crypto library (e.g. Mbed TLS). Hope that helps. Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: 15 December 2020 10:08 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Discuss how to support secure Flash in TF-M Dear all, I would like to discuss how to add secure Flash support in TF-M. Firstly, I want to describe the motivation of adding secure Flash support in TF-M. Currently ARM TF-M provides protected storage service(PS service for short) to implement security protection on external normal storage, however this type external normal storage is still vulnerable to unauthorized physical modifications/erasing and cloning.Macronix and other Flash memory suppliers have developed secure Flash products to enhance the security in external flash devices. Secure Flash enables mutual authentication between itself and host MCU/SoC and only permits the authorised host to perform access, besides, the communication channel between host MCU/SoC and secure Flash is protected by encryption, authentication, data scrambling, and frame sequencing with monotonic counters as shown below, so the secure Flash provides dependable defense against unauthorised access, man-in-the-middle, replay, sniffing and other security threats. If we port TF-M to a platform which uses secure Flash as external flash,then secure Flash driver should be added to TF-M.However,compared with nomal external flash driver,secure Flash driver needs extra crypto functions(such as calling AES crypto functions to encrypt/decrypt data), if the secure Flash driver is placed in platform folder in TF-M code structure as a backend of ITS service, I don't know whether secure Flash driver is allowed to call Crypto service(such as psa_aead_encrypt(), psa_aead_decrypt() )directly.If not, are there any other solutions to perform crypto operations in secure Flash driver? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd Tel: 86-512-62580888 EXT: 3147 Fax: 86-512-62585399 ZIP: 215021 http://www.mxic.com.cn CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================-- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m ============================================================================ CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

4 years, 10 months

2
1
0 0

[CANCELLED] TF-M Technical Forum - December 24

by Anton Komlev

Hello, Probably the next Technical Forum will not be very popular, planned on Thursday, Dec 24 (US friendly time zone). Let's cancel this slot to meet again in January 7. Wish you pleasant holidays and Happy New Year. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

4 years, 10 months

1
0
0 0

Tiny update on the code review guidelines

by Ken Liu

Hi, The purpose of code review guidelines is trying to provide some reference for reviewers. It is still in the evaluation stage. After it gets matured then we can pointer to this document as a required reference. I updated some part of it, the main changes: - The private symbol (static inside a source file) can have a prefix for easier source viewing, a reader would know it is a symbol in the file he/she is viewing which can avoid cross-files 'find reference' operation in the editor. - Clarifies the header file types and the usage: A 'interface' header file is for abstraction, and a typical 'include' header contains exported functionalities for external module usage. Please help to take a look if you have time - as this is one of the upcoming updates, I will treat the review contents out of the changed lines into a new patch if it is possible. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7577 Thanks. /Ken

4 years, 10 months

1
0
0 0

Re: [TF-M] Discuss how to support secure Flash in TF-M

by Jamie Fox

Hi, The trouble with calling the PSA Crypto functions from your secure flash driver is that it will create a circular dependency between the ITS service and the Crypto service. Crypto uses ITS to store its keys, but then the secure flash driver calls the Crypto service again to encrypt the data. These circular dependencies between partitions are forbidden in TF-M. As I understand it, one of the uses of the secure flash is to store crypto keys, so the dependency from Crypto to the secure flash needs to be kept. That means the dependency on the Crypto service in the secure flash driver needs to be avoided. I think ideally the best way to do this would be to use hardware crypto functions available in the platform instead of PSA Crypto APIs inside the flash driver, but if no crypto hardware is available then you could use AES encrypt/decrypt functions from a software crypto library (e.g. Mbed TLS). Hope that helps. Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: 15 December 2020 10:08 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Discuss how to support secure Flash in TF-M Dear all, I would like to discuss how to add secure Flash support in TF-M. Firstly, I want to describe the motivation of adding secure Flash support in TF-M. Currently ARM TF-M provides protected storage service(PS service for short) to implement security protection on external normal storage, however this type external normal storage is still vulnerable to unauthorized physical modifications/erasing and cloning.Macronix and other Flash memory suppliers have developed secure Flash products to enhance the security in external flash devices. Secure Flash enables mutual authentication between itself and host MCU/SoC and only permits the authorised host to perform access, besides, the communication channel between host MCU/SoC and secure Flash is protected by encryption, authentication, data scrambling, and frame sequencing with monotonic counters as shown below, so the secure Flash provides dependable defense against unauthorised access, man-in-the-middle, replay, sniffing and other security threats. [cid:image001.gif@01D6D313.1B0E4E10] If we port TF-M to a platform which uses secure Flash as external flash,then secure Flash driver should be added to TF-M.However,compared with nomal external flash driver,secure Flash driver needs extra crypto functions(such as calling AES crypto functions to encrypt/decrypt data), if the secure Flash driver is placed in platform folder in TF-M code structure as a backend of ITS service, I don't know whether secure Flash driver is allowed to call Crypto service(such as psa_aead_encrypt(), psa_aead_decrypt() )directly.If not, are there any other solutions to perform crypto operations in secure Flash driver? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd Tel: 86-512-62580888 EXT: 3147 Fax: 86-512-62585399 ZIP: 215021 http://www.mxic.com.cn<http://www.mxic.com.cn/> CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

4 years, 10 months

1
0
0 0

Discuss how to support secure Flash in TF-M

by Edward Yang

Dear all, I would like to discuss how to add secure Flash support in TF-M. Firstly, I want to describe the motivation of adding secure Flash support in TF-M. Currently ARM TF-M provides protected storage service(PS service for short) to implement security protection on external normal storage, however this type external normal storage is still vulnerable to unauthorized physical modifications/erasing and cloning.Macronix and other Flash memory suppliers have developed secure Flash products to enhance the security in external flash devices. Secure Flash enables mutual authentication between itself and host MCU/SoC and only permits the authorised host to perform access, besides, the communication channel between host MCU/SoC and secure Flash is protected by encryption, authentication, data scrambling, and frame sequencing with monotonic counters as shown below, so the secure Flash provides dependable defense against unauthorised access, man-in-the-middle, replay, sniffing and other security threats. If we port TF-M to a platform which uses secure Flash as external flash,then secure Flash driver should be added to TF-M.However,compared with nomal external flash driver,secure Flash driver needs extra crypto functions(such as calling AES crypto functions to encrypt/decrypt data), if the secure Flash driver is placed in platform folder in TF-M code structure as a backend of ITS service, I don't know whether secure Flash driver is allowed to call Crypto service(such as psa_aead_encrypt(), psa_aead_decrypt() )directly.If not, are there any other solutions to perform crypto operations in secure Flash driver? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd Tel: 86-512-62580888 EXT: 3147 Fax: 86-512-62585399 ZIP: 215021 http://www.mxic.com.cn ============================================================================ CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

4 years, 10 months

1
0
0 0

ITS and PS HALs pushed for review

by Jamie Fox

Hi all, I have pushed for review the new Internal Trusted Storage and Protected Storage HAL designs, as well as an initial implementation for AN521. I will update the change for all other platforms once the design has settled down. It expands the ITS and PS HALs to cover all flash and filesystem configuration parameters required from the platform. The CMSIS Flash Driver is exposed to abstract the flash device itself. ITS is updated to use the new HALs, with its_flash_info_external.c, its_flash_info_internal.c and its_flash.c removed. The ITS filesystem is updated to take a configuration struct as an initialisation parameter, which is filled using values from the HAL. The gerrit reviews are: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4781 https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7598 Kind regards, Jamie

4 years, 10 months

1
0
0 0

Re: [TF-M] [RFC] Moving partition stack into partition BSS/ZI.

by Ken Liu

😉 No response got yet, as it is closing to Xmas, plan to merge them before end of this week (18th Dec) if there is no more voice. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Monday, December 7, 2020 3:22 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] Moving partition stack into partition BSS/ZI. Hi, We are now allocating partition’s stack inside linker script file, and there are two external patches trying to move these stack definitions into partition’s BSS/ZI: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5374/5 https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6508/1 The advantages: - Simplify the linker script/sct templating, stack items can be saved. - Stack as global just uses 8 bytes alignment instead of wider bytes alignment (such as 32 bytes in most of the cases). - Stack is private data, putting private data together is a direct way. And the disadvantages: - Stack memory and global memory may affect each other – actually we don’t apply such protecting mechanism now? Anything I missed? Any feedbacks are welcome. We would collect your feedbacks and update the patches if they are still available after your comments. Other proposals are welcome, too. Thanks. /Ken

4 years, 10 months

1
0
0 0

Proposal to fix the version of tf-m-tests for auto-downloading in build system

by Kevin Peng

Hi all, The build system currently fetches the latest "master" of tf-m-tests repo for building, if auto-download dependencies mode is used (which is the default). This would break the building when: * TF-M and tf-m-tests have dependency changes got merged * A developer is working with a local copy of TF-M that has not been updated to the latest. * The developer does a clean build with auto-downloading * The build system fetch the latest tf-m-tests repo which is not compatible with the local copy of TF-M We've seen this kind of issue reported in mailing list. To solve this problem, the proposal<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7550> of fixing the "TFM_TEST_REPO_VERSION" to a hash or tag is raised. With this change, the build system would download a compatible version always. The version of the test repo is not required to be updated for every commit in the test repo. (Guide line on when to update the version is required and it's still under discussion - welcome for ideas.) Developers want a different version can always override "TFM_TEST_REPO_PATH" to a local copy to build. Best Regards, Kevin

4 years, 10 months

1
0
0 0

Re: [TF-M] Secure Enclave solution in TF-M + New path for Musca-B1 platform

by Mark Horvath

Dear All, The Secure Enclave patches have been merged and caused a minor source structure change. The platform so far named musca_b1 became musca_b1/sse_200, because we added support to the other subsystem on the Musca-B1 board, musca_b1/secure_enclave. So to build onto the old Musca-B1 platform the -DTFM_PLATFORM=musca_b1/sse_200 flag will be needed. All information about the Secure Enclave topic can be found in these rsts: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/desig… https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/refer… https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e… Best regards, Mark From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Mark Horvath via TF-M Sent: 09 December 2020 10:11 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] Secure Enclave solution in TF-M Dear All, The patches for the Secure Enclave topic are planned to be merged soon if no further comments raised. https://review.trustedfirmware.org/q/topic:%22Secure+Enclave%22+(status:ope… Best regards, Mark From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Mark Horvath via TF-M Sent: 03 December 2020 16:38 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: Re: [TF-M] Secure Enclave solution in TF-M Dear All, I would like to merge the Secure Enclave topic at about middle of next week, feel free to give any feedback. https://review.trustedfirmware.org/q/topic:%22Secure+Enclave%22+(status:ope… Best regards, Mark From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Mark Horvath via TF-M Sent: 14 September 2020 21:00 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] Secure Enclave solution in TF-M Dear All, Following the tech forum presentation (back in 6th August) I uploaded the draft design document for the Secure Enclave topic: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5653 I also updated the first implementation of the proposed solution for the Musca-B1 board with minimal features, marked as WIP: https://review.trustedfirmware.org/q/topic:%22Secure+Enclave%22+(status:ope… Limitations, missing features, notes: * No support for isolation level2 on SSE-200 * Protected Storage is an Application RoT partition, but PS also moved to Secure Enclave * Some regression tests running on secure side of SSE-200 fail as all messages are forwarded with the same client ID to Secure Enclave * All IPC message forwarding is a blocking call * Only one message is put into the mailbox at a time * Musca-B1 related documentation is not complete yet * Generated files are not committed, manifest parser should be run before build. * The BL0 component mentioned in the tech forum presentation is not uploaded, as it is based on the new cmake system, and not so interesting right now * Cmake changes are rudimentary, will be rebased to new cmake system. Any feedback very welcomed! Best regards, Márk Horváth Senior Software Engineer Mark.Horvath(a)arm.com<mailto:Mark.Horvath@arm.com> Arm Hungary Kft., Corvin Offices II, Crystal Tower, Budapest, Futó u. 45. H-1082 Hungary www.arm.com<http://www.arm.com/>

4 years, 10 months

1
0
0 0

TF-M generic threat model

by David Hu

Hi all, A generic threat model of TF-M has been uploaded to gerrit. It is a key step in TF-M Threat Modeling. Please help review the threat model document via the link below. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7492 Any question or comment is welcome! Best regards, Hu Ziji

4 years, 10 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - December 10

by Anton Komlev

Hi All The agenda for the forum: 1. PSA FF-M v1.1 alpha specification overview. Do not miss it! 2. AOB Thanks, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrew Thoelke via TF-M Sent: 09 December 2020 15:42 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M Technical Forum call - December 10 Hi all, The proposed version 1.1 extensions to PSA FF-M version 1.0 will be published as an alpha specification in the next few weeks. I would like to update the Technical Forum on the final set of features for v1.1. (Some of these have already been presented earlier this year to the forum) Kind regards, Andrew 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: 02 December 2020 15:45 To: 'tf-m(a)lists.trustedfirmware.org' <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 - December 10 Hello, The next Technical Forum is planned on Thursday, December 10 at 6:00-07: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, 10 months

1
0
0 0

SW countermeasure against physical attacks in SPE

by Tamas Ban

Hi, PSA Level 3 certification mandates protection against physical attack at a certain extent. MCUboot v1.7.0 release already contains SW countermeasures against fault injection attacks. These can be used at device boot-up time. But fault injection attacks are not targeting only the device boot-up time, instead they could be applied against the runtime firmware. The following design proposal is addressing this threat: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7476 Prototype implementation on AN521 and Musca-B1 target (top of the patch set): https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7475/1 Review and comments are welcome! BR, Tamas Ban

4 years, 10 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - December 10

by Andrew Thoelke

Hi all, The proposed version 1.1 extensions to PSA FF-M version 1.0 will be published as an alpha specification in the next few weeks. I would like to update the Technical Forum on the final set of features for v1.1. (Some of these have already been presented earlier this year to the forum) Kind regards, Andrew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 02 December 2020 15:45 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 - December 10 Hello, The next Technical Forum is planned on Thursday, December 10 at 6:00-07: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, 10 months

1
0
0 0

Re: [TF-M] Secure Enclave solution in TF-M

by Mark Horvath

Dear All, The patches for the Secure Enclave topic are planned to be merged soon if no further comments raised. https://review.trustedfirmware.org/q/topic:%22Secure+Enclave%22+(status:ope… Best regards, Mark From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Mark Horvath via TF-M Sent: 03 December 2020 16:38 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] Secure Enclave solution in TF-M Dear All, I would like to merge the Secure Enclave topic at about middle of next week, feel free to give any feedback. https://review.trustedfirmware.org/q/topic:%22Secure+Enclave%22+(status:ope… Best regards, Mark From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Mark Horvath via TF-M Sent: 14 September 2020 21:00 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] Secure Enclave solution in TF-M Dear All, Following the tech forum presentation (back in 6th August) I uploaded the draft design document for the Secure Enclave topic: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5653 I also updated the first implementation of the proposed solution for the Musca-B1 board with minimal features, marked as WIP: https://review.trustedfirmware.org/q/topic:%22Secure+Enclave%22+(status:ope… Limitations, missing features, notes: * No support for isolation level2 on SSE-200 * Protected Storage is an Application RoT partition, but PS also moved to Secure Enclave * Some regression tests running on secure side of SSE-200 fail as all messages are forwarded with the same client ID to Secure Enclave * All IPC message forwarding is a blocking call * Only one message is put into the mailbox at a time * Musca-B1 related documentation is not complete yet * Generated files are not committed, manifest parser should be run before build. * The BL0 component mentioned in the tech forum presentation is not uploaded, as it is based on the new cmake system, and not so interesting right now * Cmake changes are rudimentary, will be rebased to new cmake system. Any feedback very welcomed! Best regards, Márk Horváth Senior Software Engineer Mark.Horvath(a)arm.com<mailto:Mark.Horvath@arm.com> Arm Hungary Kft., Corvin Offices II, Crystal Tower, Budapest, Futó u. 45. H-1082 Hungary www.arm.com<http://www.arm.com/>

4 years, 10 months

1
0
0 0

TF-M openCI nightly notification mail list is ready to subscribe

by Karl Zhang

Hi, There is a CI notification mail list enabled, it aims to send the failure info of TF-M nightly job to the subscribers without spam to a big group. If you are interested in the master branch nightly verification status, feel free to add your email to the list. Subscribing: https://lists.trustedfirmware.org/mailman/listinfo/tf-m-ci-notifications The notification only triggers a notification when CI build or test fail occur from the nightly job. Thanks Karl

4 years, 10 months

1
0
0 0

IAR, problems building with 8.50.9

by Thomas Törnblom

IAR released a new service pack late last week, version 8.50.9. This service pack includes a new compiler version, which although thoroughly tested, apparently introduced a new intricate bug, which causes at least the musca_a mcuboot to fail. The issue has been identified and fixed, and the next release should have this fix. I have no date for when this will be released or in what form. So for the time being, please do not upgrade above version 8.50.7. Thanks, Thomas -- *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>

4 years, 10 months

1
0
0 0

[RFC] Moving partition stack into partition BSS/ZI.

by Ken Liu

Hi, We are now allocating partition's stack inside linker script file, and there are two external patches trying to move these stack definitions into partition's BSS/ZI: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5374/5 https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6508/1 The advantages: - Simplify the linker script/sct templating, stack items can be saved. - Stack as global just uses 8 bytes alignment instead of wider bytes alignment (such as 32 bytes in most of the cases). - Stack is private data, putting private data together is a direct way. And the disadvantages: - Stack memory and global memory may affect each other - actually we don't apply such protecting mechanism now? Anything I missed? Any feedbacks are welcome. We would collect your feedbacks and update the patches if they are still available after your comments. Other proposals are welcome, too. Thanks. /Ken

4 years, 11 months

1
0
0 0

[RFC] Build: Move UART symbols to SPRTL

by Kevin Peng

Hi Platform owners, explicitly ST, Nordic and NXP owners. Could you confirm that this patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6678> wouldn't break your platforms. The patch changes the build system to put the UART drivers to the SPRTL. It is important to improve the isolation implementations. For more details, please see the patch. We will wait for one more week and merge it as is if no feedbacks. Any feedbacks from others are welcome always. Best Regards, Kevin

4 years, 11 months

1
0
0 0

Re: [TF-M] Secure Enclave solution in TF-M

by Mark Horvath

Dear All, I would like to merge the Secure Enclave topic at about middle of next week, feel free to give any feedback. https://review.trustedfirmware.org/q/topic:%22Secure+Enclave%22+(status:ope… Best regards, Mark From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Mark Horvath via TF-M Sent: 14 September 2020 21:00 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Secure Enclave solution in TF-M Dear All, Following the tech forum presentation (back in 6th August) I uploaded the draft design document for the Secure Enclave topic: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5653 I also updated the first implementation of the proposed solution for the Musca-B1 board with minimal features, marked as WIP: https://review.trustedfirmware.org/q/topic:%22Secure+Enclave%22+(status:ope… Limitations, missing features, notes: * No support for isolation level2 on SSE-200 * Protected Storage is an Application RoT partition, but PS also moved to Secure Enclave * Some regression tests running on secure side of SSE-200 fail as all messages are forwarded with the same client ID to Secure Enclave * All IPC message forwarding is a blocking call * Only one message is put into the mailbox at a time * Musca-B1 related documentation is not complete yet * Generated files are not committed, manifest parser should be run before build. * The BL0 component mentioned in the tech forum presentation is not uploaded, as it is based on the new cmake system, and not so interesting right now * Cmake changes are rudimentary, will be rebased to new cmake system. Any feedback very welcomed! Best regards, Márk Horváth Senior Software Engineer Mark.Horvath(a)arm.com<mailto:Mark.Horvath@arm.com> Arm Hungary Kft., Corvin Offices II, Crystal Tower, Budapest, Futó u. 45. H-1082 Hungary www.arm.com<http://www.arm.com/>

4 years, 11 months

1
0
0 0

Review request of TF-M dual-cpu mailbox enhancement

by David Hu

Hi all, Could you please help the patches to enhance TF-M dual-cpu mailbox, as discussed in last Technical Forum? Improvements to make NS RTOS port easier: https://review.trustedfirmware.org/q/topic:%22mailbox-enhance%22+(status:op… A new working model to support NS RTOS application isolation better: https://review.trustedfirmware.org/q/topic:%22mailbox-dedicated-thread%22+(… Any comment is welcome! Please see the slides for the basic ideas of the enhancements mentioned above. Slides link: https://www.trustedfirmware.org/docs/TF-M_Dual-cpu_NSPE_mailbox_enhancement… Best regards, Hu Ziji

4 years, 11 months

1
0
0 0

Re: [TF-M] Review request for adding External Trusted Secure Storage service in TF-M

by Jamie Fox

Hi, Thank you for the proposal, I have commented in the Gerrit review. Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: 02 December 2020 14:28 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Review request for adding External Trusted Secure Storage service in TF-M Hi everyone, Please help review the following design proposal of adding External Trusted Secure Storage service in TF-M,any comments and suggestions will be appreciated. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7295 Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd http://www.mxic.com.cn<http://www.mxic.com.cn/> ======================================================== CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

4 years, 11 months

1
0
0 0

TF-M Technical Forum call - December 10

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, December 10 at 6:00-07: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, 11 months

1
0
0 0

Re: [TF-M] Externally override flash layout and pin configurations (out-of-tree platforms?)

by Rønningstad, Øyvind

I've created a proof of concept for allowing out-of-tree platforms here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7301 It was simpler than I had thought :) Øyvind From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Thursday, November 26, 2020 07:57 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Externally override flash layout and pin configurations (out-of-tree platforms?) Hi, In the ideal case with HAL API, the platform itself can decide which variant's layout to be applied, selected by build system switches or just some header files. Because SPM could get what it needed by HAL API run-time. It can be mostly done inside the platform folder if one platform has the variants management already. Others please give inputs as this is a very useful topic, we can list down the problem we met during integration first. BR /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Rønningstad, Øyvind via TF-M Sent: Thursday, November 26, 2020 3:47 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: Rasmussen, Torsten <Torsten.Rasmussen(a)nordicsemi.no<mailto:Torsten.Rasmussen@nordicsemi.no>> Subject: [TF-M] Externally override flash layout and pin configurations (out-of-tree platforms?) Hi all In our work integrating TFM into Zephyr and the nRF Connect SDK, it's apparent that the integration would be a lot smoother if we could specify TFM's flash layout externally. Looking into it a bit, I came up with a draft proposal here: https://github.com/zephyrproject-rtos/trusted-firmware-m/pull/18/files<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> We could just modify our own platforms to this and be happy, but I'm wondering if there would be interest in standardizing something. Now, a related problem is: How can we make it easier to add multiple boards based on a single chip. For the Nordic platforms we've already separated the chip-specific code (nRF9160/nRF5340) from the board specific code (DK/PDK), and for the boards, it really boils down to pin configurations. We could allow to specify pins via Cmake instead, to easily allow users to support their production PCBs. But (this was brought up in the above PR) we can also solve both problems by adding support for out-of-tree platforms. For example, allow TFM to be built like so: cmake -DTFM_PLATFORM=../../../../my_custom_board ... This would probably be less work that designing a new interface for overriding flash layouts and pin configurations. What are your thoughts? BR, Øyvind Rønningstad

4 years, 11 months

1
0
0 0

Review request for adding External Trusted Secure Storage service in TF-M

by Edward Yang

Hi everyone, Please help review the following design proposal of adding External Trusted Secure Storage service in TF-M,any comments and suggestions will be appreciated. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7295 Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd http://www.mxic.com.cn ======================================================== ============================================================================ CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

4 years, 11 months

1
0
0 0

Review request for adding External Trusted Secure Storage service in TF-M

by Edward Yang

Hi everyone, Please help review the following design proposal of adding External Trusted Secure Storage service in TF-M,any comments and suggestions will be appreciated. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7295 Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd http://www.mxic.com.cn ======================================================== ============================================================================ CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

4 years, 11 months

1
0
0 0

Deprecation of platform MPS2/SSE-200_AWS

by Marton Berke

Hi Everyone, I would like to propose the deprecation of platform MPS2/SSE-200_AWS because the platform is no longer available to use: https://aws.amazon.com/marketplace/pp/ARM-Ltd-DesignStart-FPGA-on-Cloud-Cor… As per the process, this proposal is open for discussion for a period of 4 weeks and if there are no major objections, the platform should be marked as deprecated and removed from TF-M master after next release. Thanks and Best regards, Marton Berke

4 years, 11 months

1
0
0 0

Re: [TF-M] Technical Forum call - November 26

by Karl Zhang

Hi Anton I would have an introduction to TF-M openCI. Thanks Karl ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of David Hu via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Monday, November 23, 2020 2:10 PM To: Anton Komlev <Anton.Komlev(a)arm.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] Technical Forum call - November 26 Hi Anton, I’d like to share a proposal to improve dual-cpu mailbox. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Thursday, November 19, 2020 4:59 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Technical Forum call - November 26 Hello, The next Technical Forum is planned on Thursday, November 26 at 15:00-16:00 GMT (US friendly 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, 11 months

2
1
0 0

Re: [TF-M] gcc compiler requirement documentation

by Shawn Shan

Hi Chris, Thanks for point out this. Here is the fix: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7226 Regards, Shawn From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: Thursday, November 26, 2020 2:55 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] gcc compiler requirement documentation Looking at docs/getting_started//tfm_sw_requirement.rst it says that the version requirement for gcc is "GNU Arm compiler v7.3.1+". then it describes where to get that toolchain, but in that section the two versions it suggests are "GNU Arm Embedded Toolchain: 6-2017-q1-update" and "GNU Arm Embedded Toolchain: 7-2018-q2-update". The former is gcc version 6.3.1, which doesn't actually meet the requirements. Chris Brand Sr Prin Software Engr, MCD: WIRELESS Cypress Semiconductor Corp. An Infineon Technologies Company #320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com> This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

4 years, 11 months

1
0
0 0

Re: [TF-M] Externally override flash layout and pin configurations (out-of-tree platforms?)

by Ken Liu

Hi, In the ideal case with HAL API, the platform itself can decide which variant's layout to be applied, selected by build system switches or just some header files. Because SPM could get what it needed by HAL API run-time. It can be mostly done inside the platform folder if one platform has the variants management already. Others please give inputs as this is a very useful topic, we can list down the problem we met during integration first. BR /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Rønningstad, Øyvind via TF-M Sent: Thursday, November 26, 2020 3:47 AM To: tf-m(a)lists.trustedfirmware.org Cc: Rasmussen, Torsten <Torsten.Rasmussen(a)nordicsemi.no> Subject: [TF-M] Externally override flash layout and pin configurations (out-of-tree platforms?) Hi all In our work integrating TFM into Zephyr and the nRF Connect SDK, it's apparent that the integration would be a lot smoother if we could specify TFM's flash layout externally. Looking into it a bit, I came up with a draft proposal here: https://github.com/zephyrproject-rtos/trusted-firmware-m/pull/18/files We could just modify our own platforms to this and be happy, but I'm wondering if there would be interest in standardizing something. Now, a related problem is: How can we make it easier to add multiple boards based on a single chip. For the Nordic platforms we've already separated the chip-specific code (nRF9160/nRF5340) from the board specific code (DK/PDK), and for the boards, it really boils down to pin configurations. We could allow to specify pins via Cmake instead, to easily allow users to support their production PCBs. But (this was brought up in the above PR) we can also solve both problems by adding support for out-of-tree platforms. For example, allow TFM to be built like so: cmake -DTFM_PLATFORM=../../../../my_custom_board ... This would probably be less work that designing a new interface for overriding flash layouts and pin configurations. What are your thoughts? BR, Øyvind Rønningstad

4 years, 11 months

1
0
0 0

Externally override flash layout and pin configurations (out-of-tree platforms?)

by Rønningstad, Øyvind

Hi all In our work integrating TFM into Zephyr and the nRF Connect SDK, it's apparent that the integration would be a lot smoother if we could specify TFM's flash layout externally. Looking into it a bit, I came up with a draft proposal here: https://github.com/zephyrproject-rtos/trusted-firmware-m/pull/18/files We could just modify our own platforms to this and be happy, but I'm wondering if there would be interest in standardizing something. Now, a related problem is: How can we make it easier to add multiple boards based on a single chip. For the Nordic platforms we've already separated the chip-specific code (nRF9160/nRF5340) from the board specific code (DK/PDK), and for the boards, it really boils down to pin configurations. We could allow to specify pins via Cmake instead, to easily allow users to support their production PCBs. But (this was brought up in the above PR) we can also solve both problems by adding support for out-of-tree platforms. For example, allow TFM to be built like so: cmake -DTFM_PLATFORM=../../../../my_custom_board ... This would probably be less work that designing a new interface for overriding flash layouts and pin configurations. What are your thoughts? BR, Øyvind Rønningstad

4 years, 11 months

1
0
0 0

gcc compiler requirement documentation

by Christopher Brand

Looking at docs/getting_started//tfm_sw_requirement.rst it says that the version requirement for gcc is "GNU Arm compiler v7.3.1+". then it describes where to get that toolchain, but in that section the two versions it suggests are "GNU Arm Embedded Toolchain: 6-2017-q1-update" and "GNU Arm Embedded Toolchain: 7-2018-q2-update". The former is gcc version 6.3.1, which doesn't actually meet the requirements. Chris Brand Sr Prin Software Engr, MCD: WIRELESS Cypress Semiconductor Corp. An Infineon Technologies Company #320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com> This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

4 years, 11 months

1
0
0 0

Re: [TF-M] MCUBOOT_LOG_LEVEL description confusing/wrong

by Tamas Ban

Hi Thomas, Here is the fix: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7196 Actually since the CMake refactor the default value can be overridden from the command line, so it is possible to enable the logging even in Release builds. BR Tamas -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 2020. november 25., szerda 8:50 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] MCUBOOT_LOG_LEVEL description confusing/wrong The description of how to set MCUBOOT_LOG_LEVEL in tfm_secure_boot.rst appears wrong, or at least unclear. --- - MCUBOOT_LOG_LEVEL: Can be used to configure the level of logging in MCUBoot. The possible values are the following: - **LOG_LEVEL_OFF** - **LOG_LEVEL_ERROR** - **LOG_LEVEL_WARNING** - **LOG_LEVEL_INFO** - **LOG_LEVEL_DEBUG** The logging in MCUBoot can be disabled and thus the code size can be reduced by setting it to ``LOG_LEVEL_OFF``. Its value depends on the build type. If the build type is ``Debug`` and a value has been provided (e.g. through the command line or the CMake GUI) then that value will be used, otherwise it is ``LOG_LEVEL_INFO`` by default. In case of different kinds of ``Release`` builds its value is set to ``LOG_LEVEL_OFF`` (any other value will be overridden). --- I tried enabling MCUBOOT_LOG_LEVEL_DEBUG by adding -DMCUBOOT_LOG_LEVEL=LOG_LEVEL_DEBUG to the cmake command line, but that set the level to -1. I also tried -DMCUBOOT_LOG_LEVEL=4, which also set it to -1. I then noticed that the default setting in CMakeCache.txt is "MCUBOOT_LOG_LEVEL:STRING=INFO", so I instead used -DMCUBOOT_LOG_LEVEL=DEBUG, which worked. I would also like to be able to use logging for Release builds, as this may assist chasing down optimization issues. Thomas -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 11 months

1
0
0 0

TF-M v1.2.0 release

by Anton Komlev

Hello, TF-M project released version v1.2.0, tagged as TF-Mv1.2.0. This release has started using adopted semantic versioning as described in the release_process.rst<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/contr…> Please take a look into the release notes for the new features and changes. Thanks to everyone who directly and indirectly contributed to this milestone. Anton Komlev TF-M technical lead Arm Ltd.

4 years, 11 months

1
0
0 0

MCUBOOT_LOG_LEVEL description confusing/wrong

by Thomas Törnblom

The description of how to set MCUBOOT_LOG_LEVEL in tfm_secure_boot.rst appears wrong, or at least unclear. --- - MCUBOOT_LOG_LEVEL: Can be used to configure the level of logging in MCUBoot. The possible values are the following: - **LOG_LEVEL_OFF** - **LOG_LEVEL_ERROR** - **LOG_LEVEL_WARNING** - **LOG_LEVEL_INFO** - **LOG_LEVEL_DEBUG** The logging in MCUBoot can be disabled and thus the code size can be reduced by setting it to ``LOG_LEVEL_OFF``. Its value depends on the build type. If the build type is ``Debug`` and a value has been provided (e.g. through the command line or the CMake GUI) then that value will be used, otherwise it is ``LOG_LEVEL_INFO`` by default. In case of different kinds of ``Release`` builds its value is set to ``LOG_LEVEL_OFF`` (any other value will be overridden). --- I tried enabling MCUBOOT_LOG_LEVEL_DEBUG by adding -DMCUBOOT_LOG_LEVEL=LOG_LEVEL_DEBUG to the cmake command line, but that set the level to -1. I also tried -DMCUBOOT_LOG_LEVEL=4, which also set it to -1. I then noticed that the default setting in CMakeCache.txt is "MCUBOOT_LOG_LEVEL:STRING=INFO", so I instead used -DMCUBOOT_LOG_LEVEL=DEBUG, which worked. I would also like to be able to use logging for Release builds, as this may assist chasing down optimization issues. Thomas

4 years, 11 months

1
0
0 0

Re: [TF-M] Technical Forum call - November 26

by David Hu

Hi Anton, I'd like to share a proposal to improve dual-cpu mailbox. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Thursday, November 19, 2020 4:59 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Technical Forum call - November 26 Hello, The next Technical Forum is planned on Thursday, November 26 at 15:00-16:00 GMT (US friendly 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, 11 months

1
0
0 0

Re: [TF-M] Code freeze heads up for TF-M v1.2

by Anton Komlev

Hi, New TF-M Release Candidate 3 is tagged by TF-Mv1.2-RC3 Please update all repositories as it contain all fixes for issues found in RC2. Best regards, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 11 November 2020 15:34 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Code freeze heads up for TF-M v1.2 Hi, New TF-M Release Candidate 2 is tagged by TF-Mv1.2-RC2. Please update all repositories as it contain fixes for issues found in RC1. Best regards, 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: 04 November 2020 16:35 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] Code freeze heads up for TF-M v1.2 Hi, All TF-M repositories are tagged with TF-Mv1.2-RC1 tag, marking the code freeze and beginning of the release candidate testing. 1. tf-m-tools 2. tf-m-tests 3. trusted-firmware-m 4. tf-m-ci-scripts 5. tf-m-job-configs Please use this tag for tests and report all issues found here. The best, 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: 02 November 2020 14:28 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] Code freeze heads up for TF-M v1.2 Hi All, This is a reminder and heads up that TF-Mv1.2 release is planned for the end of November and TF-M code repository is aimed for freeze on Nov 4th (Wed), tagged by TF-Mv1.2-RC1 for testing. Availability of the tag will be notified via this mailing list. Thanks, Anton

4 years, 11 months

1
0
0 0

Technical Forum call - November 26

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, November 26 at 15:00-16:00 GMT (US friendly 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, 11 months

1
0
0 0

Re: [TF-M] Semantic versioning

by Minos Galanakis

Hi, Following up the current discussions on semantic versioning, I have prepared a patch <https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7075/1> . Feel free to review and comment. Expanded patch link: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7075/1 Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Gyorgy Szing via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 16 November 2020 17:32 To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Semantic versioning Hi, Well, yes. Not sure what backwards compatibility would mean in a complex application with a configurable set of services and service capabilities. Semantic versioning could work quite well for components (i.e. secure service implementations) though. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 16 November 2020 18:04 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Semantic versioning Hi George, All, Thanks for the thoughts. Can I assume that you suggest to stay with option 1? The semantic versioning was proposed several times and sounds reasonable because it gives a meaning to each version component so downstream projects could rely on it. Yes, a version of a product represents some quality status but in my view that depends on convention. For downstream projects reference, TF-M issues releases periodically so a version represents a stable point in time and occasionally brings new features / fixes. Cheers, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: 16 November 2020 08:17 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] Semantic versioning Hi, I miss something here. What is being discussed, what is the purpose of changing version numbering? * Is more granularity needed and each or some lesser quality levels should be assigned a version number too? Currently a new version number is assigned if a new SW set reaches “Release” quality level. (Whatever that might be.) * Is there need for expressing backwards compatibility better? * Is the aim to enhance existing version numbers just by making them following a well-defined standard? I have the feeling different people are talking about different sub-topics. I think the most important purpose or having release numbers is to express quality. It could help on version numbers if quality would be defined cleaner. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Peng via TF-M Sent: 16 November 2020 09:06 To: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>>; David Wang <David.Wang(a)arm.com<mailto:David.Wang@arm.com>>; Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>>; 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] Semantic versioning I would vote for Option 3, and “.2” - Backport the fixing patches to the existing v1.x.0 tag. – This provides the flexibility to have a released version with critical fixes only. If TF-M users want all the changes between the release and the fix they can take the master branch as well. Best Regards, Kevin 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: Monday, November 16, 2020 3:45 PM To: David Wang <David.Wang(a)arm.com<mailto:David.Wang@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Semantic versioning Hi Anton, Option 3 seems more reasonable to me. Hi David, I think we can leave tag v1.x.0 as it is and create a new tag v1.x.1 for this critical fix on master branch. It can be more easier to distinguish between tags. 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 Wang via TF-M Sent: Monday, November 16, 2020 2:53 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] Semantic versioning Hi Anton, Option 3 is a good. Just to clarify, for example, if v1.x.0 released, and we got a critical fix 2 months later. Then in your proposal, we: * Tag the current master which includes the fixing patch (and may also include some other merged/ongoing features after last release) as v1.x.1, or * Backport the fixing patches to the existing v1.x.0 tag (keep it in a new branch) and tag the tip of the v1.x release branch as v1.x.1 Thanks. Regards, David Wang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Townsend via TF-M Sent: Saturday, November 14, 2020 3:45 AM To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Semantic versioning Hi Anton, Option 3 seems the most sensible to me for a project like TF-M at this stage. Best regards, Kevin On Fri, 13 Nov 2020 at 20:19, Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: Hi, I would like to continue the discussion on TF-M semantic versioning started on the last tech forum. Currently TF-M uses a loosely defined versioning schema with major and minor versions, following TF-A. There are several calls to switch TF-M to semantic versioning. Here is the reminder of the meaning: (https://semver.org/) v1.2.3 : 1. MAJOR version when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards compatible manner, and 3. PATCH version when you make backwards compatible bug fixes. This is a good way to go for a mature project but TF-M will overkill from everyday re-versioning because of new patches. It was discussed on the forum and several options were proposed: 1. Do nothing, reasonably bumping up versions on release time only. 2. Use semantic versioning ignoring changes in PATCH by keeping it 0. So upcoming version could be: v1.2.0, next v1.3.0 and nothing in between. 3. Use option 2 but change PATCH when critical code change delivered within release cadence like a security vulnerability fix to let down-stream project relay on a fixed version. 4. Other ideas? Personally I tend to follow option 3 but looking for the community input. Thanks, Anton. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 11 months

2
1
0 0

Blog for Amazon FreeRTOS Gateway Demo based on TF-M Profile Small

by David Wang

Hi, In Linaro Virtual Connect 20 (LVC20), Shebu and I presented a session "Scalable Security Using Trusted Firmware-M Profiles" (ref[1]). It basically shows an example of using FreeRTOS+TF-M Profile Small on armv8m devices to connect to AWS cloud through a Gateway. The key features demonstrated in the example: * Symmetric cipher based secure connection - TLS PSK * Usage of (symmetric) attestation * Device-Gateway-Cloud secure channel example A blog (https://www.trustedfirmware.org/blog/amazon-freertos-tfm-blog/) is shared in tf.org if you want to know more details of the design. Thanks. Ref: [1] Scalable Security Using Trusted Firmware-M Profiles - https://connect.linaro.org/resources/lvc20/lvc20-213/ Regards, David Wang ARM Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142)

4 years, 11 months

1
0
0 0

Re: [TF-M] Generated files location

by Ken Liu

Hi Andrej, Thanks for reporting this. It looks like the dependency on TFM_TEST_PATH matters. We need to define something for managing these generated files. /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Friday, November 13, 2020 9:54 PM To: Raef Coles <Raef.Coles(a)arm.com>; Anton Komlev <Anton.Komlev(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Generated files location Hi, FYI: For Windows (not Liniux) users, the command have to be: ... set TFM_TEST_PATH=../tf-m-tests/test python tools/tfm_parse_manifest_list.py -m tools/tfm_manifest_list.yaml -f tools/tfm_generated_file_list.yaml -o <output> ... Also, all required Python modules have to be installed before (PyYAML, Jinja2) Best regards, Andrej Butok -----Original Message----- From: Raef Coles <Raef.Coles(a)arm.com> Sent: Thursday, November 12, 2020 2:11 PM To: Anton Komlev <Anton.Komlev(a)arm.com>; Andrej Butok <andrey.butok(a)nxp.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: Generated files location Hi, As an intermediate step, we've made a modification to the file generation code so that file can be generated without cmake being run. This generation can be run by: ``` python3 tools/tfm_parse_manifest_list.py -m tools/tfm_manifest_list.yaml -f tools/tfm_generated_file_list.yaml -o <output dir> ``` Which will output the files into the specified output directory. if the `-o` flag is not provided then the files will be generated into the TFM source tree. Note that this method still requires knowledge of the location of some dependencies, as this cannot be provided by cmake. When run in standalone mode, these paths are gathered from environment variables, and generation will fail if those variables are not set. Thus: ``` env TFM_TEST_PATH=$(realpath ../tf-m-tests/test) python3 tools/tfm_parse_manifest_list.py -m tools/tfm_manifest_list.yaml -f tools/tfm_generated_file_list.yaml ``` Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 20 October 2020 08:39 To: Anton Komlev Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Generated files location Hi Anton If it's not possible to avoid a file generation now, it's good to have pre-generated files for a most typical configuration (l2, IPC etc.). As I mentioned before, ideally to use TFM as a real component/framework without generation of any source code. BUT If you believe, this requirement breaks a TFM concept, just tell us. Thanks, Andrej From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Tuesday, October 20, 2020 9:27 AM To: tf-m(a)lists.trustedfirmware.org Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Generated files location Hi Andrej, Essentially, do you mean to move the files back to code tree and synch them with templates manually as it was ? Cheers, Anton From: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>> Sent: 19 October 2020 16:15 To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: RE: Generated files location Hi Anton, Another option: 3. Avoid the mandatory on-the-fly generation. Try to make TFM a component/framework, which is configurable by compile & run time parameters. 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: Monday, October 19, 2020 5:00 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] Generated files location Hi, Some source files in TF-M are templated and generated inside /<build_dir>/generated/ on the fly as a part of build process. This guaranty consistency between templates and generated but might make a trouble for IDE, where not all source files exist at the first run. I see 2 options for solution: 1. Explicitly generate those files via cmake as a part of IDE project creation (1 time action) 2. Relay on CMSIS Pack for IDE, where generated files must be presents Any alternative thoughts? Anton -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 11 months

1
0
0 0

Re: [TF-M] Semantic versioning

by Gyorgy Szing

Hi, Well, yes. Not sure what backwards compatibility would mean in a complex application with a configurable set of services and service capabilities. Semantic versioning could work quite well for components (i.e. secure service implementations) though. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 16 November 2020 18:04 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Semantic versioning Hi George, All, Thanks for the thoughts. Can I assume that you suggest to stay with option 1? The semantic versioning was proposed several times and sounds reasonable because it gives a meaning to each version component so downstream projects could rely on it. Yes, a version of a product represents some quality status but in my view that depends on convention. For downstream projects reference, TF-M issues releases periodically so a version represents a stable point in time and occasionally brings new features / fixes. Cheers, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: 16 November 2020 08:17 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] Semantic versioning Hi, I miss something here. What is being discussed, what is the purpose of changing version numbering? * Is more granularity needed and each or some lesser quality levels should be assigned a version number too? Currently a new version number is assigned if a new SW set reaches “Release” quality level. (Whatever that might be.) * Is there need for expressing backwards compatibility better? * Is the aim to enhance existing version numbers just by making them following a well-defined standard? I have the feeling different people are talking about different sub-topics. I think the most important purpose or having release numbers is to express quality. It could help on version numbers if quality would be defined cleaner. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Peng via TF-M Sent: 16 November 2020 09:06 To: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>>; David Wang <David.Wang(a)arm.com<mailto:David.Wang@arm.com>>; Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>>; 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] Semantic versioning I would vote for Option 3, and “.2” - Backport the fixing patches to the existing v1.x.0 tag. – This provides the flexibility to have a released version with critical fixes only. If TF-M users want all the changes between the release and the fix they can take the master branch as well. Best Regards, Kevin 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: Monday, November 16, 2020 3:45 PM To: David Wang <David.Wang(a)arm.com<mailto:David.Wang@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Semantic versioning Hi Anton, Option 3 seems more reasonable to me. Hi David, I think we can leave tag v1.x.0 as it is and create a new tag v1.x.1 for this critical fix on master branch. It can be more easier to distinguish between tags. 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 Wang via TF-M Sent: Monday, November 16, 2020 2:53 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] Semantic versioning Hi Anton, Option 3 is a good. Just to clarify, for example, if v1.x.0 released, and we got a critical fix 2 months later. Then in your proposal, we: * Tag the current master which includes the fixing patch (and may also include some other merged/ongoing features after last release) as v1.x.1, or * Backport the fixing patches to the existing v1.x.0 tag (keep it in a new branch) and tag the tip of the v1.x release branch as v1.x.1 Thanks. Regards, David Wang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Townsend via TF-M Sent: Saturday, November 14, 2020 3:45 AM To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Semantic versioning Hi Anton, Option 3 seems the most sensible to me for a project like TF-M at this stage. Best regards, Kevin On Fri, 13 Nov 2020 at 20:19, Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: Hi, I would like to continue the discussion on TF-M semantic versioning started on the last tech forum. Currently TF-M uses a loosely defined versioning schema with major and minor versions, following TF-A. There are several calls to switch TF-M to semantic versioning. Here is the reminder of the meaning: (https://semver.org/) v1.2.3 : 1. MAJOR version when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards compatible manner, and 3. PATCH version when you make backwards compatible bug fixes. This is a good way to go for a mature project but TF-M will overkill from everyday re-versioning because of new patches. It was discussed on the forum and several options were proposed: 1. Do nothing, reasonably bumping up versions on release time only. 2. Use semantic versioning ignoring changes in PATCH by keeping it 0. So upcoming version could be: v1.2.0, next v1.3.0 and nothing in between. 3. Use option 2 but change PATCH when critical code change delivered within release cadence like a security vulnerability fix to let down-stream project relay on a fixed version. 4. Other ideas? Personally I tend to follow option 3 but looking for the community input. Thanks, Anton. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 11 months

1
0
0 0

Re: [TF-M] Semantic versioning

by Anton Komlev

Hi George, All, Thanks for the thoughts. Can I assume that you suggest to stay with option 1? The semantic versioning was proposed several times and sounds reasonable because it gives a meaning to each version component so downstream projects could rely on it. Yes, a version of a product represents some quality status but in my view that depends on convention. For downstream projects reference, TF-M issues releases periodically so a version represents a stable point in time and occasionally brings new features / fixes. Cheers, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: 16 November 2020 08:17 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Semantic versioning Hi, I miss something here. What is being discussed, what is the purpose of changing version numbering? * Is more granularity needed and each or some lesser quality levels should be assigned a version number too? Currently a new version number is assigned if a new SW set reaches “Release” quality level. (Whatever that might be.) * Is there need for expressing backwards compatibility better? * Is the aim to enhance existing version numbers just by making them following a well-defined standard? I have the feeling different people are talking about different sub-topics. I think the most important purpose or having release numbers is to express quality. It could help on version numbers if quality would be defined cleaner. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Peng via TF-M Sent: 16 November 2020 09:06 To: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>>; David Wang <David.Wang(a)arm.com<mailto:David.Wang@arm.com>>; Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>>; 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] Semantic versioning I would vote for Option 3, and “.2” - Backport the fixing patches to the existing v1.x.0 tag. – This provides the flexibility to have a released version with critical fixes only. If TF-M users want all the changes between the release and the fix they can take the master branch as well. Best Regards, Kevin 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: Monday, November 16, 2020 3:45 PM To: David Wang <David.Wang(a)arm.com<mailto:David.Wang@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Semantic versioning Hi Anton, Option 3 seems more reasonable to me. Hi David, I think we can leave tag v1.x.0 as it is and create a new tag v1.x.1 for this critical fix on master branch. It can be more easier to distinguish between tags. 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 Wang via TF-M Sent: Monday, November 16, 2020 2:53 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] Semantic versioning Hi Anton, Option 3 is a good. Just to clarify, for example, if v1.x.0 released, and we got a critical fix 2 months later. Then in your proposal, we: * Tag the current master which includes the fixing patch (and may also include some other merged/ongoing features after last release) as v1.x.1, or * Backport the fixing patches to the existing v1.x.0 tag (keep it in a new branch) and tag the tip of the v1.x release branch as v1.x.1 Thanks. Regards, David Wang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Townsend via TF-M Sent: Saturday, November 14, 2020 3:45 AM To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Semantic versioning Hi Anton, Option 3 seems the most sensible to me for a project like TF-M at this stage. Best regards, Kevin On Fri, 13 Nov 2020 at 20:19, Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: Hi, I would like to continue the discussion on TF-M semantic versioning started on the last tech forum. Currently TF-M uses a loosely defined versioning schema with major and minor versions, following TF-A. There are several calls to switch TF-M to semantic versioning. Here is the reminder of the meaning: (https://semver.org/) v1.2.3 : 1. MAJOR version when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards compatible manner, and 3. PATCH version when you make backwards compatible bug fixes. This is a good way to go for a mature project but TF-M will overkill from everyday re-versioning because of new patches. It was discussed on the forum and several options were proposed: 1. Do nothing, reasonably bumping up versions on release time only. 2. Use semantic versioning ignoring changes in PATCH by keeping it 0. So upcoming version could be: v1.2.0, next v1.3.0 and nothing in between. 3. Use option 2 but change PATCH when critical code change delivered within release cadence like a security vulnerability fix to let down-stream project relay on a fixed version. 4. Other ideas? Personally I tend to follow option 3 but looking for the community input. Thanks, Anton. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 11 months

1
0
0 0

Re: [TF-M] Combine secure and non-secure image

by Kevin Townsend

Hi Antonio, I'm not sure if this helps, but here is an example of how we sign the binaries for the MPS2 AN521, for example, after building the TF-M and Zephyr NS images, plus MCUBoot: https://github.com/zephyrproject-rtos/zephyr/blob/966015f503d1438c25d597937… Best regards, Kevin On Fri, 13 Nov 2020 at 16:19, Antonio Ken IANNILLO via TF-M < tf-m(a)lists.trustedfirmware.org> wrote: > Hi all, > > I abandoned the idea to build at once tf-m and zephyr and switched to > separated compilations. > > Now, I have both secure and non-secure binaries but I’m not sure how to > concatenate and sign them. > > I found the assemble.py script but I don’t know whether it is the correct > one or where to find the signing_layout. > > > > To be more specific, for my current target musca-a (going to switch to > musca-s as soon as it arrives): > > - I built TF-M > - I imported and included in my zephyr application both libpsa_api_ns.a > and libtfm_s_veneers.a > - I build my zephyr application > > Now (I suppose) I have to > > - merge zephyr.bin with tfm_s.bin > - sign the merged binary > - concatenate with bl2 > > I could not find any reference how to correctly do these last steps. > > > > Best, > > -- > > *Antonio Ken Iannillo* > > Research Scientist – SEDAN group > > SnT – Interdisciplinary Centre for Security, Reliability and Trust > > UNIVERSITÉ DU LUXEMBOURG > > > > CAMPUS KIRCHBERG > 29, avenue John F. Kennedy > L-1855 Luxembourg Kirchberg > T +352 46 66 44 9660 > > > > Join the conversation > > News <https://wwwen.uni.lu/snt/news_events> | Twitter > <https://twitter.com/SnT_uni_lu> | Linkedin > <https://www.linkedin.com/school/snt-lu/> > > www.uni.lu/snt > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m >

4 years, 11 months

3
2
0 0

Re: [TF-M] Semantic versioning

by Gyorgy Szing

Hi, I miss something here. What is being discussed, what is the purpose of changing version numbering? * Is more granularity needed and each or some lesser quality levels should be assigned a version number too? Currently a new version number is assigned if a new SW set reaches “Release” quality level. (Whatever that might be.) * Is there need for expressing backwards compatibility better? * Is the aim to enhance existing version numbers just by making them following a well-defined standard? I have the feeling different people are talking about different sub-topics. I think the most important purpose or having release numbers is to express quality. It could help on version numbers if quality would be defined cleaner. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Peng via TF-M Sent: 16 November 2020 09:06 To: David Hu <David.Hu(a)arm.com>; David Wang <David.Wang(a)arm.com>; Anton Komlev <Anton.Komlev(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Semantic versioning I would vote for Option 3, and “.2” - Backport the fixing patches to the existing v1.x.0 tag. – This provides the flexibility to have a released version with critical fixes only. If TF-M users want all the changes between the release and the fix they can take the master branch as well. Best Regards, Kevin 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: Monday, November 16, 2020 3:45 PM To: David Wang <David.Wang(a)arm.com<mailto:David.Wang@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Semantic versioning Hi Anton, Option 3 seems more reasonable to me. Hi David, I think we can leave tag v1.x.0 as it is and create a new tag v1.x.1 for this critical fix on master branch. It can be more easier to distinguish between tags. 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 Wang via TF-M Sent: Monday, November 16, 2020 2:53 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] Semantic versioning Hi Anton, Option 3 is a good. Just to clarify, for example, if v1.x.0 released, and we got a critical fix 2 months later. Then in your proposal, we: * Tag the current master which includes the fixing patch (and may also include some other merged/ongoing features after last release) as v1.x.1, or * Backport the fixing patches to the existing v1.x.0 tag (keep it in a new branch) and tag the tip of the v1.x release branch as v1.x.1 Thanks. Regards, David Wang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Townsend via TF-M Sent: Saturday, November 14, 2020 3:45 AM To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Semantic versioning Hi Anton, Option 3 seems the most sensible to me for a project like TF-M at this stage. Best regards, Kevin On Fri, 13 Nov 2020 at 20:19, Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: Hi, I would like to continue the discussion on TF-M semantic versioning started on the last tech forum. Currently TF-M uses a loosely defined versioning schema with major and minor versions, following TF-A. There are several calls to switch TF-M to semantic versioning. Here is the reminder of the meaning: (https://semver.org/) v1.2.3 : 1. MAJOR version when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards compatible manner, and 3. PATCH version when you make backwards compatible bug fixes. This is a good way to go for a mature project but TF-M will overkill from everyday re-versioning because of new patches. It was discussed on the forum and several options were proposed: 1. Do nothing, reasonably bumping up versions on release time only. 2. Use semantic versioning ignoring changes in PATCH by keeping it 0. So upcoming version could be: v1.2.0, next v1.3.0 and nothing in between. 3. Use option 2 but change PATCH when critical code change delivered within release cadence like a security vulnerability fix to let down-stream project relay on a fixed version. 4. Other ideas? Personally I tend to follow option 3 but looking for the community input. Thanks, Anton. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 11 months

1
0
0 0

Re: [TF-M] Semantic versioning

by Kevin Peng

I would vote for Option 3, and “.2” - Backport the fixing patches to the existing v1.x.0 tag. – This provides the flexibility to have a released version with critical fixes only. If TF-M users want all the changes between the release and the fix they can take the master branch as well. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Monday, November 16, 2020 3:45 PM To: David Wang <David.Wang(a)arm.com>; tf-m(a)lists.trustedfirmware.org; Anton Komlev <Anton.Komlev(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Semantic versioning Hi Anton, Option 3 seems more reasonable to me. Hi David, I think we can leave tag v1.x.0 as it is and create a new tag v1.x.1 for this critical fix on master branch. It can be more easier to distinguish between tags. 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 Wang via TF-M Sent: Monday, November 16, 2020 2:53 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] Semantic versioning Hi Anton, Option 3 is a good. Just to clarify, for example, if v1.x.0 released, and we got a critical fix 2 months later. Then in your proposal, we: * Tag the current master which includes the fixing patch (and may also include some other merged/ongoing features after last release) as v1.x.1, or * Backport the fixing patches to the existing v1.x.0 tag (keep it in a new branch) and tag the tip of the v1.x release branch as v1.x.1 Thanks. Regards, David Wang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Townsend via TF-M Sent: Saturday, November 14, 2020 3:45 AM To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Semantic versioning Hi Anton, Option 3 seems the most sensible to me for a project like TF-M at this stage. Best regards, Kevin On Fri, 13 Nov 2020 at 20:19, Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: Hi, I would like to continue the discussion on TF-M semantic versioning started on the last tech forum. Currently TF-M uses a loosely defined versioning schema with major and minor versions, following TF-A. There are several calls to switch TF-M to semantic versioning. Here is the reminder of the meaning: (https://semver.org/) v1.2.3 : 1. MAJOR version when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards compatible manner, and 3. PATCH version when you make backwards compatible bug fixes. This is a good way to go for a mature project but TF-M will overkill from everyday re-versioning because of new patches. It was discussed on the forum and several options were proposed: 1. Do nothing, reasonably bumping up versions on release time only. 2. Use semantic versioning ignoring changes in PATCH by keeping it 0. So upcoming version could be: v1.2.0, next v1.3.0 and nothing in between. 3. Use option 2 but change PATCH when critical code change delivered within release cadence like a security vulnerability fix to let down-stream project relay on a fixed version. 4. Other ideas? Personally I tend to follow option 3 but looking for the community input. Thanks, Anton. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 11 months

1
0
0 0

Re: [TF-M] Semantic versioning

by David Hu

Hi Anton, Option 3 seems more reasonable to me. Hi David, I think we can leave tag v1.x.0 as it is and create a new tag v1.x.1 for this critical fix on master branch. It can be more easier to distinguish between tags. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang via TF-M Sent: Monday, November 16, 2020 2:53 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Semantic versioning Hi Anton, Option 3 is a good. Just to clarify, for example, if v1.x.0 released, and we got a critical fix 2 months later. Then in your proposal, we: * Tag the current master which includes the fixing patch (and may also include some other merged/ongoing features after last release) as v1.x.1, or * Backport the fixing patches to the existing v1.x.0 tag (keep it in a new branch) and tag the tip of the v1.x release branch as v1.x.1 Thanks. Regards, David Wang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Townsend via TF-M Sent: Saturday, November 14, 2020 3:45 AM To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Semantic versioning Hi Anton, Option 3 seems the most sensible to me for a project like TF-M at this stage. Best regards, Kevin On Fri, 13 Nov 2020 at 20:19, Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: Hi, I would like to continue the discussion on TF-M semantic versioning started on the last tech forum. Currently TF-M uses a loosely defined versioning schema with major and minor versions, following TF-A. There are several calls to switch TF-M to semantic versioning. Here is the reminder of the meaning: (https://semver.org/) v1.2.3 : 1. MAJOR version when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards compatible manner, and 3. PATCH version when you make backwards compatible bug fixes. This is a good way to go for a mature project but TF-M will overkill from everyday re-versioning because of new patches. It was discussed on the forum and several options were proposed: 1. Do nothing, reasonably bumping up versions on release time only. 2. Use semantic versioning ignoring changes in PATCH by keeping it 0. So upcoming version could be: v1.2.0, next v1.3.0 and nothing in between. 3. Use option 2 but change PATCH when critical code change delivered within release cadence like a security vulnerability fix to let down-stream project relay on a fixed version. 4. Other ideas? Personally I tend to follow option 3 but looking for the community input. Thanks, Anton. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 11 months

1
0
0 0

Re: [TF-M] Semantic versioning

by David Wang

Hi Anton, Option 3 is a good. Just to clarify, for example, if v1.x.0 released, and we got a critical fix 2 months later. Then in your proposal, we: * Tag the current master which includes the fixing patch (and may also include some other merged/ongoing features after last release) as v1.x.1, or * Backport the fixing patches to the existing v1.x.0 tag (keep it in a new branch) and tag the tip of the v1.x release branch as v1.x.1 Thanks. Regards, David Wang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: Saturday, November 14, 2020 3:45 AM To: Anton Komlev <Anton.Komlev(a)arm.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Semantic versioning Hi Anton, Option 3 seems the most sensible to me for a project like TF-M at this stage. Best regards, Kevin On Fri, 13 Nov 2020 at 20:19, Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: Hi, I would like to continue the discussion on TF-M semantic versioning started on the last tech forum. Currently TF-M uses a loosely defined versioning schema with major and minor versions, following TF-A. There are several calls to switch TF-M to semantic versioning. Here is the reminder of the meaning: (https://semver.org/) v1.2.3 : 1. MAJOR version when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards compatible manner, and 3. PATCH version when you make backwards compatible bug fixes. This is a good way to go for a mature project but TF-M will overkill from everyday re-versioning because of new patches. It was discussed on the forum and several options were proposed: 1. Do nothing, reasonably bumping up versions on release time only. 2. Use semantic versioning ignoring changes in PATCH by keeping it 0. So upcoming version could be: v1.2.0, next v1.3.0 and nothing in between. 3. Use option 2 but change PATCH when critical code change delivered within release cadence like a security vulnerability fix to let down-stream project relay on a fixed version. 4. Other ideas? Personally I tend to follow option 3 but looking for the community input. Thanks, Anton. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 11 months

1
0
0 0

Re: [TF-M] Semantic versioning

by Ken Liu

Option 3 +1. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: Saturday, November 14, 2020 3:45 AM To: Anton Komlev <Anton.Komlev(a)arm.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Semantic versioning Hi Anton, Option 3 seems the most sensible to me for a project like TF-M at this stage. Best regards, Kevin On Fri, 13 Nov 2020 at 20:19, Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: Hi, I would like to continue the discussion on TF-M semantic versioning started on the last tech forum. Currently TF-M uses a loosely defined versioning schema with major and minor versions, following TF-A. There are several calls to switch TF-M to semantic versioning. Here is the reminder of the meaning: (https://semver.org/) v1.2.3 : 1. MAJOR version when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards compatible manner, and 3. PATCH version when you make backwards compatible bug fixes. This is a good way to go for a mature project but TF-M will overkill from everyday re-versioning because of new patches. It was discussed on the forum and several options were proposed: 1. Do nothing, reasonably bumping up versions on release time only. 2. Use semantic versioning ignoring changes in PATCH by keeping it 0. So upcoming version could be: v1.2.0, next v1.3.0 and nothing in between. 3. Use option 2 but change PATCH when critical code change delivered within release cadence like a security vulnerability fix to let down-stream project relay on a fixed version. 4. Other ideas? Personally I tend to follow option 3 but looking for the community input. Thanks, Anton. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 11 months

1
0
0 0

Re: [TF-M] Semantic versioning

by Kevin Townsend

Hi Anton, Option 3 seems the most sensible to me for a project like TF-M at this stage. Best regards, Kevin On Fri, 13 Nov 2020 at 20:19, Anton Komlev via TF-M < tf-m(a)lists.trustedfirmware.org> wrote: > Hi, > > > > I would like to continue the discussion on TF-M semantic versioning > started on the last tech forum. > > Currently TF-M uses a loosely defined versioning schema with major and > minor versions, following TF-A. > > There are several calls to switch TF-M to semantic versioning. > > Here is the reminder of the meaning: (https://semver.org/) v1.2.3 : > > 1. MAJOR version when you make incompatible API changes, > 2. MINOR version when you add functionality in a backwards compatible > manner, and > 3. PATCH version when you make backwards compatible bug fixes. > > > > This is a good way to go for a mature project but TF-M will overkill from > everyday re-versioning because of new patches. It was discussed on the > forum and several options were proposed: > > 1. Do nothing, reasonably bumping up versions on release time only. > 2. Use semantic versioning ignoring changes in PATCH by keeping it 0. > So upcoming version could be: v1.2.0, next v1.3.0 and nothing in between. > 3. Use option 2 but change PATCH when critical code change delivered > within release cadence like a security vulnerability fix to let down-stream > project relay on a fixed version. > 4. Other ideas? > > > > Personally I tend to follow option 3 but looking for the community input. > > > > Thanks, > > Anton. > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m >

4 years, 11 months

1
0
0 0

Semantic versioning

by Anton Komlev

Hi, I would like to continue the discussion on TF-M semantic versioning started on the last tech forum. Currently TF-M uses a loosely defined versioning schema with major and minor versions, following TF-A. There are several calls to switch TF-M to semantic versioning. Here is the reminder of the meaning: (https://semver.org/) v1.2.3 : 1. MAJOR version when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards compatible manner, and 3. PATCH version when you make backwards compatible bug fixes. This is a good way to go for a mature project but TF-M will overkill from everyday re-versioning because of new patches. It was discussed on the forum and several options were proposed: 1. Do nothing, reasonably bumping up versions on release time only. 2. Use semantic versioning ignoring changes in PATCH by keeping it 0. So upcoming version could be: v1.2.0, next v1.3.0 and nothing in between. 3. Use option 2 but change PATCH when critical code change delivered within release cadence like a security vulnerability fix to let down-stream project relay on a fixed version. 4. Other ideas? Personally I tend to follow option 3 but looking for the community input. Thanks, Anton.

4 years, 11 months

1
0
0 0

Re: [TF-M] Combine secure and non-secure image

by Anton Komlev

Hi Antonio, This might be helpful in addition to Tamas: https://ci.trustedfirmware.org/view/TF-M/job/tf-m-build-docs-nightly/lastSt… The best, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M Sent: 13 November 2020 15:36 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Combine secure and non-secure image Hi Antonio, Required steps on Musca-A (only single image boot is supported by MCUboot due to RAM_LOAD upgrade mode limitation): - Concatenate zephyr.bin + tfm_s.bin. [ 93%] Generating tfm_s_ns.bin cd /home/tamban01/repo/tf-m/build/bl2/ext/mcuboot && ../../../../py_env/bin/python3 /home/tamban01/repo/tf-m/bl2/ext/mcuboot/scripts/assemble.py --layout /home/tamban01/repo/tf-m/build/bl2/ext/mcuboot/CMakeFiles/signing_layout_s.dir/signing_layout_s_ns.o -s /home/tamban01/repo/tf-m/build/bin/tfm_s.bin -n /home/tamban01/repo/tf-m/build/bin/tfm_ns.bin -o tfm_s_ns.bin * Signing the concatenated binary: [ 94%] Generating tfm_s_ns_signed.bin cd /home/tamban01/repo/tf-m/build/bl2/ext/mcuboot && ../../../../py_env/bin/python3 /home/tamban01/repo/tf-m/bl2/ext/mcuboot/scripts/wrapper/wrapper.py -v 1.1.0 --layout /home/tamban01/repo/tf-m/build/bl2/ext/mcuboot/CMakeFiles/signing_layout_s.dir/signing_layout_s_ns.o -k /home/tamban01/repo/tf-m/bl2/ext/mcuboot/root-RSA-3072.pem --public-key-format full --align 1 --pad --pad-header -H 0x400 -s auto -d "(0, 0.0.0+0)" -d "(1, 0.0.0+0)" tfm_s_ns.bin /home/tamban01/repo/tf-m/build/bl2/ext/mcuboot/tfm_s_ns_signed.bin * Combine bl2.bin and tfm_s_ns.bin: srec_cat build/bin/bl2.bin -Binary -offset 0x200000 build/bin/tfm_s_ns_signed.bin -Binary -offset 0x220000 -o tfm.hex -Intel Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Townsend via TF-M Sent: 2020. november 13., péntek 16:33 To: Antonio Ken IANNILLO <antonioken.iannillo(a)uni.lu<mailto:antonioken.iannillo@uni.lu>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Combine secure and non-secure image Hi Antonio, I'm not sure if this helps, but here is an example of how we sign the binaries for the MPS2 AN521, for example, after building the TF-M and Zephyr NS images, plus MCUBoot: https://github.com/zephyrproject-rtos/zephyr/blob/966015f503d1438c25d597937… Best regards, Kevin On Fri, 13 Nov 2020 at 16:19, Antonio Ken IANNILLO via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: Hi all, I abandoned the idea to build at once tf-m and zephyr and switched to separated compilations. Now, I have both secure and non-secure binaries but I’m not sure how to concatenate and sign them. I found the assemble.py script but I don’t know whether it is the correct one or where to find the signing_layout. To be more specific, for my current target musca-a (going to switch to musca-s as soon as it arrives): * I built TF-M * I imported and included in my zephyr application both libpsa_api_ns.a and libtfm_s_veneers.a * I build my zephyr application Now (I suppose) I have to · merge zephyr.bin with tfm_s.bin · sign the merged binary · concatenate with bl2 I could not find any reference how to correctly do these last steps. Best, -- Antonio Ken Iannillo Research Scientist – SEDAN group SnT – Interdisciplinary Centre for Security, Reliability and Trust UNIVERSITÉ DU LUXEMBOURG CAMPUS KIRCHBERG 29, avenue John F. Kennedy L-1855 Luxembourg Kirchberg T +352 46 66 44 9660 Join the conversation News<https://wwwen.uni.lu/snt/news_events> | Twitter<https://twitter.com/SnT_uni_lu> | Linkedin<https://www.linkedin.com/school/snt-lu/> www.uni.lu/snt<http://www.uni.lu/snt> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 11 months

1
0
0 0

Re: [TF-M] Combine secure and non-secure image

by Tamas Ban

Hi Antonio, Required steps on Musca-A (only single image boot is supported by MCUboot due to RAM_LOAD upgrade mode limitation): - Concatenate zephyr.bin + tfm_s.bin. [ 93%] Generating tfm_s_ns.bin cd /home/tamban01/repo/tf-m/build/bl2/ext/mcuboot && ../../../../py_env/bin/python3 /home/tamban01/repo/tf-m/bl2/ext/mcuboot/scripts/assemble.py --layout /home/tamban01/repo/tf-m/build/bl2/ext/mcuboot/CMakeFiles/signing_layout_s.dir/signing_layout_s_ns.o -s /home/tamban01/repo/tf-m/build/bin/tfm_s.bin -n /home/tamban01/repo/tf-m/build/bin/tfm_ns.bin -o tfm_s_ns.bin * Signing the concatenated binary: [ 94%] Generating tfm_s_ns_signed.bin cd /home/tamban01/repo/tf-m/build/bl2/ext/mcuboot && ../../../../py_env/bin/python3 /home/tamban01/repo/tf-m/bl2/ext/mcuboot/scripts/wrapper/wrapper.py -v 1.1.0 --layout /home/tamban01/repo/tf-m/build/bl2/ext/mcuboot/CMakeFiles/signing_layout_s.dir/signing_layout_s_ns.o -k /home/tamban01/repo/tf-m/bl2/ext/mcuboot/root-RSA-3072.pem --public-key-format full --align 1 --pad --pad-header -H 0x400 -s auto -d "(0, 0.0.0+0)" -d "(1, 0.0.0+0)" tfm_s_ns.bin /home/tamban01/repo/tf-m/build/bl2/ext/mcuboot/tfm_s_ns_signed.bin * Combine bl2.bin and tfm_s_ns.bin: srec_cat build/bin/bl2.bin -Binary -offset 0x200000 build/bin/tfm_s_ns_signed.bin -Binary -offset 0x220000 -o tfm.hex -Intel Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: 2020. november 13., péntek 16:33 To: Antonio Ken IANNILLO <antonioken.iannillo(a)uni.lu> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Combine secure and non-secure image Hi Antonio, I'm not sure if this helps, but here is an example of how we sign the binaries for the MPS2 AN521, for example, after building the TF-M and Zephyr NS images, plus MCUBoot: https://github.com/zephyrproject-rtos/zephyr/blob/966015f503d1438c25d597937… Best regards, Kevin On Fri, 13 Nov 2020 at 16:19, Antonio Ken IANNILLO via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: Hi all, I abandoned the idea to build at once tf-m and zephyr and switched to separated compilations. Now, I have both secure and non-secure binaries but I’m not sure how to concatenate and sign them. I found the assemble.py script but I don’t know whether it is the correct one or where to find the signing_layout. To be more specific, for my current target musca-a (going to switch to musca-s as soon as it arrives): * I built TF-M * I imported and included in my zephyr application both libpsa_api_ns.a and libtfm_s_veneers.a * I build my zephyr application Now (I suppose) I have to · merge zephyr.bin with tfm_s.bin · sign the merged binary · concatenate with bl2 I could not find any reference how to correctly do these last steps. Best, -- Antonio Ken Iannillo Research Scientist – SEDAN group SnT – Interdisciplinary Centre for Security, Reliability and Trust UNIVERSITÉ DU LUXEMBOURG CAMPUS KIRCHBERG 29, avenue John F. Kennedy L-1855 Luxembourg Kirchberg T +352 46 66 44 9660 Join the conversation News<https://wwwen.uni.lu/snt/news_events> | Twitter<https://twitter.com/SnT_uni_lu> | Linkedin<https://www.linkedin.com/school/snt-lu/> www.uni.lu/snt<http://www.uni.lu/snt> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 11 months

1
0
0 0

Combine secure and non-secure image

by Antonio Ken IANNILLO

Hi all, I abandoned the idea to build at once tf-m and zephyr and switched to separated compilations. Now, I have both secure and non-secure binaries but I’m not sure how to concatenate and sign them. I found the assemble.py script but I don’t know whether it is the correct one or where to find the signing_layout. To be more specific, for my current target musca-a (going to switch to musca-s as soon as it arrives): I built TF-M I imported and included in my zephyr application both libpsa_api_ns.a and libtfm_s_veneers.a I build my zephyr application Now (I suppose) I have to merge zephyr.bin with tfm_s.bin sign the merged binary concatenate with bl2 I could not find any reference how to correctly do these last steps. Best, -- Antonio Ken Iannillo Research Scientist – SEDAN group SnT – Interdisciplinary Centre for Security, Reliability and Trust UNIVERSITÉ DU LUXEMBOURG CAMPUS KIRCHBERG 29, avenue John F. Kennedy L-1855 Luxembourg Kirchberg T +352 46 66 44 9660 Join the conversation News | Twitter | Linkedin www.uni.lu/snt

4 years, 11 months

1
0
0 0

Re: [TF-M] Generated files location

by Raef Coles

Hi, As an intermediate step, we've made a modification to the file generation code so that file can be generated without cmake being run. This generation can be run by: ``` python3 tools/tfm_parse_manifest_list.py -m tools/tfm_manifest_list.yaml -f tools/tfm_generated_file_list.yaml -o <output dir> ``` Which will output the files into the specified output directory. if the `-o` flag is not provided then the files will be generated into the TFM source tree. Note that this method still requires knowledge of the location of some dependencies, as this cannot be provided by cmake. When run in standalone mode, these paths are gathered from environment variables, and generation will fail if those variables are not set. Thus: ``` env TFM_TEST_PATH=$(realpath ../tf-m-tests/test) python3 tools/tfm_parse_manifest_list.py -m tools/tfm_manifest_list.yaml -f tools/tfm_generated_file_list.yaml ``` Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 20 October 2020 08:39 To: Anton Komlev Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Generated files location Hi Anton If it’s not possible to avoid a file generation now, it’s good to have pre-generated files for a most typical configuration (l2, IPC etc.). As I mentioned before, ideally to use TFM as a real component/framework without generation of any source code. BUT If you believe, this requirement breaks a TFM concept, just tell us. Thanks, Andrej From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Tuesday, October 20, 2020 9:27 AM To: tf-m(a)lists.trustedfirmware.org Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Generated files location Hi Andrej, Essentially, do you mean to move the files back to code tree and synch them with templates manually as it was ? Cheers, Anton From: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>> Sent: 19 October 2020 16:15 To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: RE: Generated files location Hi Anton, Another option: 3. Avoid the mandatory on-the-fly generation. Try to make TFM a component/framework, which is configurable by compile & run time parameters. 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: Monday, October 19, 2020 5:00 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] Generated files location Hi, Some source files in TF-M are templated and generated inside /<build_dir>/generated/ on the fly as a part of build process. This guaranty consistency between templates and generated but might make a trouble for IDE, where not all source files exist at the first run. I see 2 options for solution: 1. Explicitly generate those files via cmake as a part of IDE project creation (1 time action) 2. Relay on CMSIS Pack for IDE, where generated files must be presents Any alternative thoughts? Anton

4 years, 11 months

2
1
0 0

Re: [TF-M] Typo in return value (ps_object_system.c)

by Jamie Fox

Hi Robert, Thanks for the bug report. I have pushed a fix for review: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6986 Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Robert Rostohar via TF-M Sent: 12 November 2020 13:57 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Typo in return value (ps_object_system.c) Hi, I believe there is a small typo in the return value of function ps_read_object (ps_object_system.c). This results in build failure of Non-encrypted Protected Storage. https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/… The define used should be "PSA_ERROR_DATA_CORRUPT" and not "PSA_PS_ERROR_DATA_CORRUPT". Best regards, Robert

4 years, 11 months

1
0
0 0

Typo in return value (ps_object_system.c)

by Robert Rostohar

Hi, I believe there is a small typo in the return value of function ps_read_object (ps_object_system.c). This results in build failure of Non-encrypted Protected Storage. https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/… The define used should be "PSA_ERROR_DATA_CORRUPT" and not "PSA_PS_ERROR_DATA_CORRUPT". Best regards, Robert

4 years, 11 months

1
0
0 0

Re: [TF-M] Technical Forum call - November 12

by Mingyang Sun

Hi Anton, I have a topic, Partition Storage Arrangement, to introduce partition data storage briefly, for about 20 minutes. Thanks, Mingyang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, November 4, 2020 10:17 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Technical Forum call - November 12 Hello, The next Technical Forum is planned on Thursday, November 12 at 6:00-07: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, 11 months

2
1
0 0

Re: [TF-M] Code freeze heads up for TF-M v1.2

by Anton Komlev

Hi, New TF-M Release Candidate 2 is tagged by TF-Mv1.2-RC2. Please update all repositories as it contain fixes for issues found in RC1. Best regards, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 04 November 2020 16:35 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Code freeze heads up for TF-M v1.2 Hi, All TF-M repositories are tagged with TF-Mv1.2-RC1 tag, marking the code freeze and beginning of the release candidate testing. 1. tf-m-tools 2. tf-m-tests 3. trusted-firmware-m 4. tf-m-ci-scripts 5. tf-m-job-configs Please use this tag for tests and report all issues found here. The best, 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: 02 November 2020 14:28 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] Code freeze heads up for TF-M v1.2 Hi All, This is a reminder and heads up that TF-Mv1.2 release is planned for the end of November and TF-M code repository is aimed for freeze on Nov 4th (Wed), tagged by TF-Mv1.2-RC1 for testing. Availability of the tag will be notified via this mailing list. Thanks, Anton

4 years, 11 months

1
0
0 0

GNU Arm compiler v6.3.1 deprecation heads up

by Minos Galanakis

Hi, With the upcoming release of TF-M 1.2, we are considering deprecating the GNU Arm compiler v6.3.1 to be able to reallocate testing bandwidth to newer and more up to date versions ( 7+ ) Before doing so I would like to ask for the community's feedback. Is anyone using this compiler, and if so, would you be affected by the change? Are there any other reasons we should consider keeping it in to the test plan? Regards, Minos

4 years, 12 months

1
0
0 0

Re: [TF-M] Code freeze heads up for TF-M v1.2

by Anton Komlev

Hi, All TF-M repositories are tagged with TF-Mv1.2-RC1 tag, marking the code freeze and beginning of the release candidate testing. 1. tf-m-tools 2. tf-m-tests 3. trusted-firmware-m 4. tf-m-ci-scripts 5. tf-m-job-configs Please use this tag for tests and report all issues found here. The best, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 02 November 2020 14:28 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Code freeze heads up for TF-M v1.2 Hi All, This is a reminder and heads up that TF-Mv1.2 release is planned for the end of November and TF-M code repository is aimed for freeze on Nov 4th (Wed), tagged by TF-Mv1.2-RC1 for testing. Availability of the tag will be notified via this mailing list. Thanks, Anton

4 years, 12 months

1
0
0 0

Technical Forum call - November 12

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, November 12 at 6:00-07: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, 12 months

1
0
0 0

Re: [TF-M] Integrating a different RTOS in tf-m-test

by Kevin Peng

Just adding some hints from the TF-M point of view. The TF-M test cases are RTOS independent. And test entry functions are provided for integrating the tests to any RTOS - test_app() You just need to call them in your application thread. Of course, you need to implement the os_wrapper APIs as well. You can refer to the os_wrapper_cmsis_rtos_v2.c for details. The old build system of TF-M used to provide libraries of the tests. The new build system is not having those yet. So the source codes need to be built. The test case libraries should be added back to the new build system and then integrating tf-m tests to RTOS should be much more direct. Best Regards, Kevin -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raef Coles via TF-M Sent: Tuesday, November 3, 2020 11:19 PM To: Antonio Ken IANNILLO <antonioken.iannillo(a)uni.lu>; Kevin Townsend (kevin.townsend(a)linaro.org) <kevin.townsend(a)linaro.org> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Integrating a different RTOS in tf-m-test Good spot Antonio, those docs are out of date. I'll try to get them updated before the code freeze. Raef ________________________________________ From: Antonio Ken IANNILLO Sent: Tuesday, November 03, 2020 14:35 To: Raef Coles; Kevin Townsend (kevin.townsend(a)linaro.org) Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Integrating a different RTOS in tf-m-test Hi Raef, I agree with you, also reading the documentation https://ci.trustedfirmware.org/view/TF-M/job/tf-m-build-docs-nightly/lastSt… (even if it seems obsolete since some files are missing). For example, are now the static library for the test included in the one you mentioned? I'm using the module offered by zephyr to build and import the tfm, but I get a lot of missing references. Further, I searched in the install directory built by tfm and I cannot really find all of them. -- Antonio Ken Iannillo On 03/11/2020, 15:08, "Raef Coles" <Raef.Coles(a)arm.com> wrote: One of the things tfm produces is the NS api static library, which should be found in `interface/libpsa_api_ns.a`. There is also a ns platforms static lib in the same directory. I'm not sure how easy it is to pick these up from the zephyr buildsystem, but those should contain the symbols you want. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Antonio Ken IANNILLO via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 03 November 2020 11:45 To: Kevin Townsend (kevin.townsend(a)linaro.org) Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Integrating a different RTOS in tf-m-test Hi Kevin, Thank you for your message. I’m trying to create a zephyr application copying the tfm-test non secure application (https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/master/tf-m-t…). The only thing that is not clear is how to include the tfm platform code (e.g., https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/master/truste…). I suppose as a static library from the zephyr tfm module but I cannot really find how. Can you point me to the right direction? Or do you have a different way to run the tfm-tests? Best, -- Antonio Ken Iannillo From: Kevin Townsend <kevin.townsend(a)linaro.org> Date: Monday, 2 November 2020 at 13:08 To: Antonio Ken IANNILLO <antonioken.iannillo(a)uni.lu> Cc: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] Integrating a different RTOS in tf-m-test Hi Antonio, There is currently an issue filed in Zephyr to add a new sample application that will make it easy to run the PSA API tests via Zephyr, but it we're currently working on finalizing higher priority changes before the 1.2 code freeze later this week: https://github.com/zephyrproject-rtos/zephyr/issues/29476 So, there isn't an 'easy' way to build these tests in Zephyr today out of the box using Zephyr as the RTOS on the NS side, unless you want to have a go at it yourself in the short term while we try to make sure Zephyr is ready for the changes in T-M 1.2. Best regards, Kevin On Mon, 2 Nov 2020 at 10:29, Antonio Ken IANNILLO via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: Hi all, I wanted to use some other RTOS in the NS side while testing tf-m. Is there a simple way to use the Zephyr kernel or FreeRTOS in the tf-m-test (-DTEST_S=ON, -DTEST_NS=ON) instead of the default RTX? Best, -- Antonio Ken Iannillo Research Scientist – SEDAN group SnT – Interdisciplinary Centre for Security, Reliability and Trust UNIVERSITÉ DU LUXEMBOURG CAMPUS KIRCHBERG 29, avenue John F. Kennedy L-1855 Luxembourg Kirchberg T +352 46 66 44 9660 Join the conversation News<https://wwwen.uni.lu/snt/news_events> | Twitter<https://twitter.com/SnT_uni_lu> | Linkedin<https://www.linkedin.com/school/snt-lu/> www.uni.lu/snt<http://www.uni.lu/snt> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 12 months

1
0
0 0

Re: [TF-M] Integrating a different RTOS in tf-m-test

by Raef Coles

Good spot Antonio, those docs are out of date. I'll try to get them updated before the code freeze. Raef ________________________________________ From: Antonio Ken IANNILLO Sent: Tuesday, November 03, 2020 14:35 To: Raef Coles; Kevin Townsend (kevin.townsend(a)linaro.org) Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Integrating a different RTOS in tf-m-test Hi Raef, I agree with you, also reading the documentation https://ci.trustedfirmware.org/view/TF-M/job/tf-m-build-docs-nightly/lastSt… (even if it seems obsolete since some files are missing). For example, are now the static library for the test included in the one you mentioned? I'm using the module offered by zephyr to build and import the tfm, but I get a lot of missing references. Further, I searched in the install directory built by tfm and I cannot really find all of them. -- Antonio Ken Iannillo On 03/11/2020, 15:08, "Raef Coles" <Raef.Coles(a)arm.com> wrote: One of the things tfm produces is the NS api static library, which should be found in `interface/libpsa_api_ns.a`. There is also a ns platforms static lib in the same directory. I'm not sure how easy it is to pick these up from the zephyr buildsystem, but those should contain the symbols you want. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Antonio Ken IANNILLO via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 03 November 2020 11:45 To: Kevin Townsend (kevin.townsend(a)linaro.org) Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Integrating a different RTOS in tf-m-test Hi Kevin, Thank you for your message. I’m trying to create a zephyr application copying the tfm-test non secure application (https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/master/tf-m-t…). The only thing that is not clear is how to include the tfm platform code (e.g., https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/master/truste…). I suppose as a static library from the zephyr tfm module but I cannot really find how. Can you point me to the right direction? Or do you have a different way to run the tfm-tests? Best, -- Antonio Ken Iannillo From: Kevin Townsend <kevin.townsend(a)linaro.org> Date: Monday, 2 November 2020 at 13:08 To: Antonio Ken IANNILLO <antonioken.iannillo(a)uni.lu> Cc: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] Integrating a different RTOS in tf-m-test Hi Antonio, There is currently an issue filed in Zephyr to add a new sample application that will make it easy to run the PSA API tests via Zephyr, but it we're currently working on finalizing higher priority changes before the 1.2 code freeze later this week: https://github.com/zephyrproject-rtos/zephyr/issues/29476 So, there isn't an 'easy' way to build these tests in Zephyr today out of the box using Zephyr as the RTOS on the NS side, unless you want to have a go at it yourself in the short term while we try to make sure Zephyr is ready for the changes in T-M 1.2. Best regards, Kevin On Mon, 2 Nov 2020 at 10:29, Antonio Ken IANNILLO via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: Hi all, I wanted to use some other RTOS in the NS side while testing tf-m. Is there a simple way to use the Zephyr kernel or FreeRTOS in the tf-m-test (-DTEST_S=ON, -DTEST_NS=ON) instead of the default RTX? Best, -- Antonio Ken Iannillo Research Scientist – SEDAN group SnT – Interdisciplinary Centre for Security, Reliability and Trust UNIVERSITÉ DU LUXEMBOURG CAMPUS KIRCHBERG 29, avenue John F. Kennedy L-1855 Luxembourg Kirchberg T +352 46 66 44 9660 Join the conversation News<https://wwwen.uni.lu/snt/news_events> | Twitter<https://twitter.com/SnT_uni_lu> | Linkedin<https://www.linkedin.com/school/snt-lu/> www.uni.lu/snt<http://www.uni.lu/snt> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 12 months

1
0
0 0

Re: [TF-M] Integrating a different RTOS in tf-m-test

by Raef Coles

One of the things tfm produces is the NS api static library, which should be found in `interface/libpsa_api_ns.a`. There is also a ns platforms static lib in the same directory. I'm not sure how easy it is to pick these up from the zephyr buildsystem, but those should contain the symbols you want. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Antonio Ken IANNILLO via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 03 November 2020 11:45 To: Kevin Townsend (kevin.townsend(a)linaro.org) Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Integrating a different RTOS in tf-m-test Hi Kevin, Thank you for your message. I’m trying to create a zephyr application copying the tfm-test non secure application (https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/master/tf-m-t…). The only thing that is not clear is how to include the tfm platform code (e.g., https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/master/truste…). I suppose as a static library from the zephyr tfm module but I cannot really find how. Can you point me to the right direction? Or do you have a different way to run the tfm-tests? Best, -- Antonio Ken Iannillo From: Kevin Townsend <kevin.townsend(a)linaro.org> Date: Monday, 2 November 2020 at 13:08 To: Antonio Ken IANNILLO <antonioken.iannillo(a)uni.lu> Cc: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] Integrating a different RTOS in tf-m-test Hi Antonio, There is currently an issue filed in Zephyr to add a new sample application that will make it easy to run the PSA API tests via Zephyr, but it we're currently working on finalizing higher priority changes before the 1.2 code freeze later this week: https://github.com/zephyrproject-rtos/zephyr/issues/29476 So, there isn't an 'easy' way to build these tests in Zephyr today out of the box using Zephyr as the RTOS on the NS side, unless you want to have a go at it yourself in the short term while we try to make sure Zephyr is ready for the changes in T-M 1.2. Best regards, Kevin On Mon, 2 Nov 2020 at 10:29, Antonio Ken IANNILLO via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: Hi all, I wanted to use some other RTOS in the NS side while testing tf-m. Is there a simple way to use the Zephyr kernel or FreeRTOS in the tf-m-test (-DTEST_S=ON, -DTEST_NS=ON) instead of the default RTX? Best, -- Antonio Ken Iannillo Research Scientist – SEDAN group SnT – Interdisciplinary Centre for Security, Reliability and Trust UNIVERSITÉ DU LUXEMBOURG CAMPUS KIRCHBERG 29, avenue John F. Kennedy L-1855 Luxembourg Kirchberg T +352 46 66 44 9660 Join the conversation News<https://wwwen.uni.lu/snt/news_events> | Twitter<https://twitter.com/SnT_uni_lu> | Linkedin<https://www.linkedin.com/school/snt-lu/> www.uni.lu/snt<http://www.uni.lu/snt> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 12 months

3
3
0 0

Re: [TF-M] Current IAR support

by Raef Coles

Sorry Thomas - Someday I'll get that IAR license working and stop breaking support every 5 seconds. Thanks for all the hard work and fixes. Patches look good, have reviewed. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 03 November 2020 12:22 To: DeMars, Alan via TF-M Subject: [TF-M] Current IAR support Just when you think you have nailed everfything down, you decide to start with a fresh clone and stuff don't build anymore ;) See: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6766 I have now gone over and tried building everything that has IAR support and here are my findings. I have used the following patches: https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/5978 https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6766 I have built for the following targets: musca_a mps2/an519 mps2/an521 mps2/an539 mps2/sse-200_aws mps3/an524 cypress/psoc64 nxp/lpcxpresso55s69 (-DBL2=False as bl2 support appears to have been added recently to this target) stm/nucleo_l552ze_q stm/stm32l562e_dk The mps2/fvp_sse300 requires a compiler with support for the M55, and the IAR compiler with support for this is not yet released. I have run tests on the following targets: musca_a mps2/an519 mps2/an521 mps2/an539 The cypress/psoc64 board I have appears to be obsolete now and I could not flash the secure image to it. The nuvoton/m2351 appears to have IAR support, but it appears untested as it gives linking errors for the bl2 and NS startup files. There are some old and new warnings for type issues and some other minor things. The QCBOR NaN tests are still failing, see: https://developer.trustedfirmware.org/T700 This really is an issue where the ARM ABI and IEEE 754 are incompatible and we are following the ARM ABI. In reality neither ARMCLANG nor GNUARM are fully ARM ABI compliant as they are not ignoring the relevant bits. Thomas -- 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>

4 years, 12 months

1
0
0 0

Current IAR support

by Thomas Törnblom

Just when you think you have nailed everfything down, you decide to start with a fresh clone and stuff don't build anymore ;) See: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6766 I have now gone over and tried building everything that has IAR support and here are my findings. I have used the following patches: https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/5978 https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6766 I have built for the following targets: musca_a mps2/an519 mps2/an521 mps2/an539 mps2/sse-200_aws mps3/an524 cypress/psoc64 nxp/lpcxpresso55s69 (-DBL2=False as bl2 support appears to have been added recently to this target) stm/nucleo_l552ze_q stm/stm32l562e_dk The mps2/fvp_sse300 requires a compiler with support for the M55, and the IAR compiler with support for this is not yet released. I have run tests on the following targets: musca_a mps2/an519 mps2/an521 mps2/an539 The cypress/psoc64 board I have appears to be obsolete now and I could not flash the secure image to it. The nuvoton/m2351 appears to have IAR support, but it appears untested as it gives linking errors for the bl2 and NS startup files. There are some old and new warnings for type issues and some other minor things. The QCBOR NaN tests are still failing, see: https://developer.trustedfirmware.org/T700 This really is an issue where the ARM ABI and IEEE 754 are incompatible and we are following the ARM ABI. In reality neither ARMCLANG nor GNUARM are fully ARM ABI compliant as they are not ignoring the relevant bits. Thomas -- *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>

4 years, 12 months

1
0
0 0

Re: [TF-M] Integrating a different RTOS in tf-m-test

by Kevin Townsend

Hi Antonio, There is currently an issue filed in Zephyr to add a new sample application that will make it easy to run the PSA API tests via Zephyr, but it we're currently working on finalizing higher priority changes before the 1.2 code freeze later this week: https://github.com/zephyrproject-rtos/zephyr/issues/29476 So, there isn't an 'easy' way to build these tests in Zephyr today out of the box using Zephyr as the RTOS on the NS side, unless you want to have a go at it yourself in the short term while we try to make sure Zephyr is ready for the changes in T-M 1.2. Best regards, Kevin On Mon, 2 Nov 2020 at 10:29, Antonio Ken IANNILLO via TF-M < tf-m(a)lists.trustedfirmware.org> wrote: > Hi all, > > I wanted to use some other RTOS in the NS side while testing tf-m. > > Is there a simple way to use the Zephyr kernel or FreeRTOS in the > tf-m-test (-DTEST_S=ON, -DTEST_NS=ON) instead of the default RTX? > > > > Best, > > -- > > *Antonio Ken Iannillo* > > Research Scientist – SEDAN group > > SnT – Interdisciplinary Centre for Security, Reliability and Trust > > UNIVERSITÉ DU LUXEMBOURG > > > > CAMPUS KIRCHBERG > 29, avenue John F. Kennedy > L-1855 Luxembourg Kirchberg > T +352 46 66 44 9660 > > > > Join the conversation > > News <https://wwwen.uni.lu/snt/news_events> | Twitter > <https://twitter.com/SnT_uni_lu> | Linkedin > <https://www.linkedin.com/school/snt-lu/> > > www.uni.lu/snt > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m >

4 years, 12 months

2
1
0 0

Re: [TF-M] cmake error

by Malcolm Fernandes

I've verified that reverting the tf-m-tests patch fixes the build failures that Chris outlined. Cheers, Mal On Mon, Nov 2, 2020 at 6:16 PM David Hu via TF-M < tf-m(a)lists.trustedfirmware.org> wrote: > Hi Chris, > > > > Sorry for the build failure. A patch is merged into tf-m-tests but its > peer ones in TF-M haven’t been approved yet. > > I have temporarily reverted that tf-m-tests patch. Please have another try. > > > > Best regards, > > Hu Ziji > > > > *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org> * On Behalf Of *Christopher > Brand via TF-M > *Sent:* Tuesday, November 3, 2020 1:54 AM > *To:* tf-m(a)lists.trustedfirmware.org > *Subject:* [TF-M] cmake error > > > > I just fetched the latest master > (1655ef5120e99c62782575d0a8b3707ebfc2148e), and I’m now getting a cmake > error: > > $ cmake -S . -B build_GNUARM_Relwithdebinfo '-GUnix Makefiles' > -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake > -DCMAKE_BUILD_TYPE=Relwithdebinfo -DTEST_NS=ON -DTEST_S=ON -DTFM_IRQ_TEST=ON > > […] > > CMake Error at > build_GNUARM_Relwithdebinfo/lib/ext/tfm_test_repo-src/app/CMakeLists.txt:17 > (tfm_toolchain_reload_compiler): > > Unknown CMake command "tfm_toolchain_reload_compiler". > > > > Looks like tf-tests commit c41f3a078713b17b5654851329d63bcc0672874b > introduced calls to tfm_toolchain_reload_compiler(), which I don’t see > declared anywhere. > > > > I can work around it by using a local checkout of tf-m-tests at HEAD~. > > > > Chris Brand > > Sr Prin Software Engr, MCD: WIRELESS > > > > Cypress Semiconductor Corp. > > An Infineon Technologies Company > > #320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada > > www.infineon.com www.cypress.com > > > > > This message and any attachments may contain confidential information from > Cypress or its subsidiaries. If it has been received in error, please > advise the sender and immediately delete this message. > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m >

4 years, 12 months

1
0
0 0

Re: [TF-M] cmake error

by David Hu

Hi Chris, Sorry for the build failure. A patch is merged into tf-m-tests but its peer ones in TF-M haven't been approved yet. I have temporarily reverted that tf-m-tests patch. Please have another try. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: Tuesday, November 3, 2020 1:54 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] cmake error I just fetched the latest master (1655ef5120e99c62782575d0a8b3707ebfc2148e), and I'm now getting a cmake error: $ cmake -S . -B build_GNUARM_Relwithdebinfo '-GUnix Makefiles' -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Relwithdebinfo -DTEST_NS=ON -DTEST_S=ON -DTFM_IRQ_TEST=ON [...] CMake Error at build_GNUARM_Relwithdebinfo/lib/ext/tfm_test_repo-src/app/CMakeLists.txt:17 (tfm_toolchain_reload_compiler): Unknown CMake command "tfm_toolchain_reload_compiler". Looks like tf-tests commit c41f3a078713b17b5654851329d63bcc0672874b introduced calls to tfm_toolchain_reload_compiler(), which I don't see declared anywhere. I can work around it by using a local checkout of tf-m-tests at HEAD~. Chris Brand Sr Prin Software Engr, MCD: WIRELESS Cypress Semiconductor Corp. An Infineon Technologies Company #320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com> This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

4 years, 12 months

1
0
0 0

Mbed TLS Virtual Workshop Tomorrow

by Shebu Varghese Kuriakose

Hi All, Gentle reminder about the Mbed TLS workshop tomorrow (Tuesday, November 3rd) from 2 to 6pm GMT. See agenda and zoom link here - https://www.trustedfirmware.org/meetings/mbed-tls-workshop/ Thanks, Shebu -----Original Appointment----- From: Trusted Firmware Public Meetings <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com> Sent: Friday, October 23, 2020 12:32 AM To: Trusted Firmware Public Meetings; Shebu Varghese Kuriakose; mbed-tls(a)lists.trustedfirmware.org; Don Harbin; psa-crypto(a)lists.trustedfirmware.org; Dave Rodgman Subject: Mbed TLS Virtual Workshop When: Tuesday, November 3, 2020 2:00 PM-6:00 PM (UTC+00:00) Dublin, Edinburgh, Lisbon, London. Where: Zoom: https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT… You have been invited to the following event. Mbed TLS Virtual Workshop When Tue Nov 3, 2020 7am – 11am Mountain Standard Time - Phoenix Where Zoom: https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT… (map<https://www.google.com/maps/search/Zoom:+https:%2F%2Flinaro-org.zoom.us%2Fj…>) Calendar shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> Who • Don Harbin - creator • shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> • mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> • psa-crypto(a)lists.trustedfirmware.org<mailto:psa-crypto@lists.trustedfirmware.org> • dave.rodgman(a)arm.com<mailto:dave.rodgman@arm.com> more details »<https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…> Hi, Trustedfirmware.org community project would like to invite you to the Mbed TLS Virtual Workshop. The purpose of the workshop is to bring together the Mbed TLS community including maintainers, contributors and users to discuss * The future direction of the project and * Ways to improve community collaboration Here is the agenda for the workshop. Topic Time (in GMT) Welcome 2.00 - 2.10pm Constant-time code 2.10 – 2.30pm Processes - how does work get scheduled? 2.30 – 2.50pm PSA Crypto APIs 2.50 – 3.20pm PSA Crypto for Silicon Labs Wireless MCUs - Why, What, Where and When 3.20 – 3.50pm Break Roadmap, TLS1.3 Update 4.10 – 4.30pm Mbed TLS 3.0 Plans, Scope 4.30 – 5.00pm How do I contribute my first review and be an effective Mbed TLS reviewer 5.00 – 5.30pm Regards, Don Harbin Trusted Firmware Community Manager ==============Zoom details below:==================== Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: Mbed TLS Virtual Workshop Time: Nov 3, 2020 02:00 PM Greenwich Mean Time Join Zoom Meeting https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9531520…> Meeting ID: 953 1520 0315 Passcode: 143755 One tap mobile +16699009128,,95315200315# US (San Jose) +12532158782,,95315200315# US (Tacoma) Dial by your location +1 669 900 9128 US (San Jose) +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 646 558 8656 US (New York) +1 301 715 8592 US (Germantown) +1 312 626 6799 US (Chicago) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 953 1520 0315 Find your local number: https://linaro-org.zoom.us/u/apL3hgti4<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fu%2FapL3hgt…> Going (shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com>)? Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> 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 organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn More<https://support.google.com/calendar/answer/37135#forwarding>.

4 years, 12 months

1
0
0 0

cmake error

by Christopher Brand

I just fetched the latest master (1655ef5120e99c62782575d0a8b3707ebfc2148e), and I'm now getting a cmake error: $ cmake -S . -B build_GNUARM_Relwithdebinfo '-GUnix Makefiles' -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Relwithdebinfo -DTEST_NS=ON -DTEST_S=ON -DTFM_IRQ_TEST=ON [...] CMake Error at build_GNUARM_Relwithdebinfo/lib/ext/tfm_test_repo-src/app/CMakeLists.txt:17 (tfm_toolchain_reload_compiler): Unknown CMake command "tfm_toolchain_reload_compiler". Looks like tf-tests commit c41f3a078713b17b5654851329d63bcc0672874b introduced calls to tfm_toolchain_reload_compiler(), which I don't see declared anywhere. I can work around it by using a local checkout of tf-m-tests at HEAD~. Chris Brand Sr Prin Software Engr, MCD: WIRELESS Cypress Semiconductor Corp. An Infineon Technologies Company #320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com> This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

4 years, 12 months

1
0
0 0

Code freeze heads up for TF-M v1.2

by Anton Komlev

Hi All, This is a reminder and heads up that TF-Mv1.2 release is planned for the end of November and TF-M code repository is aimed for freeze on Nov 4th (Wed), tagged by TF-Mv1.2-RC1 for testing. Availability of the tag will be notified via this mailing list. Thanks, Anton

4 years, 12 months

1
0
0 0

Integrating a different RTOS in tf-m-test

by Antonio Ken IANNILLO

Hi all, I wanted to use some other RTOS in the NS side while testing tf-m. Is there a simple way to use the Zephyr kernel or FreeRTOS in the tf-m-test (-DTEST_S=ON, -DTEST_NS=ON) instead of the default RTX? Best, -- Antonio Ken Iannillo Research Scientist – SEDAN group SnT – Interdisciplinary Centre for Security, Reliability and Trust UNIVERSITÉ DU LUXEMBOURG CAMPUS KIRCHBERG 29, avenue John F. Kennedy L-1855 Luxembourg Kirchberg T +352 46 66 44 9660 Join the conversation News | Twitter | Linkedin www.uni.lu/snt

4 years, 12 months

1
0
0 0

Re: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging

by Kevin Peng

Hi all, As the isolation level 3 PoC targets for AN521 and MUSCA_B1 only at the first stage, two level-3-specific linker script files are created for these two platforms. And the common linker scripts are not changed now. This would avoid affecting the platforms who do not support isolation level 3 with a big changed linker script. The patch for specific linker scripts can be found here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6717 Best Regards, Kevin From: Kevin Peng Sent: Wednesday, October 21, 2020 5:27 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: RE: Feature branch 'feature-isolation-level3' is created for related patches merging Hi all, We've finished the PoC of isolation level 3 along with the new TFM HAL on the feature branch. And now we are migrating the patches to master branch by cherry-picking, squashing and refining. Here are the several topics ongoing parallel: * Linker script changes for isolation L3<https://review.trustedfirmware.org/q/topic:%22linker_script_isolation%22+(s…> * Isolation HAL API<https://review.trustedfirmware.org/q/topic:%22isolation_api_implementation%…> * SPM log<https://review.trustedfirmware.org/q/topic:%22SPM_LOG%22+(status:open%20OR%…> * SP log<https://review.trustedfirmware.org/q/topic:%22tfm_sp_log%22+(status:open%20…> And the HAL API docs: * Docs: Design of the TF-M isolation HAL<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4829> More patches will be coming soon, will keep you update-to-date. Please help on reviews, thanks. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 9, 2020 3:21 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] Feature branch 'feature-isolation-level3' is created for related patches merging Hi, A new branch created for two repos 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m', this feature branch is for isolation related patches merging. The POC patches would come in following days, first platform would be AN521. If you want to try this branch, please: IMPORTANT: Checkout 'feature-isoaltion-level3' branch for both 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m'. BR /Ken

5 years

1
0
0 0

Upgrade crypto to mbedtls-2.24 tag

by Soby Mathew

Hi Everyone This is a heads to notify that we have some patches to upgrade to mbedtls-2.24 tag and we hope to merge them today. The patches can be found here: https://review.trustedfirmware.org/q/topic:%22mbedtls-2.24%22+(status:open%… Please be aware that there is a change in tf-m-tests as well which means that if the build system is setup to download latest master of tf-m-tests, you need to update TF-M to latest master as well for the build to succeed. This is not ideal workflow, but we are thinking about some system to avoid this kind of problems. Best Regards Soby Mathew

5 years

1
0
0 0

Re: [TF-M] Deprecate AN539 platform

by Soby Mathew

An update on this: The platform has been deprecated and is scheduled for removal from upstream after TFvMv1.2 release. Patches to warn about deprecation of this platform have been merged https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6516 Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby Mathew via TF-M Sent: 17 August 2020 15:12 To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Deprecate AN539 platform Hi Everyone, As mentioned in https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/contr…, we would like to propose the deprecation of AN539 MPS2 platform and remove the same from TF-M master after next release. As per the process, this proposal will be open for discussion for a period of 4 weeks and if there are no major objections, the platform will be marked as deprecated. Thanks & Regards Soby Mathew

5 years

1
0
0 0

Re: [TF-M] [RFC] TF-M Documentation Contribution Format

by Gyorgy Szing

Hi, I think this effort should be done together with other tf.org projects using the same technology (Sphinx). Can you pls sync up with the TF-A team? Related to the details: * I suggest referring to the RTD style guide [1] instead of Python. The text is much smaller, does not cover topics we don’t need and your points 1-5 are aligned. Point 6 is conflicting as RTD allows 6 levels. * I disagree on 11. “A drawing is worth 1e3 words”, and hiding these at the end is not a good practice. * 12: do we really need this? How often are people doing such things? * 13 is ok 😊 * 14: might be too strict. What if a term is over used and may have a different meaning is some sections (i.e. platform, host, etc...). [1] https://documentation-style-guide-sphinx.readthedocs.io/en/latest/style-gui… /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Minos Galanakis via TF-M Sent: 30 June 2020 16:23 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] TF-M Documentation Contribution Format Hi, As the project matures, and the community grows, I would like to revive an old discussion and suggest that we set some guidelines for contributing to the project's documentation. I would like to propose that we establish a minimal sub-set of rules, based on the official Python guidelines<https://devguide.python.org/documenting/#style-guide> which is the most widely used notation. This offers compatibility with existing tools for proofing and producing said documentation. The following rules should be considered: 1. H1 document title headers should be expressed by # with over-line (rows on top and bottom) of the text 2. Only ONE H1 header should allowed per document, ideally placed on top of the page. 3. H2 headers should be expressed by * with over-line 4. H2 header's text should be UNIQUE in per document basis 5. H3 headers should be expressed by a row of '=' 6. H4 headers should be expressed by a row of '-' 7. H3 and H4 headers have no limitation about naming. They can have similar names on the same document, as long as they have different parents. 8. H5 headers should be expressed by a row of '^' 9. H5 headers will be rendered in document body but not in menus on the navigation bar. 10. Do not use more than 5 level of heading 11. When writing guide, which are expected to be able to be readable by command line tools, it would be best practice to add long complicated tables, and UML diagrams in the bottom of the page and using internal references(auto-label). Please refer to the `tfm_sw_requirement.rst<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/getti…>` as an example 12. No special formatting should be allowed in Headers ( code, underline, strike-through etc ) 13. Long URLs and external references should be placed at the bottom of the page and referenced in the body of the document 14. New introduced terms and abbreviations should be added to Glossary and directly linked by the `:term:` notation across all documents using it. When something new, which is not covered is required, the rule should be first to follow the any reference to of an existing document, and the Python Documentation rules otherwise. Please let me know if you have any questions/objection or proposals or new rules you would like to consider. Any feedback is more than welcome. Minos

5 years

2
1
0 0

Re: [TF-M] TF-M Technical Forum call – October 29

by Tamas Ban

Hi Anton, I would like to give an overview about the code sharing feature. Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shawn Shan via TF-M Sent: 2020. október 26., hétfő 3:30 To: Anton Komlev <Anton.Komlev(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M Technical Forum call – October 29 Hi Anton, I would like to briefly introduce the update of TF-M log system, about 20 minutes. Best regards, Shawn 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, October 23, 2020 5:56 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] TF-M Technical Forum call – October 29 Hello, The next Technical Forum is planned on Thursday, October 29 (for US 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

5 years

2
1
0 0

Re: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging

by Ken Liu

Hi, Reminder the isolation design document which will be merged before code freeze, too: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4730 Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Peng via TF-M Sent: Friday, October 23, 2020 5:32 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging Another topic added: New isolation implementation<https://review.trustedfirmware.org/q/topic:%22isolation-implement%22+(statu…> based on the isolation APIs. We are opening for new review comments before the end of October to catch the TF-M v1.2 release code freeze. Best Regards, Kevin From: Kevin Peng Sent: Wednesday, October 21, 2020 5:27 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: RE: Feature branch 'feature-isolation-level3' is created for related patches merging Hi all, We've finished the PoC of isolation level 3 along with the new TFM HAL on the feature branch. And now we are migrating the patches to master branch by cherry-picking, squashing and refining. Here are the several topics ongoing parallel: * Linker script changes for isolation L3<https://review.trustedfirmware.org/q/topic:%22linker_script_isolation%22+(s…> * Isolation HAL API<https://review.trustedfirmware.org/q/topic:%22isolation_api_implementation%…> * SPM log<https://review.trustedfirmware.org/q/topic:%22SPM_LOG%22+(status:open%20OR%…> * SP log<https://review.trustedfirmware.org/q/topic:%22tfm_sp_log%22+(status:open%20…> And the HAL API docs: * Docs: Design of the TF-M isolation HAL<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4829> More patches will be coming soon, will keep you update-to-date. Please help on reviews, thanks. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 9, 2020 3:21 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] Feature branch 'feature-isolation-level3' is created for related patches merging Hi, A new branch created for two repos 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m', this feature branch is for isolation related patches merging. The POC patches would come in following days, first platform would be AN521. If you want to try this branch, please: IMPORTANT: Checkout 'feature-isoaltion-level3' branch for both 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m'. BR /Ken

5 years

1
0
0 0

Re: [TF-M] TF-M Technical Forum call – October 29

by Shawn Shan

Hi Anton, I would like to briefly introduce the update of TF-M log system, about 20 minutes. Best regards, Shawn From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Friday, October 23, 2020 5:56 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call – October 29 Hello, The next Technical Forum is planned on Thursday, October 29 (for US 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

5 years

1
0
0 0

Invitation: TF-M Tech forum @ Every 4 weeks from 8am to 9am on Thursday from Thu Oct 29 to Fri Mar 26, 2021 (MST) (tf-m@lists.trustedfirmware.org)

by Don Harbin

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/==… Info====Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: TF-M Tech forum - US Time Zone FriendlyTime: Oct 29, 2020 03:00 PM Greenwich Mean Time        Every 4 weeks on Thu, until Mar 18, 2021, 6 occurrence(s)        Oct 29, 2020 03:00 PM        Nov 26, 2020 03:00 PM        Dec 24, 2020 03:00 PM        Jan 21, 2021 03:00 PM        Feb 18, 2021 03:00 PM        Mar 18, 2021 03:00 PMPlease download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJEocOmvpz4tHtYu0Wvn2fOsG91u0kv_ECPd/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz09Meeting ID: 955 7079 5742Passcode: 177658One tap mobile+12532158782,,95570795742# US (Tacoma)+13462487799,,95570795742# US (Houston)Dial by your location        +1 253 215 8782 US (Tacoma)        +1 346 248 7799 US (Houston)        +1 669 900 9128 US (San Jose)        +1 301 715 8592 US (Germantown)        +1 312 626 6799 US (Chicago)        +1 646 558 8656 US (New York)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 955 7079 5742Find your local number: https://linaro-org.zoom.us/u/abx3I7IoRq When: Every 4 weeks from 8am to 9am on Thursday from Thu Oct 29 to Fri Mar 26, 2021 Mountain Standard Time - Phoenix Where: https://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz… Calendar: tf-m(a)lists.trustedfirmware.org Who: * Don Harbin - creator * tf-m(a)lists.trustedfirmware.org * anton.komlev(a)arm.com Event details: https://www.google.com/calendar/event?action=VIEW&eid=NjQzcnZwcmEwNnV2cGoxN… 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 organizer and be added to the guest list, or 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

1
0
0 0

Invitation: TF-M Tech forum @ Every 4 weeks from 12am to 1am on Thursday from Thu Nov 12 to Fri May 28, 2021 (MST) (tf-m@lists.trustedfirmware.org)

by Don Harbin

You have been invited to the following event. Title: TF-M Tech forum About 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/==…Topic: TF-M Tech forum - Asia Time Zone FriendlyTime: Nov 12, 2020 07:00 AM Greenwich Mean Time        Every 4 weeks on Thu, until Mar 4, 2021, 5 occurrence(s)        Nov 12, 2020 07:00 AM        Dec 10, 2020 07:00 AM        Jan 7, 2021 07:00 AM        Feb 4, 2021 07:00 AM        Mar 4, 2021 07:00 AMPlease download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJYodOyvpz8jGNEc_1ykVap8Zg6oTLqZZSeJ/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT09Meeting ID: 925 3579 4925Passcode: 414410One tap mobile+12532158782,,92535794925# US (Tacoma)+13462487799,,92535794925# US (Houston)Dial by your location        +1 253 215 8782 US (Tacoma)        +1 346 248 7799 US (Houston)        +1 669 900 9128 US (San Jose)        +1 301 715 8592 US (Germantown)        +1 312 626 6799 US (Chicago)        +1 646 558 8656 US (New York)        888 788 0099 US Toll-free        877 853 5247 US Toll-freeMeeting ID: 925 3579 4925Find your local number: https://linaro-org.zoom.us/u/aesS64I7GW When: Every 4 weeks from 12am to 1am on Thursday from Thu Nov 12 to Fri May 28, 2021 Mountain Standard Time - Phoenix Where: https://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT… Calendar: tf-m(a)lists.trustedfirmware.org Who: * Don Harbin - creator * tf-m(a)lists.trustedfirmware.org * anton.komlev(a)arm.com Event details: https://www.google.com/calendar/event?action=VIEW&eid=NTAyYXB1M2xsYzJ2MzU3M… 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 organizer and be added to the guest list, or 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

1
0
0 0

TF-M Technical Forum call – October 29

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, October 29 (for US 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

5 years

1
0
0 0

Re: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging

by Kevin Peng

Hi all, We've finished the PoC of isolation level 3 along with the new TFM HAL on the feature branch. And now we are migrating the patches to master branch by cherry-picking, squashing and refining. Here are the several topics ongoing parallel: * Linker script changes for isolation L3<https://review.trustedfirmware.org/q/topic:%22linker_script_isolation%22+(s…> * Isolation HAL API<https://review.trustedfirmware.org/q/topic:%22isolation_api_implementation%…> * SPM log<https://review.trustedfirmware.org/q/topic:%22SPM_LOG%22+(status:open%20OR%…> * SP log<https://review.trustedfirmware.org/q/topic:%22tfm_sp_log%22+(status:open%20…> And the HAL API docs: * Docs: Design of the TF-M isolation HAL<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4829> More patches will be coming soon, will keep you update-to-date. Please help on reviews, thanks. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 9, 2020 3:21 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging Hi, A new branch created for two repos 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m', this feature branch is for isolation related patches merging. The POC patches would come in following days, first platform would be AN521. If you want to try this branch, please: IMPORTANT: Checkout 'feature-isoaltion-level3' branch for both 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m'. BR /Ken

5 years

1
1
0 0

Re: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging

by Ken Liu

Hi, Thank Tamas for the scenario, this is a good example. There were some queries and initial investigations before, which shows that some users want to protect the implementation of their services, and check if there are mechanisms to help on that. I think isolation level 3 is applicable to this scenario. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M Sent: Wednesday, October 21, 2020 7:26 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging Hi Andrej, the following scenario comes to my mind: * There is a product where secure services from different vendors are merged together and these are together make up the ARoT code. * There is a vendor who has a novel algorithm what he wants to protect against reverse engineering. * Image is delivered to the device in encrypted format. But on the device it is decrypted when moved to primary slot. * This secure partition needs the L3 isolation to be hidden from the other secure services within ARoT code. Tamas 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: 2020. október 21., szerda 11:53 To: Kevin Peng <Kevin.Peng(a)arm.com<mailto:Kevin.Peng@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging Hi Kevin, Do you know any real (not academic) MCU application where L3 isolation is required? People ask, but I have nothing to tell. Even for L2 is difficult to find something, for most of cases L1 is enough. Thanks, Andrej From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Peng via TF-M Sent: Wednesday, October 21, 2020 11:27 AM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: Re: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging Hi all, We've finished the PoC of isolation level 3 along with the new TFM HAL on the feature branch. And now we are migrating the patches to master branch by cherry-picking, squashing and refining. Here are the several topics ongoing parallel: * Linker script changes for isolation L3<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> * Isolation HAL API<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> * SPM log<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> * SP log<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> And the HAL API docs: * Docs: Design of the TF-M isolation HAL<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> More patches will be coming soon, will keep you update-to-date. Please help on reviews, thanks. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 9, 2020 3:21 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] Feature branch 'feature-isolation-level3' is created for related patches merging Hi, A new branch created for two repos 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m', this feature branch is for isolation related patches merging. The POC patches would come in following days, first platform would be AN521. If you want to try this branch, please: IMPORTANT: Checkout 'feature-isoaltion-level3' branch for both 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m'. BR /Ken

5 years

1
0
0 0

Re: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging

by Tamas Ban

Hi Andrej, the following scenario comes to my mind: * There is a product where secure services from different vendors are merged together and these are together make up the ARoT code. * There is a vendor who has a novel algorithm what he wants to protect against reverse engineering. * Image is delivered to the device in encrypted format. But on the device it is decrypted when moved to primary slot. * This secure partition needs the L3 isolation to be hidden from the other secure services within ARoT code. Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 2020. október 21., szerda 11:53 To: Kevin Peng <Kevin.Peng(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging Hi Kevin, Do you know any real (not academic) MCU application where L3 isolation is required? People ask, but I have nothing to tell. Even for L2 is difficult to find something, for most of cases L1 is enough. Thanks, Andrej From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Peng via TF-M Sent: Wednesday, October 21, 2020 11:27 AM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: Re: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging Hi all, We've finished the PoC of isolation level 3 along with the new TFM HAL on the feature branch. And now we are migrating the patches to master branch by cherry-picking, squashing and refining. Here are the several topics ongoing parallel: * Linker script changes for isolation L3<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> * Isolation HAL API<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> * SPM log<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> * SP log<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> And the HAL API docs: * Docs: Design of the TF-M isolation HAL<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> More patches will be coming soon, will keep you update-to-date. Please help on reviews, thanks. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 9, 2020 3:21 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] Feature branch 'feature-isolation-level3' is created for related patches merging Hi, A new branch created for two repos 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m', this feature branch is for isolation related patches merging. The POC patches would come in following days, first platform would be AN521. If you want to try this branch, please: IMPORTANT: Checkout 'feature-isoaltion-level3' branch for both 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m'. BR /Ken

5 years

1
0
0 0

Re: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging

by Andrej Butok

Hi Kevin, Do you know any real (not academic) MCU application where L3 isolation is required? People ask, but I have nothing to tell. Even for L2 is difficult to find something, for most of cases L1 is enough. Thanks, Andrej From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Peng via TF-M Sent: Wednesday, October 21, 2020 11:27 AM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging Hi all, We've finished the PoC of isolation level 3 along with the new TFM HAL on the feature branch. And now we are migrating the patches to master branch by cherry-picking, squashing and refining. Here are the several topics ongoing parallel: * Linker script changes for isolation L3<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> * Isolation HAL API<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> * SPM log<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> * SP log<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> And the HAL API docs: * Docs: Design of the TF-M isolation HAL<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> More patches will be coming soon, will keep you update-to-date. Please help on reviews, thanks. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 9, 2020 3:21 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] Feature branch 'feature-isolation-level3' is created for related patches merging Hi, A new branch created for two repos 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m', this feature branch is for isolation related patches merging. The POC patches would come in following days, first platform would be AN521. If you want to try this branch, please: IMPORTANT: Checkout 'feature-isoaltion-level3' branch for both 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m'. BR /Ken

5 years

1
0
0 0

Re: [TF-M] Another build issue

by David Hu

Hi Chris, I've raised a ticket https://github.com/ARM-software/psa-arch-tests/issues/239 on PSA Arch test github repo. It will be fixed by PSA Arch test team later. We will follow the fix status. Thanks again for reporting this issue. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Tuesday, October 20, 2020 11:05 AM To: Christopher Brand <chris.brand(a)cypress.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Another build issue Hi Chris, I agree with you. It looks like PSA arch test doesn't check the correct clone destination. According to https://github.com/ARM-software/psa-arch-tests/blob/master/api-tests/CMakeL…, PSA arch test checks whether psa_qcbor exists. However, the actual clone destination of psa_qcbor folder is under CMAKE_CURRENT_BINARY_DIR as https://github.com/ARM-software/psa-arch-tests/blob/master/api-tests/CMakeL… sets. Therefore, I guess this issue will be triggered as long as CMake script execution is in the different directory as binary folder is. I changed the destination to ${CMAKE_CURRENT_BINARY_DIR}/${PSA_TARGET_QCBOR} in check step and it looks like the issue is fixed. IMOO, the quick workaround is to entirely remove the build directory. I will discuss with Raef to determine a final solution. Thanks a lot for reporting this issue! Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Christopher Brand via TF-M Sent: Tuesday, October 20, 2020 5:57 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Another build issue This one is a failure when re-configuring the build (even though the configuration is the same): $ mkdir build_GNUARM_Release $ cmake -S . -B build_GNUARM_Release -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Release -DTEST_PSA_API=INITIAL_ATTESTATION (lots of output - eventually succeeds) $ cmake -S . -B build_GNUARM_Release -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Release -DTEST_PSA_API=INITIAL_ATTESTATION (less output, eventually fails) fatal: destination path 'psa_qcbor' already exists and is not an empty directory. CMake Error at build_GNUARM_Release/lib/ext/psa_arch_tests-src/api-tests/CMakeLists.txt:324 (message): git clone failed for https://github.com/laurencelundblade/QCBOR.git I suspect that this might be due to the PSA stuff, rather than TFM per se, but it manifests when building TFM... Chris Brand Sr Prin Software Engr, MCD: WIRELESS Cypress Semiconductor Corp. An Infineon Technologies Company #320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com> This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years

1
0
0 0

Re: [TF-M] Generated files location

by Andrej Butok

Hi Anton If it's not possible to avoid a file generation now, it's good to have pre-generated files for a most typical configuration (l2, IPC etc.). As I mentioned before, ideally to use TFM as a real component/framework without generation of any source code. BUT If you believe, this requirement breaks a TFM concept, just tell us. Thanks, Andrej From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Tuesday, October 20, 2020 9:27 AM To: tf-m(a)lists.trustedfirmware.org Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Generated files location Hi Andrej, Essentially, do you mean to move the files back to code tree and synch them with templates manually as it was ? Cheers, Anton From: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>> Sent: 19 October 2020 16:15 To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: RE: Generated files location Hi Anton, Another option: 3. Avoid the mandatory on-the-fly generation. Try to make TFM a component/framework, which is configurable by compile & run time parameters. 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: Monday, October 19, 2020 5:00 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] Generated files location Hi, Some source files in TF-M are templated and generated inside /<build_dir>/generated/ on the fly as a part of build process. This guaranty consistency between templates and generated but might make a trouble for IDE, where not all source files exist at the first run. I see 2 options for solution: 1. Explicitly generate those files via cmake as a part of IDE project creation (1 time action) 2. Relay on CMSIS Pack for IDE, where generated files must be presents Any alternative thoughts? Anton

5 years

1
0
0 0

Re: [TF-M] Generated files location

by Andrej Butok

Hi Anton, Another option: 3. Avoid the mandatory on-the-fly generation. Try to make TFM a component/framework, which is configurable by compile & run time parameters. Thanks, Andrej From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Monday, October 19, 2020 5:00 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Generated files location Hi, Some source files in TF-M are templated and generated inside /<build_dir>/generated/ on the fly as a part of build process. This guaranty consistency between templates and generated but might make a trouble for IDE, where not all source files exist at the first run. I see 2 options for solution: 1. Explicitly generate those files via cmake as a part of IDE project creation (1 time action) 2. Relay on CMSIS Pack for IDE, where generated files must be presents Any alternative thoughts? Anton

5 years

2
1
0 0

Re: [TF-M] Another build issue

by David Hu

Hi Chris, I agree with you. It looks like PSA arch test doesn't check the correct clone destination. According to https://github.com/ARM-software/psa-arch-tests/blob/master/api-tests/CMakeL…, PSA arch test checks whether psa_qcbor exists. However, the actual clone destination of psa_qcbor folder is under CMAKE_CURRENT_BINARY_DIR as https://github.com/ARM-software/psa-arch-tests/blob/master/api-tests/CMakeL… sets. Therefore, I guess this issue will be triggered as long as CMake script execution is in the different directory as binary folder is. I changed the destination to ${CMAKE_CURRENT_BINARY_DIR}/${PSA_TARGET_QCBOR} in check step and it looks like the issue is fixed. IMOO, the quick workaround is to entirely remove the build directory. I will discuss with Raef to determine a final solution. Thanks a lot for reporting this issue! Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: Tuesday, October 20, 2020 5:57 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Another build issue This one is a failure when re-configuring the build (even though the configuration is the same): $ mkdir build_GNUARM_Release $ cmake -S . -B build_GNUARM_Release -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Release -DTEST_PSA_API=INITIAL_ATTESTATION (lots of output - eventually succeeds) $ cmake -S . -B build_GNUARM_Release -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Release -DTEST_PSA_API=INITIAL_ATTESTATION (less output, eventually fails) fatal: destination path 'psa_qcbor' already exists and is not an empty directory. CMake Error at build_GNUARM_Release/lib/ext/psa_arch_tests-src/api-tests/CMakeLists.txt:324 (message): git clone failed for https://github.com/laurencelundblade/QCBOR.git I suspect that this might be due to the PSA stuff, rather than TFM per se, but it manifests when building TFM... Chris Brand Sr Prin Software Engr, MCD: WIRELESS Cypress Semiconductor Corp. An Infineon Technologies Company #320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com> This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years

1
0
0 0

Another build issue

by Christopher Brand

This one is a failure when re-configuring the build (even though the configuration is the same): $ mkdir build_GNUARM_Release $ cmake -S . -B build_GNUARM_Release -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Release -DTEST_PSA_API=INITIAL_ATTESTATION (lots of output - eventually succeeds) $ cmake -S . -B build_GNUARM_Release -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Release -DTEST_PSA_API=INITIAL_ATTESTATION (less output, eventually fails) fatal: destination path 'psa_qcbor' already exists and is not an empty directory. CMake Error at build_GNUARM_Release/lib/ext/psa_arch_tests-src/api-tests/CMakeLists.txt:324 (message): git clone failed for https://github.com/laurencelundblade/QCBOR.git I suspect that this might be due to the PSA stuff, rather than TFM per se, but it manifests when building TFM... Chris Brand Sr Prin Software Engr, MCD: WIRELESS Cypress Semiconductor Corp. An Infineon Technologies Company #320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com> This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years

1
0
0 0

Re: [TF-M] Build failure

by Christopher Brand

Looks like that test is indeed not supported on PSoC64. The error message threw me because it says what the valid values are for -DTARGET (which does include one containing "psoc64"), but it doesn't tell me what -DTAREGT was actually set to. Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: Monday, October 19, 2020 1:42 PM To: David Hu <David.Hu(a)arm.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Build failure CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. We definitely used to be able to at least build ConfigPsaApiTestIPC.cmake (and the level 2 version) for PSoC64 under the old build system. It looks like we've always done so with one of the other PSA test suites also selected, which doesn't seem to be an option with the new build system. Is there an example TEST_PSA_API=IPC build for another platform I can look at? Chris From: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>> Sent: Sunday, October 18, 2020 11:10 PM To: Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: RE: Build failure Hi Chris, Sorry for the trouble. May I know if the same configurations worked with the previous build system? I checked a previous version of PSoC 64 specifics and it didn't explicitly claim to support FF compliance tests. Could you please confirm it with Alamy? Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Christopher Brand via TF-M Sent: Saturday, October 17, 2020 7:07 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Build failure I'm experimenting with the new build system, and seeing an error. Looking at docs/getting_started/tfm_build_instruction.rst, it mentions that TEST_PSA_API=IPC is a valid option ("Firmware Framework test suite"). When I try to configure for that build, though, I get an error: $ cmake -S . -B build_GNUARM_Release '-GUnix Makefiles' -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Release -DTEST_PSA_API=IPC CMake Error at build_GNUARM_Release/lib/ext/psa_arch_tests-src/api-tests/CMakeLists.txt:119 (message): [PSA] : Error: Unspported value for -DTARGET=, supported targets are : common;tgt_dev_apis_stdc;tgt_dev_apis_tfm_an521;tgt_dev_apis_tfm_an524;tgt_dev_apis_tfm_an539;tgt_dev_apis_tfm_musca_a;tgt_dev_apis_tfm_musca_b1;tgt_dev_apis_tfm_musca_s1;tgt_dev_apis_tfm_psoc64;tgt_ff_tfm_an521;tgt_ff_tfm_musca_a;tgt_ff_tfm_musca_b1 I see the same error with and without "-DTFM_ISOLATION_LEVEL=2". Chris Brand Sr Prin Software Engr, MCD: WIRELESS Cypress Semiconductor Corp. An Infineon Technologies Company #320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com> This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years

1
0
0 0

Re: [TF-M] Build failure

by David Hu

Hi Chris, Sorry for the trouble. May I know if the same configurations worked with the previous build system? I checked a previous version of PSoC 64 specifics and it didn't explicitly claim to support FF compliance tests. Could you please confirm it with Alamy? Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: Saturday, October 17, 2020 7:07 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Build failure I'm experimenting with the new build system, and seeing an error. Looking at docs/getting_started/tfm_build_instruction.rst, it mentions that TEST_PSA_API=IPC is a valid option ("Firmware Framework test suite"). When I try to configure for that build, though, I get an error: $ cmake -S . -B build_GNUARM_Release '-GUnix Makefiles' -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Release -DTEST_PSA_API=IPC CMake Error at build_GNUARM_Release/lib/ext/psa_arch_tests-src/api-tests/CMakeLists.txt:119 (message): [PSA] : Error: Unspported value for -DTARGET=, supported targets are : common;tgt_dev_apis_stdc;tgt_dev_apis_tfm_an521;tgt_dev_apis_tfm_an524;tgt_dev_apis_tfm_an539;tgt_dev_apis_tfm_musca_a;tgt_dev_apis_tfm_musca_b1;tgt_dev_apis_tfm_musca_s1;tgt_dev_apis_tfm_psoc64;tgt_ff_tfm_an521;tgt_ff_tfm_musca_a;tgt_ff_tfm_musca_b1 I see the same error with and without "-DTFM_ISOLATION_LEVEL=2". Chris Brand Sr Prin Software Engr, MCD: WIRELESS Cypress Semiconductor Corp. An Infineon Technologies Company #320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com> This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years

2
1
0 0

Generated files location

by Anton Komlev

Hi, Some source files in TF-M are templated and generated inside /<build_dir>/generated/ on the fly as a part of build process. This guaranty consistency between templates and generated but might make a trouble for IDE, where not all source files exist at the first run. I see 2 options for solution: 1. Explicitly generate those files via cmake as a part of IDE project creation (1 time action) 2. Relay on CMSIS Pack for IDE, where generated files must be presents Any alternative thoughts? Anton

5 years

1
0
0 0

Re: [TF-M] New build system missing GNUARM_PREFIX support

by Raef Coles

Hi, yes apologies that seems to have been lost. I was doing my best to track changes in the original cmake but it seems this one got missed. Can I ask - for the vendor triplet compilers (arm-etc-eabi-gcc), is it a compiler that the vendor is developing? In the new buildsystem, it might make sense to create a new compiler toolchain file that is almost identical to the GNU one, which would allow the two compilers to diverge slightly (in command-line options etc) if necessary. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Kumar Gala via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 07 October 2020 17:26 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] New build system missing GNUARM_PREFIX support It looks like the GNUARM_PREFIX changes got dropped as part of the new build system. Can someone look at restoring those changes? - k -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years

2
2
0 0

Build failure

by Christopher Brand

I'm experimenting with the new build system, and seeing an error. Looking at docs/getting_started/tfm_build_instruction.rst, it mentions that TEST_PSA_API=IPC is a valid option ("Firmware Framework test suite"). When I try to configure for that build, though, I get an error: $ cmake -S . -B build_GNUARM_Release '-GUnix Makefiles' -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Release -DTEST_PSA_API=IPC CMake Error at build_GNUARM_Release/lib/ext/psa_arch_tests-src/api-tests/CMakeLists.txt:119 (message): [PSA] : Error: Unspported value for -DTARGET=, supported targets are : common;tgt_dev_apis_stdc;tgt_dev_apis_tfm_an521;tgt_dev_apis_tfm_an524;tgt_dev_apis_tfm_an539;tgt_dev_apis_tfm_musca_a;tgt_dev_apis_tfm_musca_b1;tgt_dev_apis_tfm_musca_s1;tgt_dev_apis_tfm_psoc64;tgt_ff_tfm_an521;tgt_ff_tfm_musca_a;tgt_ff_tfm_musca_b1 I see the same error with and without "-DTFM_ISOLATION_LEVEL=2". Chris Brand Sr Prin Software Engr, MCD: WIRELESS Cypress Semiconductor Corp. An Infineon Technologies Company #320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com> This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years

1
0
0 0

Security vulnerability notice - Secure stack sealing

by Soby Mathew

Hi Everyone There is a new security vulnerability report for Secure software executing on Armv8-M processors that causes it to be vulnerable to attacks from the Non-secure state if the secure stacks are not sealed properly. More details about the vulnerability can be found here: https://developer.arm.com/support/arm-security-updates/armv8-m-stack-sealing Please find the security advisory specific to TF-M and patches that have been developed as per the TrustedFirmware.org security process[1] below : 1. TF-M Security advisory https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6455/1 2. Fix based on TF-Mv1.1 release has been uploaded as a new branch "TF-Mv1.1-stack-seal-mitigation" to the main repository. The branch can also be accessed here: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/log/?h=TF-Mv1.1… 3. Fix based on the latest master is available here: https://review.trustedfirmware.org/q/topic:%22stack-seal-mitigation%22. Please let us know if you have any comments. Best Regards Soby Mathew [1] https://developer.trustedfirmware.org/w/collaboration/security_center/repor…

5 years

1
0
0 0

Re: [TF-M] Behavior difference in Crypto IPC vs Library modes

by Tamas Ban

Hi Raymond, Test case 240, 241 are known limitation of cc312 driver. It is published here https://developer.trustedfirmware.org/T691 Tamas ________________________________ Feladó: TF-M <tf-m-bounces(a)lists.trustedfirmware.org>, meghatalmazó: Raymond Ngun via TF-M <tf-m(a)lists.trustedfirmware.org> Elküldve: 2020. október 15., csütörtök 20:29 Címzett: Soby Mathew <Soby.Mathew(a)arm.com>; Summer Qin <Summer.Qin(a)arm.com> Másolatot kap: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Tárgy: Re: [TF-M] Behavior difference in Crypto IPC vs Library modes Hi Soby and Summer, Thank you for pointing me to the complete chain of patches. I didn’t notice. With this, PSoC64 behaves quite well without any buffer changes. In fact, the results look better than previously published AN521 results – what are the latest AN521 results? It looks like 250 and 251 now passes but failed in previous AN521 results. Again, this is for PSoC64 As for Musca-B1, it looks like it is better (CC312 enabled). 241/242 is still failing and 250 is failing (passes for PSoC64). Disabling CC312 will result in 241/242 passing Thank you, Ray From: Soby Mathew <Soby.Mathew(a)arm.com> Sent: Thursday, October 15, 2020 8:01 AM To: Summer Qin <Summer.Qin(a)arm.com>; Raymond Ngun <Raymond.Ngun(a)cypress.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: RE: Behavior difference in Crypto IPC vs Library modes Hi Raymond, Some of the PSA Crypto tests require a larger buffer size and previously this was done within the build system. This size is required irrespective of IPC or Library mode. The new build system broke this buffer size configuration for API tests and the patch mentioned by Summer resolves that. Could you try with that and let us know ? Regarding Musca-B1, we switched to using Cryptocell as default for that platform recently. There are some limitations for the CC-312 with respect to some crypto APIs and I suspect the failures are related to this. I will create a ticket to look further into this. Meanwhile could you try whether you have failures if you disable CC-312 for Musca-B1 : diff --git a/platform/ext/target/musca_b1/config.cmake b/platform/ext/target/musca_b1/config.cmake index b343af36..47a2bfad 100644 --- a/platform/ext/target/musca_b1/config.cmake +++ b/platform/ext/target/musca_b1/config.cmake @@ -6,5 +6,5 @@ #------------------------------------------------------------------------------- set(PLATFORM_DUMMY_ATTEST_HAL FALSE CACHE BOOL "Use dummy boot hal implementation. Should not be used in production." FORCE) -set(CRYPTO_HW_ACCELERATOR ON CACHE BOOL "Whether to enable the crypto hardware accelerator on supported platforms" FORCE) +set(CRYPTO_HW_ACCELERATOR OFF CACHE BOOL "Whether to enable the crypto hardware accelerator on supported platforms" FORCE) set(TFM_CRYPTO_TEST_ALG_CFB OFF CACHE BOOL "Test CFB cryptography mode" FORCE) Best Regards Soby Mathew From: Summer Qin <Summer.Qin(a)arm.com<mailto:Summer.Qin@arm.com>> Sent: 15 October 2020 07:58 To: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>>; Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: Behavior difference in Crypto IPC vs Library modes Hi Raymond, Do you cherry-pick all the series patches (topic: sm/new_build_crypto<https://review.trustedfirmware.org/q/topic:%22sm%252Fnew_build_crypto%22+(s…> ) or just only pick the one Soby provided? I testes on AN521, without all the series patches, 219, 241, 242, and 243 are failed. But when you cherry-pick all series patches, they can pass. And I think patch https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6251 already increase the size for CRYPTO_ENGINE_BUF_SIZE. Thanks, Summer ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Raymond Ngun via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Thursday, October 15, 2020 6:54 AM To: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: Re: [TF-M] Behavior difference in Crypto IPC vs Library modes Hi Soby, Thank you for that fix! It does indeed fix this particular issue when using IPC. On another note, I’ve been running Musca-B1 and the results differ from what you sent out in the past for AN521. Specifically, Musca-B1 fails 219, 241, 242, and 243. Is this something you can have a look at on the Musca-B1 side? With that said, I’ve been running on PSoC64 and I can reproduce the AN521 results. I needed the patch you provided below but I was still running into memory issues and I had to bump the following (both of them). #define TFM_CRYPTO_IOVEC_BUFFER_SIZE (8120) #define TFM_CRYPTO_ENGINE_BUF_SIZE (0x5040) /* >8KB for EC signing in attest */ If I do not bump these, I would see 239 to 244 fail. Might you have any comments on the larger size requirements for these? Possibly when running in IPC mode? Thank you, Ray From: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> Sent: Wednesday, October 14, 2020 8:52 AM To: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: RE: Behavior difference in Crypto IPC vs Library modes Hi Raymond, After further analysis, it seems to me that having separate checks for Library mode and IPC mode is the easiest way to go. The current design was done in such a way that both Library and IPC mode can reuse the same crypto service API involving IOVECs. Any change to how the API is invoked from the tfm_crypto_call_sfn() will have ramifications for Library mode. I have done a patch with different checks for IPC and Library mode here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6432 . The patch relaxes the checks for IPC mode to allow empty buffers and hardens the checks for Library mode. Hopefully this should resolve the issue. Best Regards Soby Mathew From: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> Sent: 12 October 2020 17:17 To: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>>; Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: RE: Behavior difference in Crypto IPC vs Library modes Hi Raymond, As you pointed out, the difference in this case basically boils down to how the 2 models handles empty buffers. In the library mode, the empty buffers are passed down to the target API whereas the IPC mode optimizes the empty buffer from the IOVEC by reducing the buffer length. This results in different error codes in the 2 modes. The sanity check of IOVEC in incoming sizes is needed and I less inclined to remove it or enhance it. The error code certainly seems to be one way to resolve this problem. The other option is to make the IPC mode IOVEC less aggressive in optimizing away zero buffers from IOVEC (Need more investigation) thus attaining parity with library mode. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Soby Mathew via TF-M Sent: 12 October 2020 11:50 To: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Behavior difference in Crypto IPC vs Library modes Hi Raymond Thanks for the detailed report. This issue was reported here https://developer.trustedfirmware.org/T822 previously but I didn’t get time to look into it further due to other priorities. Your analysis seems right and I will look further into this. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Raymond Ngun via TF-M Sent: 10 October 2020 00:59 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Behavior difference in Crypto IPC vs Library modes Hi all, I’m seeking some assistance in determining the correct fix for a difference in behavior between IPC and Library modes that cause the Crypto PSA Arch Tests to fail when using IPC. Specifically, I’ve been testing on a PSoC64 for IPC mode and Musca-B1 for Library mode. The problem I am encountering is related to this check in crypto (e.g. crypto_aead.c in secure_fw/partitions/crypto). if ( !((in_len == 2) || (in_len == 3)) || (out_len > 1)) { return PSA_ERROR_CONNECTION_REFUSED; } This is true for direct function call since in_len and out_len are sizes of in_vec[] and out_vec[]. However, in library mode, in_len and out_len is not based on the size of in_vec[] and out_vec[] but based on the contents. Specifically, out_len is determined via the following in tfm_crypto_call_sfn(). /* Check the number of out_vec filled */ while ((out_len > 0) && (msg->out_size[out_len - 1] == 0)) { out_len--; } >From the above, if out_size (which is passed in by the user) is 0, the resultant out_len will be 0. The out_len is passed into the crypto function and PSA_ERROR_CONNECTION_REFUSED is returned due to the check above. PSA, on the other hand, expects PSA_ERROR_NOT_SUPPORTED to be returned. Btw, in_len suffers from the same issue. I’m not sure if the check above is valid for IPC mode. I’ve removed the check temporarily to avoid the problem. However, if the check still makes sense, possibly it should return PSA_ERROR_NOT_SUPPORTED instead of PSA_ERROR_CONNECTION_REFUSED. Thank you. I look forward to comments. Ray This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years

2
1
0 0

Re: [TF-M] Behavior difference in Crypto IPC vs Library modes

by Summer Qin

Hi Raymond, Do you cherry-pick all the series patches (topic: sm/new_build_crypto<https://review.trustedfirmware.org/q/topic:%22sm%252Fnew_build_crypto%22+(s…> ) or just only pick the one Soby provided? I testes on AN521, without all the series patches, 219, 241, 242, and 243 are failed. But when you cherry-pick all series patches, they can pass. And I think patch https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6251 already increase the size for CRYPTO_ENGINE_BUF_SIZE. Thanks, Summer ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Raymond Ngun via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Thursday, October 15, 2020 6:54 AM To: Soby Mathew <Soby.Mathew(a)arm.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] Behavior difference in Crypto IPC vs Library modes Hi Soby, Thank you for that fix! It does indeed fix this particular issue when using IPC. On another note, I’ve been running Musca-B1 and the results differ from what you sent out in the past for AN521. Specifically, Musca-B1 fails 219, 241, 242, and 243. Is this something you can have a look at on the Musca-B1 side? With that said, I’ve been running on PSoC64 and I can reproduce the AN521 results. I needed the patch you provided below but I was still running into memory issues and I had to bump the following (both of them). #define TFM_CRYPTO_IOVEC_BUFFER_SIZE (8120) #define TFM_CRYPTO_ENGINE_BUF_SIZE (0x5040) /* >8KB for EC signing in attest */ If I do not bump these, I would see 239 to 244 fail. Might you have any comments on the larger size requirements for these? Possibly when running in IPC mode? Thank you, Ray From: Soby Mathew <Soby.Mathew(a)arm.com> Sent: Wednesday, October 14, 2020 8:52 AM To: Raymond Ngun <Raymond.Ngun(a)cypress.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: RE: Behavior difference in Crypto IPC vs Library modes Hi Raymond, After further analysis, it seems to me that having separate checks for Library mode and IPC mode is the easiest way to go. The current design was done in such a way that both Library and IPC mode can reuse the same crypto service API involving IOVECs. Any change to how the API is invoked from the tfm_crypto_call_sfn() will have ramifications for Library mode. I have done a patch with different checks for IPC and Library mode here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6432 . The patch relaxes the checks for IPC mode to allow empty buffers and hardens the checks for Library mode. Hopefully this should resolve the issue. Best Regards Soby Mathew From: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> Sent: 12 October 2020 17:17 To: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>>; Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: RE: Behavior difference in Crypto IPC vs Library modes Hi Raymond, As you pointed out, the difference in this case basically boils down to how the 2 models handles empty buffers. In the library mode, the empty buffers are passed down to the target API whereas the IPC mode optimizes the empty buffer from the IOVEC by reducing the buffer length. This results in different error codes in the 2 modes. The sanity check of IOVEC in incoming sizes is needed and I less inclined to remove it or enhance it. The error code certainly seems to be one way to resolve this problem. The other option is to make the IPC mode IOVEC less aggressive in optimizing away zero buffers from IOVEC (Need more investigation) thus attaining parity with library mode. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Soby Mathew via TF-M Sent: 12 October 2020 11:50 To: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Behavior difference in Crypto IPC vs Library modes Hi Raymond Thanks for the detailed report. This issue was reported here https://developer.trustedfirmware.org/T822 previously but I didn’t get time to look into it further due to other priorities. Your analysis seems right and I will look further into this. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Raymond Ngun via TF-M Sent: 10 October 2020 00:59 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Behavior difference in Crypto IPC vs Library modes Hi all, I’m seeking some assistance in determining the correct fix for a difference in behavior between IPC and Library modes that cause the Crypto PSA Arch Tests to fail when using IPC. Specifically, I’ve been testing on a PSoC64 for IPC mode and Musca-B1 for Library mode. The problem I am encountering is related to this check in crypto (e.g. crypto_aead.c in secure_fw/partitions/crypto). if ( !((in_len == 2) || (in_len == 3)) || (out_len > 1)) { return PSA_ERROR_CONNECTION_REFUSED; } This is true for direct function call since in_len and out_len are sizes of in_vec[] and out_vec[]. However, in library mode, in_len and out_len is not based on the size of in_vec[] and out_vec[] but based on the contents. Specifically, out_len is determined via the following in tfm_crypto_call_sfn(). /* Check the number of out_vec filled */ while ((out_len > 0) && (msg->out_size[out_len - 1] == 0)) { out_len--; } >From the above, if out_size (which is passed in by the user) is 0, the resultant out_len will be 0. The out_len is passed into the crypto function and PSA_ERROR_CONNECTION_REFUSED is returned due to the check above. PSA, on the other hand, expects PSA_ERROR_NOT_SUPPORTED to be returned. Btw, in_len suffers from the same issue. I’m not sure if the check above is valid for IPC mode. I’ve removed the check temporarily to avoid the problem. However, if the check still makes sense, possibly it should return PSA_ERROR_NOT_SUPPORTED instead of PSA_ERROR_CONNECTION_REFUSED. Thank you. I look forward to comments. Ray This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years

3
2
0 0

Re: [TF-M] Following the TF-M build example

by Raef Coles

Ah okay. This is the behavior we saw with the other VS generators, and why we added the check to make sure "Unix Makefiles" or "Ninja" was used. Because it sets the C compiler to MSVC, it won't correctly compile TFM (which currently only supports ARMClang, GCC, and IAR). While there are other symptoms, such as the issues with python etc, this is the main one. I'd advise to just use -G"Unix Makefiles" (or ninja) Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Kevin Kilzer via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 14 October 2020 18:13 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Following the TF-M build example Hi, Raef, I can get past the CMSIS issue by dup’ing the GNU links. It now fails for lack of the correct Python. Using the -G option, CMakeCache.txt lists all the pythons in my system and the build completes: $ grep python cmake_build/CMakeCache.txt PYTHON_EXECUTABLE:FILEPATH=C:/Python/Python27/python.exe FIND_PACKAGE_MESSAGE_DETAILS_Python3:INTERNAL=[C:/Users/cXXXXX/AppData/Local/Programs/Python/Python38-32/python.exe][cfound components: Interpreter ][v3.8.5()] _Python3_EXECUTABLE:INTERNAL=C:/Users/cXXXXX/AppData/Local/Programs/Python/Python38-32/python.exe Without the -G option, the compiler is MSVC, and the cache has no entry for python at all. Building Custom Rule C:/Users/cXXXXX/Git/arm/TF-M/trusted-firmware-m/cmake_build/lib/ext/mcuboot-subbuild/CMakeLists.txt Building Custom Rule C:/Users/cXXXXX/Git/arm/TF-M/trusted-firmware-m/cmake_build/lib/ext/mcuboot-subbuild/CMakeLists.txt -- Could NOT find Python3 (missing: Python3_EXECUTABLE Interpreter) Reason given by package: Interpreter: Wrong major version for the interpreter "C:/Python/Python27/python.exe"

5 years

1
0
0 0

Re: [TF-M] Behavior difference in Crypto IPC vs Library modes

by Soby Mathew

Hi Raymond, As you pointed out, the difference in this case basically boils down to how the 2 models handles empty buffers. In the library mode, the empty buffers are passed down to the target API whereas the IPC mode optimizes the empty buffer from the IOVEC by reducing the buffer length. This results in different error codes in the 2 modes. The sanity check of IOVEC in incoming sizes is needed and I less inclined to remove it or enhance it. The error code certainly seems to be one way to resolve this problem. The other option is to make the IPC mode IOVEC less aggressive in optimizing away zero buffers from IOVEC (Need more investigation) thus attaining parity with library mode. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby Mathew via TF-M Sent: 12 October 2020 11:50 To: Raymond Ngun <Raymond.Ngun(a)cypress.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Behavior difference in Crypto IPC vs Library modes Hi Raymond Thanks for the detailed report. This issue was reported here https://developer.trustedfirmware.org/T822 previously but I didn't get time to look into it further due to other priorities. Your analysis seems right and I will look further into this. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Raymond Ngun via TF-M Sent: 10 October 2020 00:59 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Behavior difference in Crypto IPC vs Library modes Hi all, I'm seeking some assistance in determining the correct fix for a difference in behavior between IPC and Library modes that cause the Crypto PSA Arch Tests to fail when using IPC. Specifically, I've been testing on a PSoC64 for IPC mode and Musca-B1 for Library mode. The problem I am encountering is related to this check in crypto (e.g. crypto_aead.c in secure_fw/partitions/crypto). if ( !((in_len == 2) || (in_len == 3)) || (out_len > 1)) { return PSA_ERROR_CONNECTION_REFUSED; } This is true for direct function call since in_len and out_len are sizes of in_vec[] and out_vec[]. However, in library mode, in_len and out_len is not based on the size of in_vec[] and out_vec[] but based on the contents. Specifically, out_len is determined via the following in tfm_crypto_call_sfn(). /* Check the number of out_vec filled */ while ((out_len > 0) && (msg->out_size[out_len - 1] == 0)) { out_len--; } >From the above, if out_size (which is passed in by the user) is 0, the resultant out_len will be 0. The out_len is passed into the crypto function and PSA_ERROR_CONNECTION_REFUSED is returned due to the check above. PSA, on the other hand, expects PSA_ERROR_NOT_SUPPORTED to be returned. Btw, in_len suffers from the same issue. I'm not sure if the check above is valid for IPC mode. I've removed the check temporarily to avoid the problem. However, if the check still makes sense, possibly it should return PSA_ERROR_NOT_SUPPORTED instead of PSA_ERROR_CONNECTION_REFUSED. Thank you. I look forward to comments. Ray This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years

2
2
0 0

Re: [TF-M] TF-M Technical Forum call - October 15

by Anton Komlev

Hello, The agenda for the forum: 1. Interrupt handling in PSA FF-M v1.1 2. Ongoing open issues, discussed on the Forum 3. AOB See you, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 09 October 2020 11:11 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - October 15 Hello, The next Technical Forum is planned on Thursday, October 15 at 6:00-07: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

5 years

1
0
0 0

Re: [TF-M] Following the TF-M build example

by Kevin.Kilzer＠microchip.com

Hi, Raef, I can get past the CMSIS issue by dup'ing the GNU links. It now fails for lack of the correct Python. Using the -G option, CMakeCache.txt lists all the pythons in my system and the build completes: $ grep python cmake_build/CMakeCache.txt PYTHON_EXECUTABLE:FILEPATH=C:/Python/Python27/python.exe FIND_PACKAGE_MESSAGE_DETAILS_Python3:INTERNAL=[C:/Users/cXXXXX/AppData/Local/Programs/Python/Python38-32/python.exe][cfound components: Interpreter ][v3.8.5()] _Python3_EXECUTABLE:INTERNAL=C:/Users/cXXXXX/AppData/Local/Programs/Python/Python38-32/python.exe Without the -G option, the compiler is MSVC, and the cache has no entry for python at all. Building Custom Rule C:/Users/cXXXXX/Git/arm/TF-M/trusted-firmware-m/cmake_build/lib/ext/mcuboot-subbuild/CMakeLists.txt Building Custom Rule C:/Users/cXXXXX/Git/arm/TF-M/trusted-firmware-m/cmake_build/lib/ext/mcuboot-subbuild/CMakeLists.txt -- Could NOT find Python3 (missing: Python3_EXECUTABLE Interpreter) Reason given by package: Interpreter: Wrong major version for the interpreter "C:/Python/Python27/python.exe"

5 years

1
0
0 0

Re: [TF-M] Following the TF-M build example

by Kevin.Kilzer＠microchip.com

Hi, Raef, The combination that worked was the most-recent commit and gnu tools (-G option). Using VS it fails at lib/ext/CMSIS_5/CMakeLists.txt:25 for lack of CMSIS RTX static libraries. ...this command worked.... $ cmake -S . -B cmake_build -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -G"Unix Makefiles" -- The C compiler identification is GNU 9.3.1 -- The ASM compiler identification is GNU -- Found assembler: C:/Program Files (x86)/GNU Arm Embedded Toolchain/9 2020-q2-update/bin/arm-none-eabi-gcc.exe -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: C:/Program Files (x86)/GNU Arm Embedded Toolchain/9 2020-q2-update/bin/arm-none-eabi-gcc.exe - skipped -- Detecting C compile features -- Detecting C compile features - done

5 years

1
0
0 0

Re: [TF-M] Following the TF-M build example

by Raef Coles

Thanks. I'm interested if you've managed to build TFM using the visual studio generator? That check was actually added because we had a problem with at least one of the visual studio generators (VS10) setting the C compiler to `MSVC`. If you've managed to get it to build with VS16, then we can look in to adding that as a known good generator. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Kevin Kilzer via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 13 October 2020 15:30 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Following the TF-M build example Hi, Raef, I added to the generator qualifier in CMakeLists.txt line 17. Since cmake is not my native language, I put in the full string, as you see. The string comes from the display of CMAKE_GENERATOR in the error message. if(NOT ${CMAKE_GENERATOR} STREQUAL "Unix Makefiles" AND NOT ${CMAKE_GENERATOR} STREQUAL "Visual Studio 16 2019" AND NOT ${CMAKE_GENERATOR} STREQUAL "Ninja") Message(FATAL_ERROR "Unsupported generator ${CMAKE_GENERATOR}. Hint: Try -G\"Unix Makefiles\"") endif()

5 years

1
0
0 0

Re: [TF-M] Following the TF-M build example

by Kevin.Kilzer＠microchip.com

Hi, I successfully built the project using commit a2ac1f92bae51941e527f5b57c9474819e2c9ca0. Thank you to all who helped. Kevin

5 years

1
0
0 0

Re: [TF-M] Following the TF-M build example

by Kevin.Kilzer＠microchip.com

Hi, Raef, I added to the generator qualifier in CMakeLists.txt line 17. Since cmake is not my native language, I put in the full string, as you see. The string comes from the display of CMAKE_GENERATOR in the error message. if(NOT ${CMAKE_GENERATOR} STREQUAL "Unix Makefiles" AND NOT ${CMAKE_GENERATOR} STREQUAL "Visual Studio 16 2019" AND NOT ${CMAKE_GENERATOR} STREQUAL "Ninja") Message(FATAL_ERROR "Unsupported generator ${CMAKE_GENERATOR}. Hint: Try -G\"Unix Makefiles\"") endif()

5 years

1
0
0 0

Re: [TF-M] Following the TF-M build example

by Raef Coles

Note that the aforementioned patch has now been merged - windows build should now be working again on master Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Raef Coles via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 13 October 2020 10:24 To: tf-m(a)lists.trustedfirmware.org; Kevin.Kilzer(a)microchip.com Subject: Re: [TF-M] Following the TF-M build example Hi, I'm interested in the changes that you made to the validity checks, would you mind sending a patch / outlining what you had to change. The windows generator checks are still not working exactly as they should and I'd like to know what your experience was. For the build failure, I believe this might be related to an issue with the windows PSA file generation. We've got a patch in review for this at https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6386, can you test and see if that fixes the problem. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Kevin Kilzer via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 13 October 2020 00:20 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Following the TF-M build example Thanks for the notes. Since last week I’ve now: 1. downloaded today’s latest repo (12 October, commit 8bebd05745a8b27dccc6403f0215fa6e39de3bc1, and 2. added the VS compiler to the “valid” checks at CmakeLists.txt line 17. Using the -G option allows the make to complete (apparently), but the install script fails (in both GitBash and CMD). Thanks for any help. ========== -- Build files have been written to: C:/Users/cXXXXX/Git/arm/TF-M/trusted-firmware-m/cmake_build cXXXXX@LT-cXXXXXA MINGW64 ~/Git/arm/TF-M/trusted-firmware-m (master) $ cmake --build cmake_build -- install tools/CMakeFiles/tfm_generated_files.dir/build.make:93: *** target pattern contains no '%'. Stop. CMakeFiles/Makefile2:944: recipe for target 'tools/CMakeFiles/tfm_generated_files.dir/all' failed make.exe[1]: *** [tools/CMakeFiles/tfm_generated_files.dir/all] Error 2 Makefile:148: recipe for target 'all' failed make.exe: *** [all] Error 2========== -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years

1
0
0 0

Re: [TF-M] Following the TF-M build example

by Raef Coles

Hi, I'm interested in the changes that you made to the validity checks, would you mind sending a patch / outlining what you had to change. The windows generator checks are still not working exactly as they should and I'd like to know what your experience was. For the build failure, I believe this might be related to an issue with the windows PSA file generation. We've got a patch in review for this at https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6386, can you test and see if that fixes the problem. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Kevin Kilzer via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 13 October 2020 00:20 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Following the TF-M build example Thanks for the notes. Since last week I’ve now: 1. downloaded today’s latest repo (12 October, commit 8bebd05745a8b27dccc6403f0215fa6e39de3bc1, and 2. added the VS compiler to the “valid” checks at CmakeLists.txt line 17. Using the -G option allows the make to complete (apparently), but the install script fails (in both GitBash and CMD). Thanks for any help. ========== -- Build files have been written to: C:/Users/cXXXXX/Git/arm/TF-M/trusted-firmware-m/cmake_build cXXXXX@LT-cXXXXXA MINGW64 ~/Git/arm/TF-M/trusted-firmware-m (master) $ cmake --build cmake_build -- install tools/CMakeFiles/tfm_generated_files.dir/build.make:93: *** target pattern contains no '%'. Stop. CMakeFiles/Makefile2:944: recipe for target 'tools/CMakeFiles/tfm_generated_files.dir/all' failed make.exe[1]: *** [tools/CMakeFiles/tfm_generated_files.dir/all] Error 2 Makefile:148: recipe for target 'all' failed make.exe: *** [all] Error 2==========

5 years

1
0
0 0

Suggestion: external dependency enhancement

by Gyorgy Szing

Hi, While digging the clean issue brought up by Soby, I started wondering if external dependency handling would be better in a slightly different way. There is a lot of hack in the build system around including the psa-arch test project, mostly to work around cmake limitations on namespaces and symbol separation. A stronger barrier could eliminate the mess. In TS we use the following pattern (let's call it "Internal Project"): * External dependencies are fetched with fetch_content() * Right after the fetch, execute_process() is called to start the build of the component. So external component builds configuration time. * The project get's installed into a directory and the main project is using the installed content, possibly through find_package(). * Benefits: * This gives a stronger separation, elimination any name clash between the main project and the external dependency. Also global settings cannot collide like when a dependency sets CMAKE_BUILD_TYPE. * Faster main project build times, as external projects are only built once. * Makes it more "natural" to use an externally built binary for an external component. This might be handy from QA perspective if binary releases are going to happen. (If ever of course.) * Strong separation could allow using different version of the same tools for components. (i.e. main project is built with GCC, component with IAR.) * Drawbacks: * It is harder to develop the external component together with tf-m s tracking changes is more difficult. Might be a problem if debugging tf-m vs external component interaction. This should be rare and might be an acceptable issue. * It is unnatural to run builds configuration time in cmake world. * Configuration phase will take longer. * Since the build happens right where the external component is added (point A), cmake execution flow might need to be different to ensure all information needed to configure the external component is present at point A. * Since external component is built by a separated cmake run, tool detection happens separate. This means the same tools will be searched for multiple times. Initial cache files can be a workaround. This is very similar to how external projects work in cmake, but makes better integration possible. The main project can use information from the dependency as it's source and output files become available configuration time. In turn external project changes are harder to track. /George

5 years

1
0
0 0

Re: [TF-M] New TF-M Build doesn't track config changes

by Gyorgy Szing

Hi, I tried to dig deeper into this, but the cmake command used by Soby fails for me. " [ 33%] Performing patch step for 'psa_arch_tests-populate' error: patch failed: api-tests/platform/targets/tgt_dev_apis_tfm_an521/nspe/pal_driver_intf.c:128 ... " It would be nice to understand why cmake fails to clean properly, but well, I cannot deep-dive due to the above. What I wanted to check is if https://cmake.org/cmake/help/v3.15/prop_tgt/ADDITIONAL_CLEAN_FILES.html could be used to get "make clean" remove the psa-arch test binary directory. But: * I am not sure which build directory is used. I have the feeling we use ${CMAKE_CURRENT_BINARY_DIR}/psa_api_tests and not psa_arch_tests_BINARY_DIR, which would be build\lib\ext\psa_arch_tests-build. Strange. * ADDITIONAL_CLEAN_FILES was introduced in cmake v3.15 and if my memories are correct tf-m allows an older version if not using IAR. Soby: can you please test if ADDITIONAL_CLEAN_FILES works? This solution would give a more streamlined. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 12 October 2020 23:00 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] New TF-M Build doesn't track config changes Hi, Thanks Soby for sorting it out. Sounds like a right way to go and cleanall shall do that job. For me it looks like an exceptional case while the main scenario for a daily development shall be the one, described by Karl : downloaded dependencies explicitly specified by paths outside of TF-M tree via command line, or via project config file (suggested). And true, both cases shall be explicitly documented. Hope it helps, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Soby Mathew via TF-M Sent: 12 October 2020 17:29 To: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] New TF-M Build doesn't track config changes Thanks Karl, Gyorgy for your inputs. I agree with the principle that `BUILD` shall be only folder the cmake modifies. The trouble is, after a `make clean`, there are still artefacts from the previous configuration which affects the new build and gives the wrong output. Hence the suggestion to introduce a `cleanall` custom target which endeavours to clean the all the remnant config information from previous build and leave auto cloned dependant repositories untouched (or maybe print some status info). Does that sound like a good plan then ? Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: 12 October 2020 06:29 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] New TF-M Build doesn't track config changes Hi, I think the build directory is owned by cmake and the same rules shall apply to all files there. Also the only directory cmake does modify without the users consent shall be the build directory. As long as cmake is owning the external dependencies it is the responsibility of the build system to keep the dependencies in a healthy state and to ensure the correct version is built. To do this safely the "clean" operation, which is used to get out of a "non-operational" state, shall fix the dependencies too. So the correct operation (in my opinion) is to make the dependency download work in the following way: * If the dependency is already present at the target location, cmake shall use it as is. Possibly some status information should be printed (i.e. version number, if the git working copy is dirty etc...) * If not cmake shall do the fetch. This way if the user specify an external location (one not in the build directory), cmake will "export" the dependency when the first fetch is done, and do no modifications after. This gives us a well-defined act of handing over the responsibility of keeping the dependency clean. As far as I can see (was not digging into the details) this more or less matches how the current implementation works, and what is missing is more details in the documentation. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Karl Zhang via TF-M Sent: 10 October 2020 08:14 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] New TF-M Build doesn't track config changes Hi Soby, I met the same problem before, and I think your suggestions are helpful. There might be more check needed if the 'make clean' does not delete the auto cloned repos. Because the dependencies may update by a new TFM commit. The new build system supports to specify the patch of each dependency, which can avoid clone automatically to the build folder each time. Hope it can mitigate the inconvenient scenario. -DMBEDCRYPTO_PATH= -DTFM_TEST_REPO_PATH= -DMCUBOOT_PATH= -DPSA_ARCH_TESTS_PATH= There is an example from CI for build command: https://ci.trustedfirmware.org/view/TF-M/job/tf-m-build-config/lastStableBu… cmake -DTFM_PLATFORM=mps2/an519 -DCMAKE_TOOLCHAIN_FILE=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/toolchain_GNUARM.cmake -DTFM_PSA_API=True -DTFM_ISOLATION_LEVEL=1 -DTEST_NS=False -DTEST_S=False -DTEST_PSA_API=OFF -DCMAKE_BUILD_TYPE=Debug -DCRYPTO_HW_ACCELERATOR_OTP_STATE=False -DBL2=False -DNS=False -DTFM_TEST_REPO_PATH=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/../tf-m-tests -DMBEDCRYPTO_PATH=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/../mbedtls -DPSA_ARCH_TESTS_PATH=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/../psa-arch-tests -DMCUBOOT_PATH=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/../mcuboot -DTFM_PROFILE= /home/buildslave/workspace/tf-m-build-config/trusted-firmware-m BR Karl ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Soby Mathew via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Friday, October 2, 2020 8:40 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <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] New TF-M Build doesn't track config changes Hi, With the new build system, TF-M downloads all dependant repositories to the BUILD folder as part of CMAKE configuration. CMake does provide `make clean` target to clean the build and rebuild but this doesn't track any config changes between the builds. Previously, the CMake workflow was to delete all contents in the BUILD folder before re-configuring for a new build but now this means the developer has to re-download all the dependant git repositories before the project can be build again. This can be a slow and cumbersome process for developers. Deleting the CMakecache.txt doesn't seem to solve the problem either. The most obvious solution is to move the cloned repositories outside the BUILD/ folder , so we can follow the previous workflow of deleting the BUILD folder before re-build. The sample test sequence to reproduce the problem is given below: /* Build secure regressions test suite */ $ make clean; cmake .. -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DTEST_S=ON -DCMAKE_BUILD_TYPE=Debug; make install /* reconfigure and build PSA Crypto API test suite */ $ make clean; cmake .. -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Debug -DTEST_PSA_API=CRYPTO; make install Built binary is still for regression test suite. There are multiple suggestions to solve the problem, One is to move the clone repositories outside the BUILD/ folder, or introduce a build target like `make cleanall` which does the equivalent of rm -rf !(lib) within the BUILD folder (i.e the build target will remove all folders except the lib folder which has the cloned repositories). Please let us know of your suggestions on this. Best Regards Soby Mathew

5 years

1
0
0 0

Re: [TF-M] Following the TF-M build example

by Kevin.Kilzer＠microchip.com

Thanks for the notes. Since last week I've now: 1. downloaded today's latest repo (12 October, commit 8bebd05745a8b27dccc6403f0215fa6e39de3bc1, and 2. added the VS compiler to the "valid" checks at CmakeLists.txt line 17. Using the -G option allows the make to complete (apparently), but the install script fails (in both GitBash and CMD). Thanks for any help. ========== -- Build files have been written to: C:/Users/cXXXXX/Git/arm/TF-M/trusted-firmware-m/cmake_build cXXXXX@LT-cXXXXXA MINGW64 ~/Git/arm/TF-M/trusted-firmware-m (master) $ cmake --build cmake_build -- install tools/CMakeFiles/tfm_generated_files.dir/build.make:93: *** target pattern contains no '%'. Stop. CMakeFiles/Makefile2:944: recipe for target 'tools/CMakeFiles/tfm_generated_files.dir/all' failed make.exe[1]: *** [tools/CMakeFiles/tfm_generated_files.dir/all] Error 2 Makefile:148: recipe for target 'all' failed make.exe: *** [all] Error 2==========

5 years

1
0
0 0

Re: [TF-M] New TF-M Build doesn't track config changes

by Anton Komlev

Hi, Thanks Soby for sorting it out. Sounds like a right way to go and cleanall shall do that job. For me it looks like an exceptional case while the main scenario for a daily development shall be the one, described by Karl : downloaded dependencies explicitly specified by paths outside of TF-M tree via command line, or via project config file (suggested). And true, both cases shall be explicitly documented. Hope it helps, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby Mathew via TF-M Sent: 12 October 2020 17:29 To: Gyorgy Szing <Gyorgy.Szing(a)arm.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] New TF-M Build doesn't track config changes Thanks Karl, Gyorgy for your inputs. I agree with the principle that `BUILD` shall be only folder the cmake modifies. The trouble is, after a `make clean`, there are still artefacts from the previous configuration which affects the new build and gives the wrong output. Hence the suggestion to introduce a `cleanall` custom target which endeavours to clean the all the remnant config information from previous build and leave auto cloned dependant repositories untouched (or maybe print some status info). Does that sound like a good plan then ? Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: 12 October 2020 06:29 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] New TF-M Build doesn't track config changes Hi, I think the build directory is owned by cmake and the same rules shall apply to all files there. Also the only directory cmake does modify without the users consent shall be the build directory. As long as cmake is owning the external dependencies it is the responsibility of the build system to keep the dependencies in a healthy state and to ensure the correct version is built. To do this safely the "clean" operation, which is used to get out of a "non-operational" state, shall fix the dependencies too. So the correct operation (in my opinion) is to make the dependency download work in the following way: * If the dependency is already present at the target location, cmake shall use it as is. Possibly some status information should be printed (i.e. version number, if the git working copy is dirty etc...) * If not cmake shall do the fetch. This way if the user specify an external location (one not in the build directory), cmake will "export" the dependency when the first fetch is done, and do no modifications after. This gives us a well-defined act of handing over the responsibility of keeping the dependency clean. As far as I can see (was not digging into the details) this more or less matches how the current implementation works, and what is missing is more details in the documentation. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Karl Zhang via TF-M Sent: 10 October 2020 08:14 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] New TF-M Build doesn't track config changes Hi Soby, I met the same problem before, and I think your suggestions are helpful. There might be more check needed if the 'make clean' does not delete the auto cloned repos. Because the dependencies may update by a new TFM commit. The new build system supports to specify the patch of each dependency, which can avoid clone automatically to the build folder each time. Hope it can mitigate the inconvenient scenario. -DMBEDCRYPTO_PATH= -DTFM_TEST_REPO_PATH= -DMCUBOOT_PATH= -DPSA_ARCH_TESTS_PATH= There is an example from CI for build command: https://ci.trustedfirmware.org/view/TF-M/job/tf-m-build-config/lastStableBu… cmake -DTFM_PLATFORM=mps2/an519 -DCMAKE_TOOLCHAIN_FILE=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/toolchain_GNUARM.cmake -DTFM_PSA_API=True -DTFM_ISOLATION_LEVEL=1 -DTEST_NS=False -DTEST_S=False -DTEST_PSA_API=OFF -DCMAKE_BUILD_TYPE=Debug -DCRYPTO_HW_ACCELERATOR_OTP_STATE=False -DBL2=False -DNS=False -DTFM_TEST_REPO_PATH=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/../tf-m-tests -DMBEDCRYPTO_PATH=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/../mbedtls -DPSA_ARCH_TESTS_PATH=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/../psa-arch-tests -DMCUBOOT_PATH=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/../mcuboot -DTFM_PROFILE= /home/buildslave/workspace/tf-m-build-config/trusted-firmware-m BR Karl ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Soby Mathew via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Friday, October 2, 2020 8:40 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <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] New TF-M Build doesn't track config changes Hi, With the new build system, TF-M downloads all dependant repositories to the BUILD folder as part of CMAKE configuration. CMake does provide `make clean` target to clean the build and rebuild but this doesn't track any config changes between the builds. Previously, the CMake workflow was to delete all contents in the BUILD folder before re-configuring for a new build but now this means the developer has to re-download all the dependant git repositories before the project can be build again. This can be a slow and cumbersome process for developers. Deleting the CMakecache.txt doesn't seem to solve the problem either. The most obvious solution is to move the cloned repositories outside the BUILD/ folder , so we can follow the previous workflow of deleting the BUILD folder before re-build. The sample test sequence to reproduce the problem is given below: /* Build secure regressions test suite */ $ make clean; cmake .. -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DTEST_S=ON -DCMAKE_BUILD_TYPE=Debug; make install /* reconfigure and build PSA Crypto API test suite */ $ make clean; cmake .. -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Debug -DTEST_PSA_API=CRYPTO; make install Built binary is still for regression test suite. There are multiple suggestions to solve the problem, One is to move the clone repositories outside the BUILD/ folder, or introduce a build target like `make cleanall` which does the equivalent of rm -rf !(lib) within the BUILD folder (i.e the build target will remove all folders except the lib folder which has the cloned repositories). Please let us know of your suggestions on this. Best Regards Soby Mathew

5 years

1
0
0 0

Re: [TF-M] Following the TF-M build example

by Kevin.Kilzer＠microchip.com

Hi, Raef, I'm using commit 1cc7566275e8b046d5158d6e067d0fadf33bcd73. Thanks! Kevin

5 years

1
0
0 0

Re: [TF-M] New TF-M Build doesn't track config changes

by Soby Mathew

Thanks Karl, Gyorgy for your inputs. I agree with the principle that `BUILD` shall be only folder the cmake modifies. The trouble is, after a `make clean`, there are still artefacts from the previous configuration which affects the new build and gives the wrong output. Hence the suggestion to introduce a `cleanall` custom target which endeavours to clean the all the remnant config information from previous build and leave auto cloned dependant repositories untouched (or maybe print some status info). Does that sound like a good plan then ? Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: 12 October 2020 06:29 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] New TF-M Build doesn't track config changes Hi, I think the build directory is owned by cmake and the same rules shall apply to all files there. Also the only directory cmake does modify without the users consent shall be the build directory. As long as cmake is owning the external dependencies it is the responsibility of the build system to keep the dependencies in a healthy state and to ensure the correct version is built. To do this safely the "clean" operation, which is used to get out of a "non-operational" state, shall fix the dependencies too. So the correct operation (in my opinion) is to make the dependency download work in the following way: * If the dependency is already present at the target location, cmake shall use it as is. Possibly some status information should be printed (i.e. version number, if the git working copy is dirty etc...) * If not cmake shall do the fetch. This way if the user specify an external location (one not in the build directory), cmake will "export" the dependency when the first fetch is done, and do no modifications after. This gives us a well-defined act of handing over the responsibility of keeping the dependency clean. As far as I can see (was not digging into the details) this more or less matches how the current implementation works, and what is missing is more details in the documentation. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Karl Zhang via TF-M Sent: 10 October 2020 08:14 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] New TF-M Build doesn't track config changes Hi Soby, I met the same problem before, and I think your suggestions are helpful. There might be more check needed if the 'make clean' does not delete the auto cloned repos. Because the dependencies may update by a new TFM commit. The new build system supports to specify the patch of each dependency, which can avoid clone automatically to the build folder each time. Hope it can mitigate the inconvenient scenario. -DMBEDCRYPTO_PATH= -DTFM_TEST_REPO_PATH= -DMCUBOOT_PATH= -DPSA_ARCH_TESTS_PATH= There is an example from CI for build command: https://ci.trustedfirmware.org/view/TF-M/job/tf-m-build-config/lastStableBu… cmake -DTFM_PLATFORM=mps2/an519 -DCMAKE_TOOLCHAIN_FILE=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/toolchain_GNUARM.cmake -DTFM_PSA_API=True -DTFM_ISOLATION_LEVEL=1 -DTEST_NS=False -DTEST_S=False -DTEST_PSA_API=OFF -DCMAKE_BUILD_TYPE=Debug -DCRYPTO_HW_ACCELERATOR_OTP_STATE=False -DBL2=False -DNS=False -DTFM_TEST_REPO_PATH=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/../tf-m-tests -DMBEDCRYPTO_PATH=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/../mbedtls -DPSA_ARCH_TESTS_PATH=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/../psa-arch-tests -DMCUBOOT_PATH=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/../mcuboot -DTFM_PROFILE= /home/buildslave/workspace/tf-m-build-config/trusted-firmware-m BR Karl ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Soby Mathew via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Friday, October 2, 2020 8:40 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <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] New TF-M Build doesn't track config changes Hi, With the new build system, TF-M downloads all dependant repositories to the BUILD folder as part of CMAKE configuration. CMake does provide `make clean` target to clean the build and rebuild but this doesn't track any config changes between the builds. Previously, the CMake workflow was to delete all contents in the BUILD folder before re-configuring for a new build but now this means the developer has to re-download all the dependant git repositories before the project can be build again. This can be a slow and cumbersome process for developers. Deleting the CMakecache.txt doesn't seem to solve the problem either. The most obvious solution is to move the cloned repositories outside the BUILD/ folder , so we can follow the previous workflow of deleting the BUILD folder before re-build. The sample test sequence to reproduce the problem is given below: /* Build secure regressions test suite */ $ make clean; cmake .. -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DTEST_S=ON -DCMAKE_BUILD_TYPE=Debug; make install /* reconfigure and build PSA Crypto API test suite */ $ make clean; cmake .. -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Debug -DTEST_PSA_API=CRYPTO; make install Built binary is still for regression test suite. There are multiple suggestions to solve the problem, One is to move the clone repositories outside the BUILD/ folder, or introduce a build target like `make cleanall` which does the equivalent of rm -rf !(lib) within the BUILD folder (i.e the build target will remove all folders except the lib folder which has the cloned repositories). Please let us know of your suggestions on this. Best Regards Soby Mathew

5 years

1
0
0 0

Mbed TLS Virtual Workshop on Nov. 3rd

by Shebu Varghese Kuriakose

Hi All, Trustedfirmware.org community project would like to invite you to the Mbed TLS Virtual Workshop on November 3rd (Tuesday) from 2pm to 6pm GMT. The purpose of the workshop is to bring together the Mbed TLS community including maintainers, contributors and users to discuss * The future direction of the project and * Ways to improve community collaboration The workshop will be hosted in Zoom open to all. The invitation with the zoom link will be send in the Mbed TLS, PSA Crypto* mailing lists in the coming days. Here are some of the proposed agenda topics. Please reply if there is anything else you would like us or you to present during the workshop that will be interesting to the community * Constant-time code * How to be an effective Mbed TLS reviewer * Processes - how does work get scheduled? * Roadmap, Mbed TLS3.0 * PSA Crypto APIs * How Do I contribute my first review. Thanks, Shebu (TrustedFirmware.org Co-Chair, Mbed TLS Technology Manager) * https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls https://lists.trustedfirmware.org/mailman/listinfo/psa-crypto

5 years

1
0
0 0

Re: [TF-M] Behavior difference in Crypto IPC vs Library modes

by Soby Mathew

Hi Raymond Thanks for the detailed report. This issue was reported here https://developer.trustedfirmware.org/T822 previously but I didn't get time to look into it further due to other priorities. Your analysis seems right and I will look further into this. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raymond Ngun via TF-M Sent: 10 October 2020 00:59 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Behavior difference in Crypto IPC vs Library modes Hi all, I'm seeking some assistance in determining the correct fix for a difference in behavior between IPC and Library modes that cause the Crypto PSA Arch Tests to fail when using IPC. Specifically, I've been testing on a PSoC64 for IPC mode and Musca-B1 for Library mode. The problem I am encountering is related to this check in crypto (e.g. crypto_aead.c in secure_fw/partitions/crypto). if ( !((in_len == 2) || (in_len == 3)) || (out_len > 1)) { return PSA_ERROR_CONNECTION_REFUSED; } This is true for direct function call since in_len and out_len are sizes of in_vec[] and out_vec[]. However, in library mode, in_len and out_len is not based on the size of in_vec[] and out_vec[] but based on the contents. Specifically, out_len is determined via the following in tfm_crypto_call_sfn(). /* Check the number of out_vec filled */ while ((out_len > 0) && (msg->out_size[out_len - 1] == 0)) { out_len--; } >From the above, if out_size (which is passed in by the user) is 0, the resultant out_len will be 0. The out_len is passed into the crypto function and PSA_ERROR_CONNECTION_REFUSED is returned due to the check above. PSA, on the other hand, expects PSA_ERROR_NOT_SUPPORTED to be returned. Btw, in_len suffers from the same issue. I'm not sure if the check above is valid for IPC mode. I've removed the check temporarily to avoid the problem. However, if the check still makes sense, possibly it should return PSA_ERROR_NOT_SUPPORTED instead of PSA_ERROR_CONNECTION_REFUSED. Thank you. I look forward to comments. Ray This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years

1
0
0 0

Re: [TF-M] Disabling IRQ test with new build system

by Raef Coles

Hi, There is a patch that should allow better configuration of the IRQ tests / other platform-related tests, as well as clarifying the documentation. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6350 https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/6351 Any reviews would be appreciated Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of David Hu via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 12 October 2020 08:55 To: Christopher Brand; tf-m(a)lists.trustedfirmware.org Cc: nd Subject: Re: [TF-M] Disabling IRQ test with new build system Hi Chris, Thanks a lot for reporting this. It looks like the IRQ test case is enabled on NS side as long as the Platform service is enabled. The IRQ test service in SPE is controlled by `TFM_ENABLE_IRQ_TEST`, which, however, is neither explicitly configured in CMake nor exported for manual configuration. Therefore IRQ test service is not enabled by default. Thus the IRQ test case will hang the execution and configuration of IRQ test in command line won’t take effect. I’ve been looking for the solution. Just need some time to sort out the dependencies of those test control flags in the new build system. 😊 Sorry for any inconvenience. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: Saturday, October 10, 2020 4:32 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Disabling IRQ test with new build system Hi, The IRQ test part of the CORE_TEST is all conditioned on TFM_ENABLE_IRQ_TEST, and docs/reference/services/core_test_services_integration_guide.rst states that “A platform can skip IRQ handling test by setting ``TFM_ENABLE_IRQ_TEST`` to ``OFF`` in its cmake configuration file.”, but doing so doesn’t seem to actually work. I tried a number of options to the cmake command (including -DTFM_ENABLE_IRQ_TES=OFF, -U TFM_ENABLE_IRQ_TEST), too, but I can’t figure out how to avoid that test. Chris Brand Sr Prin Software Engr, MCD: WIRELESS Cypress Semiconductor Corp. An Infineon Technologies Company #320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com> This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years

1
0
0 0

Re: [TF-M] Disabling IRQ test with new build system

by David Hu

Hi Chris, Thanks a lot for reporting this. It looks like the IRQ test case is enabled on NS side as long as the Platform service is enabled. The IRQ test service in SPE is controlled by `TFM_ENABLE_IRQ_TEST`, which, however, is neither explicitly configured in CMake nor exported for manual configuration. Therefore IRQ test service is not enabled by default. Thus the IRQ test case will hang the execution and configuration of IRQ test in command line won’t take effect. I’ve been looking for the solution. Just need some time to sort out the dependencies of those test control flags in the new build system. 😊 Sorry for any inconvenience. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: Saturday, October 10, 2020 4:32 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Disabling IRQ test with new build system Hi, The IRQ test part of the CORE_TEST is all conditioned on TFM_ENABLE_IRQ_TEST, and docs/reference/services/core_test_services_integration_guide.rst states that “A platform can skip IRQ handling test by setting ``TFM_ENABLE_IRQ_TEST`` to ``OFF`` in its cmake configuration file.”, but doing so doesn’t seem to actually work. I tried a number of options to the cmake command (including -DTFM_ENABLE_IRQ_TES=OFF, -U TFM_ENABLE_IRQ_TEST), too, but I can’t figure out how to avoid that test. Chris Brand Sr Prin Software Engr, MCD: WIRELESS Cypress Semiconductor Corp. An Infineon Technologies Company #320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com> This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years

1
0
0 0

Re: [TF-M] New TF-M Build doesn't track config changes

by Gyorgy Szing

Hi, I think the build directory is owned by cmake and the same rules shall apply to all files there. Also the only directory cmake does modify without the users consent shall be the build directory. As long as cmake is owning the external dependencies it is the responsibility of the build system to keep the dependencies in a healthy state and to ensure the correct version is built. To do this safely the "clean" operation, which is used to get out of a "non-operational" state, shall fix the dependencies too. So the correct operation (in my opinion) is to make the dependency download work in the following way: * If the dependency is already present at the target location, cmake shall use it as is. Possibly some status information should be printed (i.e. version number, if the git working copy is dirty etc...) * If not cmake shall do the fetch. This way if the user specify an external location (one not in the build directory), cmake will "export" the dependency when the first fetch is done, and do no modifications after. This gives us a well-defined act of handing over the responsibility of keeping the dependency clean. As far as I can see (was not digging into the details) this more or less matches how the current implementation works, and what is missing is more details in the documentation. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Karl Zhang via TF-M Sent: 10 October 2020 08:14 To: tf-m(a)lists.trustedfirmware.org; Soby Mathew <Soby.Mathew(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] New TF-M Build doesn't track config changes Hi Soby, I met the same problem before, and I think your suggestions are helpful. There might be more check needed if the 'make clean' does not delete the auto cloned repos. Because the dependencies may update by a new TFM commit. The new build system supports to specify the patch of each dependency, which can avoid clone automatically to the build folder each time. Hope it can mitigate the inconvenient scenario. -DMBEDCRYPTO_PATH= -DTFM_TEST_REPO_PATH= -DMCUBOOT_PATH= -DPSA_ARCH_TESTS_PATH= There is an example from CI for build command: https://ci.trustedfirmware.org/view/TF-M/job/tf-m-build-config/lastStableBu… cmake -DTFM_PLATFORM=mps2/an519 -DCMAKE_TOOLCHAIN_FILE=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/toolchain_GNUARM.cmake -DTFM_PSA_API=True -DTFM_ISOLATION_LEVEL=1 -DTEST_NS=False -DTEST_S=False -DTEST_PSA_API=OFF -DCMAKE_BUILD_TYPE=Debug -DCRYPTO_HW_ACCELERATOR_OTP_STATE=False -DBL2=False -DNS=False -DTFM_TEST_REPO_PATH=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/../tf-m-tests -DMBEDCRYPTO_PATH=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/../mbedtls -DPSA_ARCH_TESTS_PATH=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/../psa-arch-tests -DMCUBOOT_PATH=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/../mcuboot -DTFM_PROFILE= /home/buildslave/workspace/tf-m-build-config/trusted-firmware-m BR Karl ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Soby Mathew via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Friday, October 2, 2020 8:40 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <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] New TF-M Build doesn't track config changes Hi, With the new build system, TF-M downloads all dependant repositories to the BUILD folder as part of CMAKE configuration. CMake does provide `make clean` target to clean the build and rebuild but this doesn't track any config changes between the builds. Previously, the CMake workflow was to delete all contents in the BUILD folder before re-configuring for a new build but now this means the developer has to re-download all the dependant git repositories before the project can be build again. This can be a slow and cumbersome process for developers. Deleting the CMakecache.txt doesn't seem to solve the problem either. The most obvious solution is to move the cloned repositories outside the BUILD/ folder , so we can follow the previous workflow of deleting the BUILD folder before re-build. The sample test sequence to reproduce the problem is given below: /* Build secure regressions test suite */ $ make clean; cmake .. -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DTEST_S=ON -DCMAKE_BUILD_TYPE=Debug; make install /* reconfigure and build PSA Crypto API test suite */ $ make clean; cmake .. -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Debug -DTEST_PSA_API=CRYPTO; make install Built binary is still for regression test suite. There are multiple suggestions to solve the problem, One is to move the clone repositories outside the BUILD/ folder, or introduce a build target like `make cleanall` which does the equivalent of rm -rf !(lib) within the BUILD folder (i.e the build target will remove all folders except the lib folder which has the cloned repositories). Please let us know of your suggestions on this. Best Regards Soby Mathew

5 years

1
0
0 0

Re: [TF-M] New TF-M Build doesn't track config changes

by Karl Zhang

Hi Soby, I met the same problem before, and I think your suggestions are helpful. There might be more check needed if the 'make clean' does not delete the auto cloned repos. Because the dependencies may update by a new TFM commit. The new build system supports to specify the patch of each dependency, which can avoid clone automatically to the build folder each time. Hope it can mitigate the inconvenient scenario. -DMBEDCRYPTO_PATH= -DTFM_TEST_REPO_PATH= -DMCUBOOT_PATH= -DPSA_ARCH_TESTS_PATH= There is an example from CI for build command: https://ci.trustedfirmware.org/view/TF-M/job/tf-m-build-config/lastStableBu… cmake -DTFM_PLATFORM=mps2/an519 -DCMAKE_TOOLCHAIN_FILE=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/toolchain_GNUARM.cmake -DTFM_PSA_API=True -DTFM_ISOLATION_LEVEL=1 -DTEST_NS=False -DTEST_S=False -DTEST_PSA_API=OFF -DCMAKE_BUILD_TYPE=Debug -DCRYPTO_HW_ACCELERATOR_OTP_STATE=False -DBL2=False -DNS=False -DTFM_TEST_REPO_PATH=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/../tf-m-tests -DMBEDCRYPTO_PATH=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/../mbedtls -DPSA_ARCH_TESTS_PATH=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/../psa-arch-tests -DMCUBOOT_PATH=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/../mcuboot -DTFM_PROFILE= /home/buildslave/workspace/tf-m-build-config/trusted-firmware-m BR Karl ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Soby Mathew via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Friday, October 2, 2020 8:40 PM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] New TF-M Build doesn't track config changes Hi, With the new build system, TF-M downloads all dependant repositories to the BUILD folder as part of CMAKE configuration. CMake does provide `make clean` target to clean the build and rebuild but this doesn't track any config changes between the builds. Previously, the CMake workflow was to delete all contents in the BUILD folder before re-configuring for a new build but now this means the developer has to re-download all the dependant git repositories before the project can be build again. This can be a slow and cumbersome process for developers. Deleting the CMakecache.txt doesn't seem to solve the problem either. The most obvious solution is to move the cloned repositories outside the BUILD/ folder , so we can follow the previous workflow of deleting the BUILD folder before re-build. The sample test sequence to reproduce the problem is given below: /* Build secure regressions test suite */ $ make clean; cmake .. -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DTEST_S=ON -DCMAKE_BUILD_TYPE=Debug; make install /* reconfigure and build PSA Crypto API test suite */ $ make clean; cmake .. -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Debug -DTEST_PSA_API=CRYPTO; make install Built binary is still for regression test suite. There are multiple suggestions to solve the problem, One is to move the clone repositories outside the BUILD/ folder, or introduce a build target like `make cleanall` which does the equivalent of rm -rf !(lib) within the BUILD folder (i.e the build target will remove all folders except the lib folder which has the cloned repositories). Please let us know of your suggestions on this. Best Regards Soby Mathew

5 years

1
0
0 0

Behavior difference in Crypto IPC vs Library modes

by Raymond Ngun

Hi all, I'm seeking some assistance in determining the correct fix for a difference in behavior between IPC and Library modes that cause the Crypto PSA Arch Tests to fail when using IPC. Specifically, I've been testing on a PSoC64 for IPC mode and Musca-B1 for Library mode. The problem I am encountering is related to this check in crypto (e.g. crypto_aead.c in secure_fw/partitions/crypto). if ( !((in_len == 2) || (in_len == 3)) || (out_len > 1)) { return PSA_ERROR_CONNECTION_REFUSED; } This is true for direct function call since in_len and out_len are sizes of in_vec[] and out_vec[]. However, in library mode, in_len and out_len is not based on the size of in_vec[] and out_vec[] but based on the contents. Specifically, out_len is determined via the following in tfm_crypto_call_sfn(). /* Check the number of out_vec filled */ while ((out_len > 0) && (msg->out_size[out_len - 1] == 0)) { out_len--; } >From the above, if out_size (which is passed in by the user) is 0, the resultant out_len will be 0. The out_len is passed into the crypto function and PSA_ERROR_CONNECTION_REFUSED is returned due to the check above. PSA, on the other hand, expects PSA_ERROR_NOT_SUPPORTED to be returned. Btw, in_len suffers from the same issue. I'm not sure if the check above is valid for IPC mode. I've removed the check temporarily to avoid the problem. However, if the check still makes sense, possibly it should return PSA_ERROR_NOT_SUPPORTED instead of PSA_ERROR_CONNECTION_REFUSED. Thank you. I look forward to comments. Ray This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years

1
0
0 0

Disabling IRQ test with new build system

by Christopher Brand

Hi, The IRQ test part of the CORE_TEST is all conditioned on TFM_ENABLE_IRQ_TEST, and docs/reference/services/core_test_services_integration_guide.rst states that "A platform can skip IRQ handling test by setting ``TFM_ENABLE_IRQ_TEST`` to ``OFF`` in its cmake configuration file.", but doing so doesn't seem to actually work. I tried a number of options to the cmake command (including -DTFM_ENABLE_IRQ_TES=OFF, -U TFM_ENABLE_IRQ_TEST), too, but I can't figure out how to avoid that test. Chris Brand Sr Prin Software Engr, MCD: WIRELESS Cypress Semiconductor Corp. An Infineon Technologies Company #320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com> This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years

1
0
0 0

TF-M Technical Forum call - October 15

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, October 15 at 6:00-07: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

5 years

1
0
0 0

Re: [TF-M] Musca-B1 and new build system

by Tamas Ban

Hi Raymond, Could you test this fix, it worked for me: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6274 BR, Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M Sent: 07 October 2020 09:26 To: Raymond Ngun <Raymond.Ngun(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Musca-B1 and new build system Hi Raymond, I propose the following way to debug: * I will build and send you a Musca-B1 image based on current master (fc8d2f7 Build: Remove PSA arch tests patch) for testing on your board. * Please send me both of your images, and if you have the corresponding *.axf files, and if you know the commit-id when they were built. * I would like to test and debug in my environment. * By the way do you have a debugger? Can you identify actually what does return an error during security counter init? BR, Tamas From: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>> Sent: 06 October 2020 23:53 To: Tamas Ban <Tamas.Ban(a)arm.com<mailto:Tamas.Ban@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: Musca-B1 and new build system Hi Tamas, It didn't make a difference. I have an old muscb1 image around and that continues to work fine but the new images do not work. I wrote 2MB of 0xFF btw. Thanks, Ray From: Tamas Ban <Tamas.Ban(a)arm.com<mailto:Tamas.Ban@arm.com>> Sent: Tuesday, October 6, 2020 8:40 AM To: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: Musca-B1 and new build system Hi Raymond, The build command and the hex creation are correct. Could you try to erase the entire eFlash before programming it? It can be done with Keil MDK, or you can create a hex file with srec_cat which only contains 0xFF bytes and program that one to the board. Let me know whether does it solved the issue. Tamas From: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>> Sent: 05 October 2020 23:07 To: Tamas Ban <Tamas.Ban(a)arm.com<mailto:Tamas.Ban@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: Musca-B1 and new build system Thanks Tamas. Unfortunately, this did not work for me. Here is what I did to build. Let me know if I did something wrong. cmake -DTFM_PLATFORM=musca_b1 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Debug -DTEST_NS=ON -DTEST_S=ON ../ cmake --build . --target install srec_cat install/outputs/MUSCA_B1/bl2.bin -Binary -offset 0xA000000 install/outputs/MUSCA_B1/tfm_s_ns_signed.bin -Binary -offset 0xA020000 -o tfm.hex -Intel The resultant output is the following. Entering standby.. [INF] Starting bootloader [ERR] Error while initializing the security counter Thank you, Ray From: Tamas Ban <Tamas.Ban(a)arm.com<mailto:Tamas.Ban@arm.com>> Sent: Thursday, October 1, 2020 3:05 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: Musca-B1 and new build system Hi Raymond, Here is the proposed fix: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6028 Could you verify on your board? Pls use at build -DCMAKE_BUILD_TYPE=Debug for full logging in bootloader. Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Tamas Ban via TF-M Sent: 01 October 2020 10:37 To: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>>; 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] Musca-B1 and new build system Hi Raymond, Thanks for reporting the issue! The observed behaviour has two reason: - In the new build system the default CMAKE_BUILD_TYPE=Release. In this case the logging is disabled in MCUboot to get smaller binary. You can set manualy to Debug in the command line to enable logging from bootloader * This commit 7d591a684b4abb0f61fbba8668dd6ea7b4b68698 introduced a crash in Musca S1/B1. Fix is ongoing. Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Raymond Ngun via TF-M Sent: 30 September 2020 17:44 To: David Hu via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] Musca-B1 and new build system Hi all, I am attempting to build Musca-B1 with the latest in master but I'm not able to get it to run (nothing shows on the UART). At a minimum, the User Guide is out of date in terms of how the final hex is created. So, I have a couple questions. 1. Is the latest tested with Musca-B1? 2. Can I obtain some updated information on how to build and create an image for Musca-B1? Thank you, Ray This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years

2
1
0 0

Re: [TF-M] New build system missing GNUARM_PREFIX support

by Gyorgy Szing

Hi, FIY this variable in the Linux world used to be called "CROSS_COMPILE" and both TF-A and OP-TEE is using the same convention. Would it be possible to align with this and rename the variable? For backwards compatibility it could be possible to use both for a while, and issue a warning when the with a deprecation message when the old one is sued. /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raef Coles via TF-M Sent: 08 October 2020 11:03 To: tf-m(a)lists.trustedfirmware.org; Kumar Gala (kumar.gala(a)linaro.org) <kumar.gala(a)linaro.org> Subject: Re: [TF-M] New build system missing GNUARM_PREFIX support Hi, yes apologies that seems to have been lost. I was doing my best to track changes in the original cmake but it seems this one got missed. Can I ask - for the vendor triplet compilers (arm-etc-eabi-gcc), is it a compiler that the vendor is developing? In the new buildsystem, it might make sense to create a new compiler toolchain file that is almost identical to the GNU one, which would allow the two compilers to diverge slightly (in command-line options etc) if necessary. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Kumar Gala via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 07 October 2020 17:26 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] New build system missing GNUARM_PREFIX support It looks like the GNUARM_PREFIX changes got dropped as part of the new build system. Can someone look at restoring those changes? - k -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years

1
0
0 0

New build system missing GNUARM_PREFIX support

by Kumar Gala

It looks like the GNUARM_PREFIX changes got dropped as part of the new build system. Can someone look at restoring those changes? - k

5 years

1
0
0 0

Re: [TF-M] Musca-B1 and new build system

by Tamas Ban

Hi Raymond, Here is the proposed fix: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6028 Could you verify on your board? Pls use at build -DCMAKE_BUILD_TYPE=Debug for full logging in bootloader. Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M Sent: 01 October 2020 10:37 To: Raymond Ngun <Raymond.Ngun(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Musca-B1 and new build system Hi Raymond, Thanks for reporting the issue! The observed behaviour has two reason: - In the new build system the default CMAKE_BUILD_TYPE=Release. In this case the logging is disabled in MCUboot to get smaller binary. You can set manualy to Debug in the command line to enable logging from bootloader * This commit 7d591a684b4abb0f61fbba8668dd6ea7b4b68698 introduced a crash in Musca S1/B1. Fix is ongoing. Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Raymond Ngun via TF-M Sent: 30 September 2020 17:44 To: David Hu via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] Musca-B1 and new build system Hi all, I am attempting to build Musca-B1 with the latest in master but I'm not able to get it to run (nothing shows on the UART). At a minimum, the User Guide is out of date in terms of how the final hex is created. So, I have a couple questions. 1. Is the latest tested with Musca-B1? 2. Can I obtain some updated information on how to build and create an image for Musca-B1? Thank you, Ray This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years

2
4
0 0

Re: [TF-M] -fshort-wchar

by Soby Mathew

Hi Øyvind Yes, you are right, we don't use wchar_t within TF-M and it does seem a trivial optimization without much benefit for TF-M other than introducing incompatibilities. Could you submit a patch to remove the same from GCC and ARMCLANG ? Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Rønningstad, Øyvind via TF-M Sent: 05 October 2020 09:12 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] -fshort-wchar Hi guys. I'm curious why -fshort-wchar is enabled for ARMCLANG and GNUARM (not IAR, interestingly). This should have little or no impact since wchar_t is so rarely used, and causes incompatibility when I try to link my Zephyr app with TF-M libs. Øyvind

5 years

2
1
0 0

Re: [TF-M] Running Tests on Musca-A

by Tamas Ban

Hi Antonio, Could you try to do a debug build? By default the build type is release and in this case the MCUboot does not log anything. Set '-DCMAKE_BUILD_TYPE=Debug' in the command line when invoking the CMake generation phase. Tamas -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio Ken IANNILLO via TF-M Sent: 05 October 2020 16:13 To: Raef Coles <Raef.Coles(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Running Tests on Musca-A Thank you. However, it seems to flash without problem but after reset I don't get the expected output. The most I can get from the UART is the message "Musca A Firmware Version 3.0" when I power off and on, but none of the logging message expected from tf-m. Am I missing something? -- Antonio Ken Iannillo On 05/10/2020, 15:41, "Raef Coles" <Raef.Coles(a)arm.com> wrote: Apologies for the difficulties that you're having. We've recently done an upgrade to the buildsystem and some of the documentation hasn't been properly updated to reflect the new files. There is a patch in review to rectify this. For now, updated (plaintext) documentation can be found at https://review.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m/…. It should also be updated on the website sometime this week. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Antonio Ken IANNILLO via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 05 October 2020 14:06 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Running Tests on Musca-A Dear all, I’m a researcher exploring TF-M. I have a Musca-A board, and I was able to build it with tests. Now, it seems that the examples running the tests [1] are outdated: I simply do not have the same files. My understanding is that I should merge two files (secure and non-secure) but it is not clear which ones and how the offset are computed. Can somebody help me on this? The output files in the /bin folder are: bl2, tfm_ns, and tfm_s in .axf, .bin, .elf, .hex, .map; tfm_s_ns.bin; and tfm_s_ns_signed.bin. Best, [1] https://ci.trustedfirmware.org/view/TF-M/job/tf-m-build-docs-nightly/lastSt… -- Antonio Ken Iannillo, PhD Research Scientist – SEDAN group SnT – Interdisciplinary Centre for Security, Reliability and Trust UNIVERSITÉ DU LUXEMBOURG CAMPUS KIRCHBERG 29, avenue John F. Kennedy L-1855 Luxembourg Kirchberg T +352 46 66 44 9660 | antonioken.iannillo(a)uni.lu<mailto:antonioken.iannillo@uni.lu> Join the conversation News<https://wwwen.uni.lu/snt/news_events> | Twitter<https://twitter.com/SnT_uni_lu> | Linkedin<https://www.linkedin.com/school/snt-lu/> www.uni.lu/snt<http://www.uni.lu/snt> https://akiannillo.github.io/ P Please consider the environment before printing this e-mail

5 years

2
1
0 0

Re: [TF-M] Running Tests on Musca-A

by Raef Coles

Apologies for the difficulties that you're having. We've recently done an upgrade to the buildsystem and some of the documentation hasn't been properly updated to reflect the new files. There is a patch in review to rectify this. For now, updated (plaintext) documentation can be found at https://review.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m/…. It should also be updated on the website sometime this week. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Antonio Ken IANNILLO via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 05 October 2020 14:06 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Running Tests on Musca-A Dear all, I’m a researcher exploring TF-M. I have a Musca-A board, and I was able to build it with tests. Now, it seems that the examples running the tests [1] are outdated: I simply do not have the same files. My understanding is that I should merge two files (secure and non-secure) but it is not clear which ones and how the offset are computed. Can somebody help me on this? The output files in the /bin folder are: bl2, tfm_ns, and tfm_s in .axf, .bin, .elf, .hex, .map; tfm_s_ns.bin; and tfm_s_ns_signed.bin. Best, [1] https://ci.trustedfirmware.org/view/TF-M/job/tf-m-build-docs-nightly/lastSt… -- Antonio Ken Iannillo, PhD Research Scientist – SEDAN group SnT – Interdisciplinary Centre for Security, Reliability and Trust UNIVERSITÉ DU LUXEMBOURG CAMPUS KIRCHBERG 29, avenue John F. Kennedy L-1855 Luxembourg Kirchberg T +352 46 66 44 9660 | antonioken.iannillo(a)uni.lu<mailto:antonioken.iannillo@uni.lu> Join the conversation News<https://wwwen.uni.lu/snt/news_events> | Twitter<https://twitter.com/SnT_uni_lu> | Linkedin<https://www.linkedin.com/school/snt-lu/> www.uni.lu/snt<http://www.uni.lu/snt> https://akiannillo.github.io/ P Please consider the environment before printing this e-mail

5 years

2
1
0 0

Re: [TF-M] Running Tests on Musca-A

by Minos Galanakis

Hi Antonio, And welcome to the TF-M community. To get a better understanding of your issue it I would like to ask from some further details, such as the HEAD of the TF-M which you are trying to build, as well as the HEAD of the test branche. There has been a large overhaul of several components on the TF-M project, including the build system, so it would be good to have a common point of reference / By examples, do you refer to the official user guide? https://ci.trustedfirmware.org/view/TF-M/job/tf-m-build-docs-nightly/lastSt… For Musca_A you only need the hex file to flash it, which is generated using the srec_cat command mentioned above which utilises the platform specific offsets and merges the signed secure and non-secure binaries with the bootloader. If you are facing any issues flashing the HEX file, make sure that you have an up-to date daplink firmware. https://community.arm.com/developer/tools-software/oss-platforms/w/docs/554… If your output folder contains the HEX file, you can try flashing it by dragging and dropping, and see if it runs the regression tests. Regards, Minos Galanakis ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Antonio Ken IANNILLO via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 05 October 2020 14:06 To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Running Tests on Musca-A Dear all, I’m a researcher exploring TF-M. I have a Musca-A board, and I was able to build it with tests. Now, it seems that the examples running the tests [1] are outdated: I simply do not have the same files. My understanding is that I should merge two files (secure and non-secure) but it is not clear which ones and how the offset are computed. Can somebody help me on this? The output files in the /bin folder are: bl2, tfm_ns, and tfm_s in .axf, .bin, .elf, .hex, .map; tfm_s_ns.bin; and tfm_s_ns_signed.bin. Best, [1] https://ci.trustedfirmware.org/view/TF-M/job/tf-m-build-docs-nightly/lastSt… -- Antonio Ken Iannillo, PhD Research Scientist – SEDAN group SnT – Interdisciplinary Centre for Security, Reliability and Trust UNIVERSITÉ DU LUXEMBOURG CAMPUS KIRCHBERG 29, avenue John F. Kennedy L-1855 Luxembourg Kirchberg T +352 46 66 44 9660 | antonioken.iannillo(a)uni.lu<mailto:antonioken.iannillo@uni.lu> Join the conversation News<https://wwwen.uni.lu/snt/news_events> | Twitter<https://twitter.com/SnT_uni_lu> | Linkedin<https://www.linkedin.com/school/snt-lu/> www.uni.lu/snt<http://www.uni.lu/snt> https://akiannillo.github.io/ P Please consider the environment before printing this e-mail

5 years

1
0
0 0

Running Tests on Musca-A

by Antonio Ken IANNILLO

Dear all, I’m a researcher exploring TF-M. I have a Musca-A board, and I was able to build it with tests. Now, it seems that the examples running the tests [1] are outdated: I simply do not have the same files. My understanding is that I should merge two files (secure and non-secure) but it is not clear which ones and how the offset are computed. Can somebody help me on this? The output files in the /bin folder are: bl2, tfm_ns, and tfm_s in .axf, .bin, .elf, .hex, .map; tfm_s_ns.bin; and tfm_s_ns_signed.bin. Best, [1] https://ci.trustedfirmware.org/view/TF-M/job/tf-m-build-docs-nightly/lastSt… -- Antonio Ken Iannillo, PhD Research Scientist – SEDAN group SnT – Interdisciplinary Centre for Security, Reliability and Trust UNIVERSITÉ DU LUXEMBOURG CAMPUS KIRCHBERG 29, avenue John F. Kennedy L-1855 Luxembourg Kirchberg T +352 46 66 44 9660 | antonioken.iannillo(a)uni.lu Join the conversation News | Twitter | Linkedin www.uni.lu/snt https://akiannillo.github.io/ P Please consider the environment before printing this e-mail

5 years

1
0
0 0

Re: [TF-M] CORE_TEST and the new build system

by Raef Coles

Patches are now up for review. for TF-M: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6095/1 for tf-m-tests: https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/6097 Any comments / reviews would be appreciated Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Raef Coles via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 01 October 2020 10:33 To: tf-m(a)lists.trustedfirmware.org; Christopher Brand Subject: Re: [TF-M] CORE_TEST and the new build system Yes, it seems like the core tests slipped through conversion. I've already had a report of this and got a patch together but it needs some thorough testing since it affects the linking order. I'll notify here once the patch is submitted for review. Should be this morning. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 30 September 2020 23:45 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] CORE_TEST and the new build system It seems that docs/reference/services/core_test_services_integration_guide.rst hasn’t been updated to reflect the new build system (it says to build using ConfigCoreTest.cmake). That config isn’t mentioned in docs/getting_started/tfm_build_instruction.rst. So how do I build the CORE_TEST stuff with the new build system (I’m particularly interested in the IRQ test). Thanks, Chris Brand Sr Prin Software Engr, MCD: WIRELESS Cypress Semiconductor Corp. An Infineon Technologies Company #320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com> This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years

1
0
0 0

-fshort-wchar

by Rønningstad, Øyvind

Hi guys. I'm curious why -fshort-wchar is enabled for ARMCLANG and GNUARM (not IAR, interestingly). This should have little or no impact since wchar_t is so rarely used, and causes incompatibility when I try to link my Zephyr app with TF-M libs. Øyvind

5 years

1
0
0 0

Re: [TF-M] Following the TF-M build example

by Raef Coles

Would it be possible to know what commit hash of TF-M you are currently using Kevin? I had thought there was now some error handling in place for this but it's possible that it doesn't work as it should. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Ken Liu via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 03 October 2020 14:37 To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: Re: [TF-M] Following the TF-M build example Hi, I assume you are building under windows, if that is true, add a -G"Unix Makefiles" in the command line would make it work as a quick fix, since cmake treat the default build system under windows as MSVC. We are trying to create a patch to enhance this part. BR /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Kilzer via TF-M Sent: Saturday, October 3, 2020 8:28 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Following the TF-M build example I’m following the first build example in docs\getting_started\tfm_build_instruction.rst, for the mps2/an521. cmake -S . -B cmake_build -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake Building on Windows with gnu, it progresses pretty far then stops with the error shown below. Any suggestions? Kevin -- Configuring done CMake Error at toolchain_GNUARM.cmake:114 (add_library): No SOURCES given to target: tfm_s_scatter Call Stack (most recent call first): platform/ext/target/mps2/an521/CMakeLists.txt:27 (target_add_scatter_file) CMake Error at toolchain_GNUARM.cmake:114 (add_library): No SOURCES given to target: tfm_ns_scatter Call Stack (most recent call first): platform/ext/target/mps2/an521/CMakeLists.txt:40 (target_add_scatter_file) CMake Error at toolchain_GNUARM.cmake:114 (add_library): No SOURCES given to target: bl2_scatter Call Stack (most recent call first): platform/ext/target/mps2/an521/CMakeLists.txt:63 (target_add_scatter_file) CMake Generate step failed. Build files cannot be regenerated correctly.

5 years

1
0
0 0

Re: [TF-M] Following the TF-M build example

by Ken Liu

Hi, I assume you are building under windows, if that is true, add a -G"Unix Makefiles" in the command line would make it work as a quick fix, since cmake treat the default build system under windows as MSVC. We are trying to create a patch to enhance this part. BR /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Kilzer via TF-M Sent: Saturday, October 3, 2020 8:28 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Following the TF-M build example I'm following the first build example in docs\getting_started\tfm_build_instruction.rst, for the mps2/an521. cmake -S . -B cmake_build -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake Building on Windows with gnu, it progresses pretty far then stops with the error shown below. Any suggestions? Kevin -- Configuring done CMake Error at toolchain_GNUARM.cmake:114 (add_library): No SOURCES given to target: tfm_s_scatter Call Stack (most recent call first): platform/ext/target/mps2/an521/CMakeLists.txt:27 (target_add_scatter_file) CMake Error at toolchain_GNUARM.cmake:114 (add_library): No SOURCES given to target: tfm_ns_scatter Call Stack (most recent call first): platform/ext/target/mps2/an521/CMakeLists.txt:40 (target_add_scatter_file) CMake Error at toolchain_GNUARM.cmake:114 (add_library): No SOURCES given to target: bl2_scatter Call Stack (most recent call first): platform/ext/target/mps2/an521/CMakeLists.txt:63 (target_add_scatter_file) CMake Generate step failed. Build files cannot be regenerated correctly.

5 years

1
0
0 0

Following the TF-M build example

by Kevin.Kilzer＠microchip.com

I'm following the first build example in docs\getting_started\tfm_build_instruction.rst, for the mps2/an521. cmake -S . -B cmake_build -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake Building on Windows with gnu, it progresses pretty far then stops with the error shown below. Any suggestions? Kevin -- Configuring done CMake Error at toolchain_GNUARM.cmake:114 (add_library): No SOURCES given to target: tfm_s_scatter Call Stack (most recent call first): platform/ext/target/mps2/an521/CMakeLists.txt:27 (target_add_scatter_file) CMake Error at toolchain_GNUARM.cmake:114 (add_library): No SOURCES given to target: tfm_ns_scatter Call Stack (most recent call first): platform/ext/target/mps2/an521/CMakeLists.txt:40 (target_add_scatter_file) CMake Error at toolchain_GNUARM.cmake:114 (add_library): No SOURCES given to target: bl2_scatter Call Stack (most recent call first): platform/ext/target/mps2/an521/CMakeLists.txt:63 (target_add_scatter_file) CMake Generate step failed. Build files cannot be regenerated correctly.

5 years, 1 month

1
0
0 0

New TF-M Build doesn't track config changes

by Soby Mathew

Hi, With the new build system, TF-M downloads all dependant repositories to the BUILD folder as part of CMAKE configuration. CMake does provide `make clean` target to clean the build and rebuild but this doesn't track any config changes between the builds. Previously, the CMake workflow was to delete all contents in the BUILD folder before re-configuring for a new build but now this means the developer has to re-download all the dependant git repositories before the project can be build again. This can be a slow and cumbersome process for developers. Deleting the CMakecache.txt doesn't seem to solve the problem either. The most obvious solution is to move the cloned repositories outside the BUILD/ folder , so we can follow the previous workflow of deleting the BUILD folder before re-build. The sample test sequence to reproduce the problem is given below: /* Build secure regressions test suite */ $ make clean; cmake .. -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DTEST_S=ON -DCMAKE_BUILD_TYPE=Debug; make install /* reconfigure and build PSA Crypto API test suite */ $ make clean; cmake .. -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Debug -DTEST_PSA_API=CRYPTO; make install Built binary is still for regression test suite. There are multiple suggestions to solve the problem, One is to move the clone repositories outside the BUILD/ folder, or introduce a build target like `make cleanall` which does the equivalent of rm -rf !(lib) within the BUILD folder (i.e the build target will remove all folders except the lib folder which has the cloned repositories). Please let us know of your suggestions on this. Best Regards Soby Mathew

5 years, 1 month

1
0
0 0

Re: [TF-M] TF-M Technical Forum call – October 1

by Anton Komlev

Hi All, The agenda for the forum today: 1. New build system features, tricks and known issues. See you, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 28 September 2020 11:39 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call – October 1 Hello, The next Technical Forum is planned on Thursday, October 1 at 15:00-16:00 UTC (US 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

5 years, 1 month

1
0
0 0

Re: [TF-M] CORE_TEST and the new build system

by Raef Coles

Yes, it seems like the core tests slipped through conversion. I've already had a report of this and got a patch together but it needs some thorough testing since it affects the linking order. I'll notify here once the patch is submitted for review. Should be this morning. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 30 September 2020 23:45 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] CORE_TEST and the new build system It seems that docs/reference/services/core_test_services_integration_guide.rst hasn’t been updated to reflect the new build system (it says to build using ConfigCoreTest.cmake). That config isn’t mentioned in docs/getting_started/tfm_build_instruction.rst. So how do I build the CORE_TEST stuff with the new build system (I’m particularly interested in the IRQ test). Thanks, Chris Brand Sr Prin Software Engr, MCD: WIRELESS Cypress Semiconductor Corp. An Infineon Technologies Company #320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com> This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years, 1 month

1
0
0 0

Re: [TF-M] Musca-B1 and new build system

by Tamas Ban

Hi Raymond, Thanks for reporting the issue! The observed behaviour has two reason: - In the new build system the default CMAKE_BUILD_TYPE=Release. In this case the logging is disabled in MCUboot to get smaller binary. You can set manualy to Debug in the command line to enable logging from bootloader * This commit 7d591a684b4abb0f61fbba8668dd6ea7b4b68698 introduced a crash in Musca S1/B1. Fix is ongoing. Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raymond Ngun via TF-M Sent: 30 September 2020 17:44 To: David Hu via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Musca-B1 and new build system Hi all, I am attempting to build Musca-B1 with the latest in master but I'm not able to get it to run (nothing shows on the UART). At a minimum, the User Guide is out of date in terms of how the final hex is created. So, I have a couple questions. 1. Is the latest tested with Musca-B1? 2. Can I obtain some updated information on how to build and create an image for Musca-B1? Thank you, Ray This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years, 1 month

1
0
0 0

CORE_TEST and the new build system

by Christopher Brand

It seems that docs/reference/services/core_test_services_integration_guide.rst hasn't been updated to reflect the new build system (it says to build using ConfigCoreTest.cmake). That config isn't mentioned in docs/getting_started/tfm_build_instruction.rst. So how do I build the CORE_TEST stuff with the new build system (I'm particularly interested in the IRQ test). Thanks, Chris Brand Sr Prin Software Engr, MCD: WIRELESS Cypress Semiconductor Corp. An Infineon Technologies Company #320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com> This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years, 1 month

1
0
0 0

Musca-B1 and new build system

by Raymond Ngun

Hi all, I am attempting to build Musca-B1 with the latest in master but I'm not able to get it to run (nothing shows on the UART). At a minimum, the User Guide is out of date in terms of how the final hex is created. So, I have a couple questions. 1. Is the latest tested with Musca-B1? 2. Can I obtain some updated information on how to build and create an image for Musca-B1? Thank you, Ray This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years, 1 month

1
0
0 0

Re: [TF-M] Removal of MCUboot fork from TF-M

by Adrian Shaw

This is excellent work and great news for both projects. Well done. Best, Adrian ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Tamas Ban via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 30 September 2020 11:13 To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] Removal of MCUboot fork from TF-M Hi, In the last few quarter TF-M team have worked on actively to upstream the TF-M related features from the forked MCUboot repo to the original repository. This activity has been finished recently and as a result the MCUboot fork has been removed from TF-M repo. Currently TF-M exclusively relies on MCUboot project as a secure bootloader. From now on all new development will be directly contributed to the upstream repo. List of feature which were upstreamed: * HW rollback protection * HW key integration * Data exchange between MCUboot and runtime firmware * RAM_LOAD boot mode * DIRECT_XIP boot mode BR, Tamas Ban

5 years, 1 month

1
0
0 0

Removal of MCUboot fork from TF-M

by Tamas Ban

Hi, In the last few quarter TF-M team have worked on actively to upstream the TF-M related features from the forked MCUboot repo to the original repository. This activity has been finished recently and as a result the MCUboot fork has been removed from TF-M repo. Currently TF-M exclusively relies on MCUboot project as a secure bootloader. From now on all new development will be directly contributed to the upstream repo. List of feature which were upstreamed: * HW rollback protection * HW key integration * Data exchange between MCUboot and runtime firmware * RAM_LOAD boot mode * DIRECT_XIP boot mode BR, Tamas Ban

5 years, 1 month

1
0
0 0

Using TF-M through ymodem to download tfm_s_enc_sign.bin---------STM32L562

by 徐鹏

Hello Jaouen, I have a development issue when running TFM download process on the STM32L562.Print a error log"[ERR] Image in the secondary slot is not valid!" when download tfm_s_enc_sign.bin.ALL other 3 bin（tfm_s_sign.bin，tfm_ns_sign.bin，tfm_ns_enc_sign.bin） download success. I follow the document UM2671 chapter 11.4 Download a new firmware image. The project is en.stm32cubel5_v1-3-0.zip，file：Projects\STM32L562E-DK\Applications\TFM Steps to reproduce: 1.run Projects\STM32L562E-DK\Applications\TFM\TFM_SBSFU_Boot\MDK-ARM\regression.bat to init device 2.build TFM_SBSFU_Boot application，TFM_Appli secure application，TFM_Appli non-secure application，Build TFM_Loader application 3.run Projects\STM32L562E-DK\Applications\TFM\TFM_SBSFU_Boot\MDK-ARM\TFM_UPDATE.bat to programing into STM32L5 internal and external Flash memory 4.success to run into app 5.press user button (blue) during board reset, the user enters local loader menu. 6.use ymodem to download tfm_s_enc_sign.bin to secure image 7.reset and then print error log "[ERR] Image in the secondary slot is not valid!" Reason： 1.hash verify not pass because after decrypt， the image not same with origin image.log as below： ===================================================== [INF] verify counter 0 1000000 1000000 [INF] counter 0 : ok [INF] hash256 : 54, cc, 2c, 4c, 97, b5, 55, 68, [INF] hash256 buf : cd, 76, a3, a1, cb, 1, 4d, bc, [ERR] Image in the secondary slot is not valid! ====================================================== Does anyone know what I39m doing wrong? Thanks in advance!

5 years, 1 month

1
0
0 0

Re: [TF-M] [RFC] The code review guideline

by Ken Liu

Hi, I would merge this one as it has been put there review for a while, thanks all the reviewers. This would provide a basic shape while we are creating new features, also could be viewed better after rendered. There would be many points can be updated later, let’s try to use it and see how it works – Create issues at https://developer.trustedfirmware.org/ and assign to me if there are, reply here is also workable. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Tuesday, September 1, 2020 9:50 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] The code review guideline Hi, We are creating one document to describe the code review guidelines: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5372 The goal of this document is to introduce the source management level concepts to be followed while reviewing a code – which try to simplify the contribution (but burdens the reviewers? 😉). Difference to the `coding style`: * It focuses more on the source placement, interface definition and including, etc. As this document is keeping evolving in a period, the plan is we merge a simple version as start and adding more contents by new patches, so please give enough comments if you have, and don’t forget the concept: we want to make things rational and simple. Thanks. /Ken

5 years, 1 month

1
0
0 0

TF-M Technical Forum call – October 1

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, October 1 at 15:00-16:00 UTC (US 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

5 years, 1 month

1
0
0 0

Updated invitation: TF-M tech Forum @ Thu 15 Oct 2020 07:00 - 08:00 (BST) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

This event has been changed. Title: TF-M tech Forum About 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: Thu 15 Oct 2020 07:00 – 08:00 United Kingdom Time Calendar: tf-m(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * Don Harbin * tf-m(a)lists.trustedfirmware.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=NWRmOTZydWZobWFnZ3RvM… 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, 1 month

1
0
0 0

Invitation: TF-M tech Forum @ Thu 15 Oct 2020 07:00 - 08:00 (BST) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. Title: TF-M tech Forum About 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: Thu 15 Oct 2020 07:00 – 08:00 United Kingdom Time Calendar: tf-m(a)lists.trustedfirmware.org Who: * Bill Fletcher- organiser * Don Harbin * tf-m(a)lists.trustedfirmware.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=NWRmOTZydWZobWFnZ3RvM… 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, 1 month

1
0
0 0

Cancelled event with note: TF-M Tech Forum @ Thu 15 Oct 2020 16:00 - 17:00 (BST) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

This event has been cancelled with this note: "This will be rescheduled with the time corrected" Title: TF-M Tech Forum About 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: Thu 15 Oct 2020 16:00 – 17:00 United Kingdom Time Calendar: tf-m(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * Don Harbin * tf-m(a)lists.trustedfirmware.org 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, 1 month

1
0
0 0

Invitation: TF-M Tech forum @ Thu 1 Oct 2020 16:00 - 17:00 (BST) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. Title: TF-M Tech forum About 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: Thu 1 Oct 2020 16:00 – 17:00 United Kingdom Time Calendar: tf-m(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * Don Harbin * tf-m(a)lists.trustedfirmware.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=N29mbm1qN2prOXBxMDhpd… 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, 1 month

1
0
0 0

Cancelled event with note: TF-M Tech Forum @ Thu 1 Oct 2020 07:00 - 08:00 (BST) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

This event has been cancelled with this note: "To be rescheduled with the time corrected" Title: TF-M Tech Forum About 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: Thu 1 Oct 2020 07:00 – 08:00 United Kingdom Time Calendar: tf-m(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * Don Harbin * tf-m(a)lists.trustedfirmware.org 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, 1 month

1
0
0 0

Re: [TF-M] X.509 Certificate Chain Support in TF-M

by Ronald Cron

Hi, I haven't dug into the details here but just wanted to point out that there is an x509 library in Mbed TLS. Thanks, Ronald. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Abhishek Pandit via TF-M Sent: 28 September 2020 11:42 To: Soby Mathew <Soby.Mathew(a)arm.com>; David Brown <david.brown(a)linaro.org>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] X.509 Certificate Chain Support in TF-M Adding TF-M mailing list, in case anyone is interested in the topic. -----Original Message----- From: Soby Mathew <Soby.Mathew(a)arm.com> Sent: 24 September 2020 15:02 To: David Brown <david.brown(a)linaro.org> Cc: Abhishek Pandit <Abhishek.Pandit(a)arm.com>; Kevin Townsend <kevin.townsend(a)linaro.org>; Anton Komlev <Anton.Komlev(a)arm.com>; David Wang <David.Wang(a)arm.com>; Tamas Ban <Tamas.Ban(a)arm.com>; Shebu Varghese Kuriakose <Shebu.VargheseKuriakose(a)arm.com>; Adrian Shaw <Adrian.Shaw(a)arm.com> Subject: RE: X.509 Certificate Chain Support in TF-M [+Adrian] Hi David > To me, what might make some sense would be to have some kind of > restrictions on what can be done with the private key stored on the > secure side. If all operations are done through an extended API, > those would be the only operations permissible, whereas a generic > private key storage could allow rogue non-secure code to make use of > signing of other things, including signing non-resident data (one > device using another for attestation. At least the risks and costs of this should be considered. Thanks for the clarification. This would mean that given the current PSA Crypto design, the only way to achieve this would be to implement a custom RoT service in SPE. Hence the NSPE cannot make use of the key for arbitrary signing operation. > My primary concern with this solution at this point, is that we > haven't consider securing the protocol necessary to associate a > certificate/key pair with a particular device. Maybe we should be looking into SDO? Yes, that does seem like a good candidate. From my reading, several aspects of provisioning seem to be outside TF-M realm. > Having roots of trust instead of public keys (or certs) for direct > signing keys would give OEMs and other parties involved in the > firmware upgrade process more flexibility. > I see, thanks. We use certificate chains when firmware images need from different vendors need to be deployed in different privilege levels or multiple boot stages are present in A-profile. The Platform boot guide document https://developer.arm.com/documentation/den0072/0101/ mentions this as well. Possibly this is an enhancement to MCUBoot (Boot loader for TF-M). After talking with Adrian, I think there is consensus that certificate chain is a useful feature to have. So from my point of view, if there is some collaborative effort to develop such a service as TF-M specific extension, I think it would be very useful to the community. Best Regards Soby Mathew > -----Original Message----- > From: David Brown <david.brown(a)linaro.org> > Sent: 23 September 2020 19:12 > To: Soby Mathew <Soby.Mathew(a)arm.com> > Cc: Abhishek Pandit <Abhishek.Pandit(a)arm.com>; Kevin Townsend > <kevin.townsend(a)linaro.org>; Anton Komlev <Anton.Komlev(a)arm.com>; > David Wang <David.Wang(a)arm.com>; Tamas Ban <Tamas.Ban(a)arm.com>; Shebu > Varghese Kuriakose <Shebu.VargheseKuriakose(a)arm.com> > Subject: Re: X.509 Certificate Chain Support in TF-M > > On Wed, Sep 23, 2020 at 04:52:13PM +0000, Soby Mathew wrote: > > > I had a review and thanks for the excellent proposal, and it does > > make sense to me to add this support but some questions from my side: > > > > 1. Do you envisage the new CSR API and ability to store certificate blobs in > > secure world as an extension to PSA Attestation API ? > > 2. I know it is desirable to add this functionality to secure world, but to > > clear my mind, Is it possible to provide the same functionality from Non > > Secure side but making use of PSA crypto APIs ? For example the > > PSA > Crypto > > could export the public key and sign necessary data to create > > the CSR > from > > NS side. Similarly new keys can be imported to Crypto by NS > > world while > the > > certificate chains are maintained in NS world for non IAT services. I may > > have missed some key point. > > I agree that there is little reason to store the certificates > themselves on the secure side. If they were modified or tampered > with, there would no longer be a private key to make use of them. > > > My primary concern with this solution at this point, is that we > haven't consider securing the protocol necessary to associate a > certificate/key pair with a particular device. Maybe we should be looking into SDO? > > > 3. I understood how we can make use of certificate chains for > > attestation, > but > > it is less clear how this can be made use of while booting firmware images. > > Could you elaborate more ? > > Only in the sense of allowing a signed firmware image to have a > certificate chain with it. Having roots of trust instead of public > keys (or certs) for direct signing keys would give OEMs and other > parties involved in the firmware upgrade process more flexibility. > > David -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 1 month

1
0
0 0

Re: [TF-M] X.509 Certificate Chain Support in TF-M

by Abhishek Pandit

Adding TF-M mailing list, in case anyone is interested in the topic. -----Original Message----- From: Soby Mathew <Soby.Mathew(a)arm.com> Sent: 24 September 2020 15:02 To: David Brown <david.brown(a)linaro.org> Cc: Abhishek Pandit <Abhishek.Pandit(a)arm.com>; Kevin Townsend <kevin.townsend(a)linaro.org>; Anton Komlev <Anton.Komlev(a)arm.com>; David Wang <David.Wang(a)arm.com>; Tamas Ban <Tamas.Ban(a)arm.com>; Shebu Varghese Kuriakose <Shebu.VargheseKuriakose(a)arm.com>; Adrian Shaw <Adrian.Shaw(a)arm.com> Subject: RE: X.509 Certificate Chain Support in TF-M [+Adrian] Hi David > To me, what might make some sense would be to have some kind of > restrictions on what can be done with the private key stored on the > secure side. If all operations are done through an extended API, > those would be the only operations permissible, whereas a generic > private key storage could allow rogue non-secure code to make use of > signing of other things, including signing non-resident data (one > device using another for attestation. At least the risks and costs of this should be considered. Thanks for the clarification. This would mean that given the current PSA Crypto design, the only way to achieve this would be to implement a custom RoT service in SPE. Hence the NSPE cannot make use of the key for arbitrary signing operation. > My primary concern with this solution at this point, is that we > haven't consider securing the protocol necessary to associate a > certificate/key pair with a particular device. Maybe we should be looking into SDO? Yes, that does seem like a good candidate. From my reading, several aspects of provisioning seem to be outside TF-M realm. > Having roots of trust instead of public keys (or certs) for direct > signing keys would give OEMs and other parties involved in the > firmware upgrade process more flexibility. > I see, thanks. We use certificate chains when firmware images need from different vendors need to be deployed in different privilege levels or multiple boot stages are present in A-profile. The Platform boot guide document https://developer.arm.com/documentation/den0072/0101/ mentions this as well. Possibly this is an enhancement to MCUBoot (Boot loader for TF-M). After talking with Adrian, I think there is consensus that certificate chain is a useful feature to have. So from my point of view, if there is some collaborative effort to develop such a service as TF-M specific extension, I think it would be very useful to the community. Best Regards Soby Mathew > -----Original Message----- > From: David Brown <david.brown(a)linaro.org> > Sent: 23 September 2020 19:12 > To: Soby Mathew <Soby.Mathew(a)arm.com> > Cc: Abhishek Pandit <Abhishek.Pandit(a)arm.com>; Kevin Townsend > <kevin.townsend(a)linaro.org>; Anton Komlev <Anton.Komlev(a)arm.com>; > David Wang <David.Wang(a)arm.com>; Tamas Ban <Tamas.Ban(a)arm.com>; Shebu > Varghese Kuriakose <Shebu.VargheseKuriakose(a)arm.com> > Subject: Re: X.509 Certificate Chain Support in TF-M > > On Wed, Sep 23, 2020 at 04:52:13PM +0000, Soby Mathew wrote: > > > I had a review and thanks for the excellent proposal, and it does > > make sense to me to add this support but some questions from my side: > > > > 1. Do you envisage the new CSR API and ability to store certificate blobs in > > secure world as an extension to PSA Attestation API ? > > 2. I know it is desirable to add this functionality to secure world, but to > > clear my mind, Is it possible to provide the same functionality from Non > > Secure side but making use of PSA crypto APIs ? For example the > > PSA > Crypto > > could export the public key and sign necessary data to create > > the CSR > from > > NS side. Similarly new keys can be imported to Crypto by NS > > world while > the > > certificate chains are maintained in NS world for non IAT services. I may > > have missed some key point. > > I agree that there is little reason to store the certificates > themselves on the secure side. If they were modified or tampered > with, there would no longer be a private key to make use of them. > > > My primary concern with this solution at this point, is that we > haven't consider securing the protocol necessary to associate a > certificate/key pair with a particular device. Maybe we should be looking into SDO? > > > 3. I understood how we can make use of certificate chains for > > attestation, > but > > it is less clear how this can be made use of while booting firmware images. > > Could you elaborate more ? > > Only in the sense of allowing a signed firmware image to have a > certificate chain with it. Having roots of trust instead of public > keys (or certs) for direct signing keys would give OEMs and other > parties involved in the firmware upgrade process more flexibility. > > David

5 years, 1 month

1
0
0 0

Cypress PSoC64 support update

by Andrei Narkevitch

Hi all, Just to let you know, some time ago Cypress has officially released the PSoC64 platform. With this, we are planning to stop supporting old PSoC64 development kits and move our focus on the new release boards. This is mainly because the old boards were programmed with an old firmware which is not compatible with the changes we do to the TFM code and it would be an unnecessary overhead to support both versions. Please let us know if it causes any issues. The new PSoC64 kit: https://www.cypress.com/documentation/development-kitsboards/psoc-64-standa… Thanks, Andrei Narkevitch Cypress Semiconductor Corp. An Infineon Technologies Company This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years, 1 month

1
0
0 0

Invitation: TF-M Tech Forum @ Thu 1 Oct 2020 07:00 - 08:00 (BST) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. Title: TF-M Tech Forum About 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: Thu 1 Oct 2020 07:00 – 08:00 United Kingdom Time Calendar: tf-m(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * Don Harbin * tf-m(a)lists.trustedfirmware.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=N250M2VrZnZtMnY0MjU3d… 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, 1 month

1
0
0 0

Invitation: TF-M Tech Forum @ Thu 15 Oct 2020 16:00 - 17:00 (BST) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. Title: TF-M Tech Forum About 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: Thu 15 Oct 2020 16:00 – 17:00 United Kingdom Time Calendar: tf-m(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * Don Harbin * tf-m(a)lists.trustedfirmware.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=MjRoajVlNjRuczZqYWIwN… 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, 1 month

1
0
0 0

New buildsystem merged

by Raef Coles

Hi all The new buildsystem has now been merged to both the trusted-firmware-m and tf-m-tests repositories. There are a few known issues: * STM platforms run into issues with flash space when building under debug configuration. * nxp/lpcxpresso66s69 fails regression tests - this is being looked into as a priority. For building with the new buildsystem, there have been some changes to the command-line. An example invocation is shown below. ``` cd <TFM root dir> mkdir build && cd build cmake .. -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake make ``` CMAKE_TOOLCHAIN_FILE and TFM_PLATFORM are the only required arguments. CMAKE_TOOLCHAIN_FILE is conceptually a replacement for COMPILER. It is a path to one of the three toolchain files in the TFM root dir. * <TFM root dir>/toolchain_GNUARM.cmake * <TFM root dir>/toolchain_ARMCLANG.cmake * <TFM root dir>/toolchain_IARARM.cmake TFM_PLATFORM is conceptually a replacement for TARGET_PLATFORM. Unlike TARGET_PLATFORM it takes as an argument the path between `platform/ext/target` and the target dir. For example: * -DTFM_PLATFORM=musca_s1 * -DTFM_PLATFORM=cypress/psoc64 * -DTFM_PLATFORM=nxp/lpcxpresso55s69 PROJ_CONFIG has now been removed. Instead configuration has been simplified using composable variables. Enable regression tests: -DTEST_NS=ON -DTEST_S=ON Enable IPC mode: -DTFM_PSA_API=ON Set isolation level: -DTFM_ISOLATION_LEVEL=2 So instead of ConfigRegressionIPC: -DTEST_NS=ON -DTEST_S=ON -DTFM_PSA_API=ON For integration with other projects, there is a new option: -DNS=[ON/OFF] If NS is set to OFF, TFM will build only the secure image (as bin tfm_s.axf) and the PSA api as a static library. This should make integration with other projects much simpler. Other miscellaneous improvements: * Full ninja support * Automatic dependency management * generation of axf, elf, hex and bin files for all outputs * Full support for partial rebuilding and parallel building * Modular support for crypto accelerators * better integration of multi-core support For full details of buildsystem variable changes, refer to `docs/getting_started/tfm_build_instructions.rst` and `config/config_default.cmake` Raef

5 years, 1 month

1
0
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Ken Liu

Thanks all for the inputs. May I collect answers for these questions: * Does the build system/IDE support sub-project for components and finally assemble them into one final image? The intention is to check the possibility to integrate TFM with sub-projects instead of a whole item. * Is there scenarios that dynamic sections being added into sct/ld, how do you deal with this? A reference link is also helpful. The intention: TF-M is actually a set of components, and the secure firmware part (secure boot is another image binary so not listed here) contains: 1. Libraries. 2. Partitions. 3. SPM. 4. Image assembling with all above components. The straight way is to generate ABC as *.a and assemble them together into a final image. Then go through each component, A and C can be configured in C domain, as what they needs maybe just some feature flags. B is a bit special but we still could provide specification defined .json and its compatible .yaml manifest and pre-generated C-based manifest with preprocessors. D is the hard part, as it needs special arrangement inside ld/sct, which make this discussion happen. Even the ‘include’ and ‘preprocessor’ are supported inside sct/ld, we still can not avoid the partitions including part, we can not do a foreach on the partition list which involve the preprocessor complexity into sct/ld. Looks like the templating can’t be avoided here. For platform specific requirements like: * Some platform won’t separate RODATA and CODE; * Some platform got non-continuous memory regions for special data; Put a platform dedicated sct/ld into the platform folder would help; but to mitigate the effort of platform, a common sct/ld needs to be abstracted. Thanks again for your great feedback. /Ken [History collapsed due to message size limitation]

5 years, 1 month

1
0
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Reed Hinkel

Hello Gyrogy: Your comment raises the question. Why is TF-M so complex and does it need to be the only answer? Either it needs to be simplified or respect must be paid to support in commercial tools as a first class citizen. Commercial tools are the path for large scale product developers. If they can’t engage TF-M with commercial tools or SiP tools then developers will face challenges to develop with it. It there are challenges they may even avoid using it in favor of simplified solutions much as they do today. Multiple target use cases will be using various components of TF-M (MbedTLS with and without hardware interfaces, Attestation, Audit Logs, etc.): 1. Arm v8M – Cortex-M33, M35, M55 2. Dual Core Systems – Multiple possible configs 3. Cortex v6M of v7M – M0, M0+, M3 & M4 4. TF-A 5. Other Cortex-R & Cortex-A implementations This reality argues for a more modular build packaging system that allows for it. All the best! Reed From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Gyorgy Szing via TF-M <tf-m(a)lists.trustedfirmware.org> Reply-To: Gyorgy Szing <Gyorgy.Szing(a)arm.com> Date: Wednesday, September 23, 2020 at 5:04 AM To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Andrej, TF-M relies heavily on compile time configuration, and C is quiet limited on that. This means we cannot rely on the only standardized part of the “ecosystem” solely, and we have to use non-standard tools. I would love to have a portable automation solution supported by most IDEs. Yes, a lot of projects can go well with a single configuration header but unfortunately TF-M is more complex than that: * How could we get information from manifest files to the build? * How could we generate signed binary packages for the boot-loader? * How could we control memory map in sync with the hw configuration in source files? (The current pre-processing linker files approach is already non-standard.) None of these can be solved with IDEs in a portable way. I understand that adding IDE support for TF-M is challenging but the root cause is not how we implemented the build system, but how IDEs can handle the complexity needed by TF-M. /George From: Andrej Butok <andrey.butok(a)nxp.com> Sent: 23 September 2020 09:33 To: Gyorgy Szing <Gyorgy.Szing(a)arm.com>; Ken Liu <Ken.Liu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Ken, So we are using one default/typical configuration. If any change in it, a user have to do changes manually which are not clear without deeper knowledge of the TFM project. But this is the issue of the TF-M chosen approach - fully rely on cmake preprocessing. The proposal is to use approach which is good for all worlds (cmake and IDEs) and which is used by all embedded MCU open-source projects like MbedTLS, FreeRTOS, lwIP, FNET and etc. Which is to have only one set of platform-independent files and the framework configuration from a user/project configuration file. It will work for both worlds, will solve all configuration issues we have, and will make TF-M easy to use and more popular. I am talking about this from very beginning. As no steps in right direction, we have a forked TF-M for our SDK. Thanks George for support ;) Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 23, 2020 8:45 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: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Andrej, Sounds like your IDE is using the default .sct/.ld file, may I ask some a question that: * Is there a scenario that someone wants to add more partitions other than the default ones into your system, and how could they do that? I believe the existing .sct/.ld do not support extra partitions out of the default ones unless some manually modification is done. We need to support more components (partition is the direct example), so in this case, the sct/ld can’t be avoided to be modified. Or do you think if we put a specific .sct/.ld under nxp folder would work if there is no other partitions are needed? Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Wednesday, September 23, 2020 8:46 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: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi, Good point, this is an important factor. I think templating can be IDE compliant as long as the IDE does support pre-build step(s). The current build flow already contains steps requiring this and thus I don’t think situation would be much worse with any mentioned solution than it is today. /George 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: 23 September 2020 08:33 To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Please, do not add changes to sources & linker-files which may harm Non-Cmake systems (IDEs). Thanks, Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 23, 2020 8:05 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: Re: [TF-M] Proposal to separate SCT/LD into each platform folder As cmake is still the build system, let me check the cmake related feature – but need to wait the build system change get merged then we can take a look where to start. BR. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Tuesday, September 22, 2020 4:43 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] Proposal to separate SCT/LD into each platform folder Hi Ken, I think templating is a good approach here, the current C preprocessor based solution is a very limited implementation of this. I see two main contenders for templating: 1. cmake has built in support for templating with the configure_file() [1] command. This would move ownership of this information info the build scripts, which are the focus point for such info already. A cmake based solution would feel more native to the existing system. On the other hand other solutions might have more features, which could lead to easier to read template files. Also cmake as a template engine is not that widely adopted. 2. jinja2 [2]. A widely adopted and more feature rich templating engine. TF-M already uses it for manifest file handling. I suggest using yahsa [3] instead of a custom pyhton script as the cli frontend though. This could speed up development as long as no complex processing is needed and the templates can be filled based on “simple” values. Which of the above is the best for the task depends on template file readability and on complexity of the task. It could be nice if a clean split could be made, and we could stop using the C preprocessor based processing completely. “Not sure if all these format support #include” The build system works around that by implementing a compiler specific cmake function to add the pre-processing step for compilers not supporting pre-processing out of the box. /George [1] https://cmake.org/cmake/help/v3.18/command/configure_file.html<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org…> [2] https://jinja.palletsprojects.com/en/2.11.x/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjinja.pal…> [3] https://github.com/kblomqvist/yasha<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 22 September 2020 10:15 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] Proposal to separate SCT/LD into each platform folder Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 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] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What’s your opinion on this? Best regards, Shawn

5 years, 1 month

2
2
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Soby Mathew

Thanks Gyorgy for your inputs. I haven't checked out the details of all the pre-build processing, but it does seem complex to solve this in a portable way, but one suggestion from me is that perhaps the output from the pre-build processing should be a standard C header and from then on the standardized C pre-processing can be used for the rest of the configuration. For example, instead of the pre-build step generating producing the final linker script , it could instead generate a C header file which then can be consumed by the linker script. Here only the C header is generated and the linker script is untouched. This means that, if the IDEs can find a path to generate this C header file somehow (either via IDE configuration or different custom pre-build processing), then rest of the setup continues in a C standard way. Best regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: 23 September 2020 11:04 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Andrej, TF-M relies heavily on compile time configuration, and C is quiet limited on that. This means we cannot rely on the only standardized part of the "ecosystem" solely, and we have to use non-standard tools. I would love to have a portable automation solution supported by most IDEs. Yes, a lot of projects can go well with a single configuration header but unfortunately TF-M is more complex than that: * How could we get information from manifest files to the build? * How could we generate signed binary packages for the boot-loader? * How could we control memory map in sync with the hw configuration in source files? (The current pre-processing linker files approach is already non-standard.) None of these can be solved with IDEs in a portable way. I understand that adding IDE support for TF-M is challenging but the root cause is not how we implemented the build system, but how IDEs can handle the complexity needed by TF-M. /George From: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>> Sent: 23 September 2020 09:33 To: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>; Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Ken, So we are using one default/typical configuration. If any change in it, a user have to do changes manually which are not clear without deeper knowledge of the TFM project. But this is the issue of the TF-M chosen approach - fully rely on cmake preprocessing. The proposal is to use approach which is good for all worlds (cmake and IDEs) and which is used by all embedded MCU open-source projects like MbedTLS, FreeRTOS, lwIP, FNET and etc. Which is to have only one set of platform-independent files and the framework configuration from a user/project configuration file. It will work for both worlds, will solve all configuration issues we have, and will make TF-M easy to use and more popular. I am talking about this from very beginning. As no steps in right direction, we have a forked TF-M for our SDK. Thanks George for support ;) Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 23, 2020 8:45 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: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Andrej, Sounds like your IDE is using the default .sct/.ld file, may I ask some a question that: * Is there a scenario that someone wants to add more partitions other than the default ones into your system, and how could they do that? I believe the existing .sct/.ld do not support extra partitions out of the default ones unless some manually modification is done. We need to support more components (partition is the direct example), so in this case, the sct/ld can't be avoided to be modified. Or do you think if we put a specific .sct/.ld under nxp folder would work if there is no other partitions are needed? Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Wednesday, September 23, 2020 8:46 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: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi, Good point, this is an important factor. I think templating can be IDE compliant as long as the IDE does support pre-build step(s). The current build flow already contains steps requiring this and thus I don't think situation would be much worse with any mentioned solution than it is today. /George 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: 23 September 2020 08:33 To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Please, do not add changes to sources & linker-files which may harm Non-Cmake systems (IDEs). Thanks, Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 23, 2020 8:05 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: Re: [TF-M] Proposal to separate SCT/LD into each platform folder As cmake is still the build system, let me check the cmake related feature - but need to wait the build system change get merged then we can take a look where to start. BR. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Tuesday, September 22, 2020 4:43 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] Proposal to separate SCT/LD into each platform folder Hi Ken, I think templating is a good approach here, the current C preprocessor based solution is a very limited implementation of this. I see two main contenders for templating: 1. cmake has built in support for templating with the configure_file() [1] command. This would move ownership of this information info the build scripts, which are the focus point for such info already. A cmake based solution would feel more native to the existing system. On the other hand other solutions might have more features, which could lead to easier to read template files. Also cmake as a template engine is not that widely adopted. 2. jinja2 [2]. A widely adopted and more feature rich templating engine. TF-M already uses it for manifest file handling. I suggest using yahsa [3] instead of a custom pyhton script as the cli frontend though. This could speed up development as long as no complex processing is needed and the templates can be filled based on "simple" values. Which of the above is the best for the task depends on template file readability and on complexity of the task. It could be nice if a clean split could be made, and we could stop using the C preprocessor based processing completely. "Not sure if all these format support #include" The build system works around that by implementing a compiler specific cmake function to add the pre-processing step for compilers not supporting pre-processing out of the box. /George [1] https://cmake.org/cmake/help/v3.18/command/configure_file.html<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org…> [2] https://jinja.palletsprojects.com/en/2.11.x/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjinja.pal…> [3] https://github.com/kblomqvist/yasha<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 22 September 2020 10:15 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] Proposal to separate SCT/LD into each platform folder Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 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] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What's your opinion on this? Best regards, Shawn

5 years, 1 month

2
1
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Gyorgy Szing

Hi Andrej, TF-M relies heavily on compile time configuration, and C is quiet limited on that. This means we cannot rely on the only standardized part of the "ecosystem" solely, and we have to use non-standard tools. I would love to have a portable automation solution supported by most IDEs. Yes, a lot of projects can go well with a single configuration header but unfortunately TF-M is more complex than that: * How could we get information from manifest files to the build? * How could we generate signed binary packages for the boot-loader? * How could we control memory map in sync with the hw configuration in source files? (The current pre-processing linker files approach is already non-standard.) None of these can be solved with IDEs in a portable way. I understand that adding IDE support for TF-M is challenging but the root cause is not how we implemented the build system, but how IDEs can handle the complexity needed by TF-M. /George From: Andrej Butok <andrey.butok(a)nxp.com> Sent: 23 September 2020 09:33 To: Gyorgy Szing <Gyorgy.Szing(a)arm.com>; Ken Liu <Ken.Liu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Ken, So we are using one default/typical configuration. If any change in it, a user have to do changes manually which are not clear without deeper knowledge of the TFM project. But this is the issue of the TF-M chosen approach - fully rely on cmake preprocessing. The proposal is to use approach which is good for all worlds (cmake and IDEs) and which is used by all embedded MCU open-source projects like MbedTLS, FreeRTOS, lwIP, FNET and etc. Which is to have only one set of platform-independent files and the framework configuration from a user/project configuration file. It will work for both worlds, will solve all configuration issues we have, and will make TF-M easy to use and more popular. I am talking about this from very beginning. As no steps in right direction, we have a forked TF-M for our SDK. Thanks George for support ;) Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 23, 2020 8:45 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: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Andrej, Sounds like your IDE is using the default .sct/.ld file, may I ask some a question that: * Is there a scenario that someone wants to add more partitions other than the default ones into your system, and how could they do that? I believe the existing .sct/.ld do not support extra partitions out of the default ones unless some manually modification is done. We need to support more components (partition is the direct example), so in this case, the sct/ld can't be avoided to be modified. Or do you think if we put a specific .sct/.ld under nxp folder would work if there is no other partitions are needed? Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Wednesday, September 23, 2020 8:46 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: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi, Good point, this is an important factor. I think templating can be IDE compliant as long as the IDE does support pre-build step(s). The current build flow already contains steps requiring this and thus I don't think situation would be much worse with any mentioned solution than it is today. /George 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: 23 September 2020 08:33 To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Please, do not add changes to sources & linker-files which may harm Non-Cmake systems (IDEs). Thanks, Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 23, 2020 8:05 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: Re: [TF-M] Proposal to separate SCT/LD into each platform folder As cmake is still the build system, let me check the cmake related feature - but need to wait the build system change get merged then we can take a look where to start. BR. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Tuesday, September 22, 2020 4:43 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] Proposal to separate SCT/LD into each platform folder Hi Ken, I think templating is a good approach here, the current C preprocessor based solution is a very limited implementation of this. I see two main contenders for templating: 1. cmake has built in support for templating with the configure_file() [1] command. This would move ownership of this information info the build scripts, which are the focus point for such info already. A cmake based solution would feel more native to the existing system. On the other hand other solutions might have more features, which could lead to easier to read template files. Also cmake as a template engine is not that widely adopted. 2. jinja2 [2]. A widely adopted and more feature rich templating engine. TF-M already uses it for manifest file handling. I suggest using yahsa [3] instead of a custom pyhton script as the cli frontend though. This could speed up development as long as no complex processing is needed and the templates can be filled based on "simple" values. Which of the above is the best for the task depends on template file readability and on complexity of the task. It could be nice if a clean split could be made, and we could stop using the C preprocessor based processing completely. "Not sure if all these format support #include" The build system works around that by implementing a compiler specific cmake function to add the pre-processing step for compilers not supporting pre-processing out of the box. /George [1] https://cmake.org/cmake/help/v3.18/command/configure_file.html<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org…> [2] https://jinja.palletsprojects.com/en/2.11.x/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjinja.pal…> [3] https://github.com/kblomqvist/yasha<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 22 September 2020 10:15 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] Proposal to separate SCT/LD into each platform folder Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 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] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What's your opinion on this? Best regards, Shawn

5 years, 1 month

1
0
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Ken Liu

Hi, Thanks for the input - this should be the goal we are approaching. I believe the updated build system has changed something, and I will raise an proposal based on that during October, let's discuss when the proposal is done. Before that, two more questions: * So if a user have to modify the file manually, will they work on the .sct directly, or the .sct.template? * Does your IDE support pre-build function? What kinds of command it could support? An IDE specific script or general shell commands or python? Thanks. /Ken From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Wednesday, September 23, 2020 3:33 PM To: Gyorgy Szing <Gyorgy.Szing(a)arm.com>; Ken Liu <Ken.Liu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Ken, So we are using one default/typical configuration. If any change in it, a user have to do changes manually which are not clear without deeper knowledge of the TFM project. But this is the issue of the TF-M chosen approach - fully rely on cmake preprocessing. The proposal is to use approach which is good for all worlds (cmake and IDEs) and which is used by all embedded MCU open-source projects like MbedTLS, FreeRTOS, lwIP, FNET and etc. Which is to have only one set of platform-independent files and the framework configuration from a user/project configuration file. It will work for both worlds, will solve all configuration issues we have, and will make TF-M easy to use and more popular. I am talking about this from very beginning. As no steps in right direction, we have a forked TF-M for our SDK. Thanks George for support ;) Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 23, 2020 8:45 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: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Andrej, Sounds like your IDE is using the default .sct/.ld file, may I ask some a question that: * Is there a scenario that someone wants to add more partitions other than the default ones into your system, and how could they do that? I believe the existing .sct/.ld do not support extra partitions out of the default ones unless some manually modification is done. We need to support more components (partition is the direct example), so in this case, the sct/ld can't be avoided to be modified. Or do you think if we put a specific .sct/.ld under nxp folder would work if there is no other partitions are needed? Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Wednesday, September 23, 2020 8:46 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: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi, Good point, this is an important factor. I think templating can be IDE compliant as long as the IDE does support pre-build step(s). The current build flow already contains steps requiring this and thus I don't think situation would be much worse with any mentioned solution than it is today. /George 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: 23 September 2020 08:33 To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Please, do not add changes to sources & linker-files which may harm Non-Cmake systems (IDEs). Thanks, Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 23, 2020 8:05 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: Re: [TF-M] Proposal to separate SCT/LD into each platform folder As cmake is still the build system, let me check the cmake related feature - but need to wait the build system change get merged then we can take a look where to start. BR. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Tuesday, September 22, 2020 4:43 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] Proposal to separate SCT/LD into each platform folder Hi Ken, I think templating is a good approach here, the current C preprocessor based solution is a very limited implementation of this. I see two main contenders for templating: 1. cmake has built in support for templating with the configure_file() [1] command. This would move ownership of this information info the build scripts, which are the focus point for such info already. A cmake based solution would feel more native to the existing system. On the other hand other solutions might have more features, which could lead to easier to read template files. Also cmake as a template engine is not that widely adopted. 2. jinja2 [2]. A widely adopted and more feature rich templating engine. TF-M already uses it for manifest file handling. I suggest using yahsa [3] instead of a custom pyhton script as the cli frontend though. This could speed up development as long as no complex processing is needed and the templates can be filled based on "simple" values. Which of the above is the best for the task depends on template file readability and on complexity of the task. It could be nice if a clean split could be made, and we could stop using the C preprocessor based processing completely. "Not sure if all these format support #include" The build system works around that by implementing a compiler specific cmake function to add the pre-processing step for compilers not supporting pre-processing out of the box. /George [1] https://cmake.org/cmake/help/v3.18/command/configure_file.html<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org…> [2] https://jinja.palletsprojects.com/en/2.11.x/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjinja.pal…> [3] https://github.com/kblomqvist/yasha<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 22 September 2020 10:15 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] Proposal to separate SCT/LD into each platform folder Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 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] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What's your opinion on this? Best regards, Shawn

5 years, 1 month

1
0
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Gyorgy Szing

Hi, Good point, this is an important factor. I think templating can be IDE compliant as long as the IDE does support pre-build step(s). The current build flow already contains steps requiring this and thus I don't think situation would be much worse with any mentioned solution than it is today. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 23 September 2020 08:33 To: Ken Liu <Ken.Liu(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Please, do not add changes to sources & linker-files which may harm Non-Cmake systems (IDEs). Thanks, Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 23, 2020 8:05 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: Re: [TF-M] Proposal to separate SCT/LD into each platform folder As cmake is still the build system, let me check the cmake related feature - but need to wait the build system change get merged then we can take a look where to start. BR. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Tuesday, September 22, 2020 4:43 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] Proposal to separate SCT/LD into each platform folder Hi Ken, I think templating is a good approach here, the current C preprocessor based solution is a very limited implementation of this. I see two main contenders for templating: 1. cmake has built in support for templating with the configure_file() [1] command. This would move ownership of this information info the build scripts, which are the focus point for such info already. A cmake based solution would feel more native to the existing system. On the other hand other solutions might have more features, which could lead to easier to read template files. Also cmake as a template engine is not that widely adopted. 2. jinja2 [2]. A widely adopted and more feature rich templating engine. TF-M already uses it for manifest file handling. I suggest using yahsa [3] instead of a custom pyhton script as the cli frontend though. This could speed up development as long as no complex processing is needed and the templates can be filled based on "simple" values. Which of the above is the best for the task depends on template file readability and on complexity of the task. It could be nice if a clean split could be made, and we could stop using the C preprocessor based processing completely. "Not sure if all these format support #include" The build system works around that by implementing a compiler specific cmake function to add the pre-processing step for compilers not supporting pre-processing out of the box. /George [1] https://cmake.org/cmake/help/v3.18/command/configure_file.html<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org…> [2] https://jinja.palletsprojects.com/en/2.11.x/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjinja.pal…> [3] https://github.com/kblomqvist/yasha<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 22 September 2020 10:15 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] Proposal to separate SCT/LD into each platform folder Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 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] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What's your opinion on this? Best regards, Shawn

5 years, 1 month

1
0
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Andrej Butok

Please, do not add changes to sources & linker-files which may harm Non-Cmake systems (IDEs). Thanks, Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 23, 2020 8:05 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder As cmake is still the build system, let me check the cmake related feature - but need to wait the build system change get merged then we can take a look where to start. BR. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Tuesday, September 22, 2020 4:43 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] Proposal to separate SCT/LD into each platform folder Hi Ken, I think templating is a good approach here, the current C preprocessor based solution is a very limited implementation of this. I see two main contenders for templating: 1. cmake has built in support for templating with the configure_file() [1] command. This would move ownership of this information info the build scripts, which are the focus point for such info already. A cmake based solution would feel more native to the existing system. On the other hand other solutions might have more features, which could lead to easier to read template files. Also cmake as a template engine is not that widely adopted. 2. jinja2 [2]. A widely adopted and more feature rich templating engine. TF-M already uses it for manifest file handling. I suggest using yahsa [3] instead of a custom pyhton script as the cli frontend though. This could speed up development as long as no complex processing is needed and the templates can be filled based on "simple" values. Which of the above is the best for the task depends on template file readability and on complexity of the task. It could be nice if a clean split could be made, and we could stop using the C preprocessor based processing completely. "Not sure if all these format support #include" The build system works around that by implementing a compiler specific cmake function to add the pre-processing step for compilers not supporting pre-processing out of the box. /George [1] https://cmake.org/cmake/help/v3.18/command/configure_file.html<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org…> [2] https://jinja.palletsprojects.com/en/2.11.x/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjinja.pal…> [3] https://github.com/kblomqvist/yasha<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 22 September 2020 10:15 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] Proposal to separate SCT/LD into each platform folder Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 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] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What's your opinion on this? Best regards, Shawn

5 years, 1 month

2
1
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Ken Liu

As cmake is still the build system, let me check the cmake related feature - but need to wait the build system change get merged then we can take a look where to start. BR. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: Tuesday, September 22, 2020 4:43 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Ken, I think templating is a good approach here, the current C preprocessor based solution is a very limited implementation of this. I see two main contenders for templating: 1. cmake has built in support for templating with the configure_file() [1] command. This would move ownership of this information info the build scripts, which are the focus point for such info already. A cmake based solution would feel more native to the existing system. On the other hand other solutions might have more features, which could lead to easier to read template files. Also cmake as a template engine is not that widely adopted. 2. jinja2 [2]. A widely adopted and more feature rich templating engine. TF-M already uses it for manifest file handling. I suggest using yahsa [3] instead of a custom pyhton script as the cli frontend though. This could speed up development as long as no complex processing is needed and the templates can be filled based on "simple" values. Which of the above is the best for the task depends on template file readability and on complexity of the task. It could be nice if a clean split could be made, and we could stop using the C preprocessor based processing completely. "Not sure if all these format support #include" The build system works around that by implementing a compiler specific cmake function to add the pre-processing step for compilers not supporting pre-processing out of the box. /George [1] https://cmake.org/cmake/help/v3.18/command/configure_file.html [2] https://jinja.palletsprojects.com/en/2.11.x/ [3] https://github.com/kblomqvist/yasha From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 22 September 2020 10:15 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] Proposal to separate SCT/LD into each platform folder Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 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] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What's your opinion on this? Best regards, Shawn

5 years, 1 month

1
0
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Gyorgy Szing

Hi Ken, I think templating is a good approach here, the current C preprocessor based solution is a very limited implementation of this. I see two main contenders for templating: 1. cmake has built in support for templating with the configure_file() [1] command. This would move ownership of this information info the build scripts, which are the focus point for such info already. A cmake based solution would feel more native to the existing system. On the other hand other solutions might have more features, which could lead to easier to read template files. Also cmake as a template engine is not that widely adopted. 2. jinja2 [2]. A widely adopted and more feature rich templating engine. TF-M already uses it for manifest file handling. I suggest using yahsa [3] instead of a custom pyhton script as the cli frontend though. This could speed up development as long as no complex processing is needed and the templates can be filled based on "simple" values. Which of the above is the best for the task depends on template file readability and on complexity of the task. It could be nice if a clean split could be made, and we could stop using the C preprocessor based processing completely. "Not sure if all these format support #include" The build system works around that by implementing a compiler specific cmake function to add the pre-processing step for compilers not supporting pre-processing out of the box. /George [1] https://cmake.org/cmake/help/v3.18/command/configure_file.html [2] https://jinja.palletsprojects.com/en/2.11.x/ [3] https://github.com/kblomqvist/yasha From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 22 September 2020 10:15 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 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] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What's your opinion on this? Best regards, Shawn

5 years, 1 month

1
0
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Ken Liu

Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What's your opinion on this? Best regards, Shawn

5 years, 1 month

1
0
0 0

Linaro Connect Sessions of Interest

by Don Harbin

Hi All, As Linaro Connect starts tomorrow, here are some pointers to sessions that will be of interest related to trustedfirmware.org. - *PSA Secure Partitions in OP-TEE* - Tuesday, September 22nd (1:25-1:50pm UTC) - Speaker: Miklos Balint - Slides available here <https://static.sched.com/hosted_files/lvc20/9a/LVC20-112_PSA_Secure_Partiti…> - *Trusted Firmware Project update* - Tuesday, Sept. 22nd (2:00-2:25pm UTC) - Spreaders: Matteo Carlini, Shebu Kuriakose - Slides available here <https://static.sched.com/hosted_files/lvc20/1e/LVC20-113-Trusted-Firmware-p…> - *Scalable Security Using Trusted Firmware-M Profiles* - Wednesday September 23rd (11.45am – 12.10pm UTC) - Speakers: Shebu Kuiakose, David Want - Slides available here <https://static.sched.com/hosted_files/lvc20/d0/ScalableSecurityUsingTrusted…> - *Enable UEFI Secure Boot using OP-TEE as Secure Partition* - Thursday September 24th (3.45-4.10pm UTC) - Speakers: Sahil Malhotra, Ilias Apalodimas - *Secure Partition Manager (SEL2 firmware) for Arm A-class devices* - Thursday September 24th (4.15-4.40pm UTC) - Speaker: Olivier Deprez - Slides are available here <https://static.sched.com/hosted_files/lvc20/09/LVC20-305-secure-partition-m…> Some general pointers to sessions of potential interest: - Security related topics can be viewed here - Boot architecture topics can be viewed here As a reminder, sign up for tomorrow's event is at Linaro Connect Registration <https://connect.linaro.org/> and is free, so feel free to forward this information on. :) The overall schedule is available at the same link as registration in case you may be interested in other sessions. Best regards, Don

5 years, 1 month

1
0
0 0

Re: [TF-M] Patch to upgrade crypto service to use latest mbedTLS tag (v2.23.0)

by Soby Mathew

For the record, I have attached the full log of the PSA Arch Crypto test run on AN521. The SHA of respective repositories are the test run given below: TF-M - 8f895ab8 PSA Arch tests - ee3c463d tf-m-tests - 7789423 mbedtls - tag: mbedtls-2.23.0 There is an additional failure for test "psa_close_key with RSA 2048 keypair" compared to the summary report below. This is due to incorrect build flag propagation for changing the ITS_MAX_ASSET_SIZE. This will be corrected in the following days. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby Mathew via TF-M Sent: 21 August 2020 11:22 To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] Patch to upgrade crypto service to use latest mbedTLS tag (v2.23.0) Just an update to this, I have merged the patch which upgrades to the latest mbedTLS tag. The PSA Arch initial attestation test suite fails to build after this merge due to width change of `ecc_curve_t` type. The issue is reported here in PSA Arch test github project : https://github.com/ARM-software/psa-arch-tests/pull/232 The patch for changing the ITS_MAX_ASSET_SIZE is still outstanding and I hope to merge it after a week. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Soby Mathew via TF-M Sent: 11 August 2020 16:24 To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] Patch to upgrade crypto service to use latest mbedTLS tag (v2.23.0) Hi Everyone The following patch updates the crypto service in TF-M to use the latest mbedTLS tag v2.23.0. All reviews for the same will be much appreciated. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5252/1 With this update, additional PSA APIs psa_hash_compute() and psa_hash_compare() are now supported. There is also another patch for platforms to update the ITS_MAX_ASSET_SIZE when testing with PSA Crypto API compliance test as one of the tests require a larger size: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5253/1 . Could the platform owners review the same and let me know whether the size changes are OK ? With the above patches, the API compliance remains the same as v1.0 Beta 3 and the PSA Crypto compliance test suite gives the below results (as tested on AN521) : ************ Crypto Suite Report ********** TOTAL TESTS : 61 TOTAL PASSED : 42 TOTAL SIM ERROR : 0 TOTAL FAILED : 17 TOTAL SKIPPED : 2 ****************************************** Best Regards Soby Mathes

5 years, 1 month

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - September 17

by Summer Qin

Hi Anton, I'd like to briefly introduce the enhancement of the TF-M initialization flow, about 20 minutes. Regards, Summer ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Sherry Zhang via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Tuesday, September 15, 2020 3:08 PM To: Anton Komlev <Anton.Komlev(a)arm.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M Technical Forum call - September 17 Hi Anton, I would like to give a very brief introduction of the integration work of TF-M and FreeRTOS Kernel which has been merged into FreeRTOS. It will take about 10 minutes around. Regards, Sherry From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, September 9, 2020 11:34 PM 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 - September 17 Hello, The next Technical Forum is planned on Thursday, September 17 at 6:00-07: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

5 years, 1 month

2
1
0 0

Re: [TF-M] TF-M Technical Forum call - September 17

by Sherry Zhang

Hi Anton, I would like to give a very brief introduction of the integration work of TF-M and FreeRTOS Kernel which has been merged into FreeRTOS. It will take about 10 minutes around. Regards, Sherry From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, September 9, 2020 11:34 PM 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 - September 17 Hello, The next Technical Forum is planned on Thursday, September 17 at 6:00-07: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

5 years, 1 month

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - September 17

by Kevin Peng

Anton, I'd like to give an update on the HAL APIs, around 10 minutes. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, September 9, 2020 11:34 PM 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 - September 17 Hello, The next Technical Forum is planned on Thursday, September 17 at 6:00-07: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

5 years, 1 month

1
0
0 0

Secure Enclave solution in TF-M

by Mark Horvath

Dear All, Following the tech forum presentation (back in 6th August) I uploaded the draft design document for the Secure Enclave topic: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5653 I also updated the first implementation of the proposed solution for the Musca-B1 board with minimal features, marked as WIP: https://review.trustedfirmware.org/q/topic:%22Secure+Enclave%22+(status:ope… Limitations, missing features, notes: * No support for isolation level2 on SSE-200 * Protected Storage is an Application RoT partition, but PS also moved to Secure Enclave * Some regression tests running on secure side of SSE-200 fail as all messages are forwarded with the same client ID to Secure Enclave * All IPC message forwarding is a blocking call * Only one message is put into the mailbox at a time * Musca-B1 related documentation is not complete yet * Generated files are not committed, manifest parser should be run before build. * The BL0 component mentioned in the tech forum presentation is not uploaded, as it is based on the new cmake system, and not so interesting right now * Cmake changes are rudimentary, will be rebased to new cmake system. Any feedback very welcomed! Best regards, Márk Horváth Senior Software Engineer Mark.Horvath(a)arm.com<mailto:Mark.Horvath@arm.com> Arm Hungary Kft., Corvin Offices II, Crystal Tower, Budapest, Futó u. 45. H-1082 Hungary www.arm.com<http://www.arm.com/>

5 years, 1 month

1
0
0 0

Re: [TF-M] Integration of TF-M and FreeRTOS Kernel has been merged into FreeRTOS

by Anton Komlev

Great news! Congratulations, Shery, David. You made it happen! Cheers, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang via TF-M Sent: 14 September 2020 04:47 To: tf-m(a)lists.trustedfirmware.org; Sherry Zhang <Sherry.Zhang2(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Integration of TF-M and FreeRTOS Kernel has been merged into FreeRTOS Thanks Sherry for sharing this great news! Regards, David Wang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Sherry Zhang via TF-M Sent: Monday, September 14, 2020 9:50 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] Integration of TF-M and FreeRTOS Kernel has been merged into FreeRTOS Hi all, The integration of TF-M and FreeRTOS Kernel has been merged into the official FreeRTOS Kernel repository<https://github.com/FreeRTOS/FreeRTOS-Kernel> master branch. You can follow this port<https://github.com/FreeRTOS/FreeRTOS-Kernel/tree/master/portable/ThirdParty…> on Cortex-M33 platforms. Regards, Sherry Zhang

5 years, 1 month

1
0
0 0

Re: [TF-M] Integration of TF-M and FreeRTOS Kernel has been merged into FreeRTOS

by David Wang

Thanks Sherry for sharing this great news! Regards, David Wang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Sherry Zhang via TF-M Sent: Monday, September 14, 2020 9:50 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Integration of TF-M and FreeRTOS Kernel has been merged into FreeRTOS Hi all, The integration of TF-M and FreeRTOS Kernel has been merged into the official FreeRTOS Kernel repository<https://github.com/FreeRTOS/FreeRTOS-Kernel> master branch. You can follow this port<https://github.com/FreeRTOS/FreeRTOS-Kernel/tree/master/portable/ThirdParty…> on Cortex-M33 platforms. Regards, Sherry Zhang

5 years, 1 month

1
0
0 0

Integration of TF-M and FreeRTOS Kernel has been merged into FreeRTOS

by Sherry Zhang

Hi all, The integration of TF-M and FreeRTOS Kernel has been merged into the official FreeRTOS Kernel repository<https://github.com/FreeRTOS/FreeRTOS-Kernel> master branch. You can follow this port<https://github.com/FreeRTOS/FreeRTOS-Kernel/tree/master/portable/ThirdParty…> on Cortex-M33 platforms. Regards, Sherry Zhang

5 years, 1 month

1
0
0 0

Re: [TF-M] The GNUARM linker script change about psa_client objects and the integration method [NXP]

by Ken Liu

Hi Andrej, Thanks, if the different approach for project compilation has its own ld file then we can remove these 4 lines - going to create a patch for this. BR /Ken From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Friday, September 11, 2020 9:10 PM To: Ken Liu <Ken.Liu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: The GNUARM linker script change about psa_client objects and the integration method [NXP] Hi Ken, Guess, these lines where upstream from NXP SDK, which is using a different approach for project compilation. Most probably they may be removed for the original TFM. Best regards, Andrej From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Friday, September 11, 2020 3:04 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] The GNUARM linker script change about psa_client objects and the integration method [NXP] Hi, When I was trying to re-arrange the linker script I found below changes: *psa_client.*(.text*) /* NXP */ *psa_client.*(.rodata*) *psa_service.*(.text*) /* NXP */ *psa_service.*(.rodata*) *psa_lifecycle.*(.text*) /* NXP */ *psa_lifecycle.*(.rodata*) *tfm_log_raw.*(.text*) /* NXP */ I think at least the psa_client.o and psa_service.o are included into the libtfmsprt.a so these items looks duplicated. What is the purpose of this change? Would it fix build problem or runtime problem? Thanks. /Ken

5 years, 1 month

1
0
0 0

The GNUARM linker script change about psa_client objects and the integration method [NXP]

by Ken Liu

Hi, When I was trying to re-arrange the linker script I found below changes: *psa_client.*(.text*) /* NXP */ *psa_client.*(.rodata*) *psa_service.*(.text*) /* NXP */ *psa_service.*(.rodata*) *psa_lifecycle.*(.text*) /* NXP */ *psa_lifecycle.*(.rodata*) *tfm_log_raw.*(.text*) /* NXP */ I think at least the psa_client.o and psa_service.o are included into the libtfmsprt.a so these items looks duplicated. What is the purpose of this change? Would it fix build problem or runtime problem? Thanks. /Ken

5 years, 1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M