- TF-M - lists.trustedfirmware.org

Remove some platform specific test cases

by Shawn Shan

Hi all, We are going to remove some test cases in tfm_core_test. They are: * TFM_INTERACTIVE_TEST * TFM_PERIPH_ACCESS_TEST The main reasons is that these peripheral and interactive test cases are mainly platform specific(button and LEDs), rather than test the main features and secure functionalities of TF-M. Besides, it also a burden for flatform owner to support and maintain those test cases. Do you have any concerns for remove those test cases? Best Regards, Shawn

4 years, 9 months

1
0
0 0

Technical Forum call - Sep 16

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, Sep 16, 7:00-8: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

3
2
0 0

Re: [TF-M] TF-M Digest, Vol 35, Issue 6

by Michael Thomas

Ken, Hu, I just saw this message now and wanted to give my perspective based on some of the code Renesas has developed. In general, the primary benefits of having enums are return codes are type checking and portability. So of you have a top level application using an API that always returns an error from a defined enum list, then the application can switch to using different implementations of the same API and does not have to change its error handling code etc. However, if you are returning uint32 instead then its likely that different implementations of the same API will have any possible return code making the application non-portable. I think the issue arises when the enum list is not sufficiently well defined so each enum entry ends up acting as a funnel for x number of lower level error code so there is loss of information etc. But w.r.t the line in the TFM coding guide : " Use enumeration for error codes to keep the code readable.", if the objective is just to make the code readable, then you don’t really need an enum for that... you can achieve readability by using #define XYZ_error. I think that will be much harder to maintain particularly in terms of preventing different error codes from being defined to the same value unless we have a common file where all error code are defined for a specific layer. -Michael -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of tf-m-request(a)lists.trustedfirmware.org Sent: Friday, September 3, 2021 4:38 AM To: tf-m(a)lists.trustedfirmware.org Subject: TF-M Digest, Vol 35, Issue 6 Send TF-M mailing list submissions to tf-m(a)lists.trustedfirmware.org To subscribe or unsubscribe via the World Wide Web, visit https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… or, via email, send a message with subject or body 'help' to tf-m-request(a)lists.trustedfirmware.org You can reach the person managing the list at tf-m-owner(a)lists.trustedfirmware.org When replying, please edit your Subject line so it is more specific than "Re: Contents of TF-M digest..." Today's Topics: 1. Re: [RFC] Can we remove the rule to use enum for error code? (Ken Liu) 2. Re: [RFC] Can we remove the rule to use enum for error code? (Andrew Thoelke) ---------------------------------------------------------------------- Message: 1 Date: Fri, 3 Sep 2021 07:54:41 +0000 From: Ken Liu <Ken.Liu(a)arm.com> To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Can we remove the rule to use enum for error code? Message-ID: <DBBPR08MB4741B0807FC4ACD9F4466520F5CF9(a)DBBPR08MB4741.eurprd08.prod.outlook.com> Content-Type: text/plain; charset="utf-8" I am okay to remove it. Even it can be used to check the error types, but some of the developers do typecast on enum which makes the rule no sense. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Friday, September 3, 2021 3:45 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] Can we remove the rule to use enum for error code? Hi all, Probably you didn’t know that there is such a rule in TF-M coding standard<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftf-m-user…>: * Use enumeration for error codes to keep the code readable. Personally, I’d prefer macros to enum, for error codes. * The implicit type casting of enum can be an issue in coding. TF-M has a document<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftf-m-user…> to solve this. * Using macros to define error codes aligns with PSA return code definitions. * Enum makes function and variable definitions longer * Enum may help developers skip writing specific error code values. But it becomes a trouble when you see an error number from log. You might need to count the enum fields one by one. * Error codes for errors are usually negative but enums are positive ones by default. I’d like to propose to remove this rule from TF-M coding standard. But it doesn’t mean that enum shall not be used anymore. I’m wondering if macros for error code in TF-M can be approved as well. 😊 May I know your opinions please? If it is a convention or a good practice to use enum for error codes in security/trusted software, please help point me to the reference. I don’t find one via google. Thanks a lot! Best regards, Hu Ziji -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://jpn01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.trus…> ------------------------------ Message: 2 Date: Fri, 3 Sep 2021 08:38:02 +0000 From: Andrew Thoelke <Andrew.Thoelke(a)arm.com> To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Can we remove the rule to use enum for error code? Message-ID: <DB7PR08MB38651B33CD7BAEB9BF05F0229ACF9(a)DB7PR08MB3865.eurprd08.prod.outlook.com> Content-Type: text/plain; charset="utf-8" Hi, In my experience, the only significant benefit of using enums is that some debuggers display the symbolic name for a value with the enum type. But, as already mentioned, using enums does not help in parsing logs, or decoding error values in integer variables/registers; particularly when the definition does not provide explicit values for each identifier. In addition, the rules for determining the implicit integer type for an enum type are non-trivial. This results in a lack of transparency when reading or reviewing code with respect to the size of the enum type in a data structure, or the behaviour when converting an enum value to an integer (or back again). This is why the PSA specifications use explicitly sized integer types for types like psa_status_t, and macros to define values of such types. Regards, Andrew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: 03 September 2021 08:45 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] Can we remove the rule to use enum for error code? Hi all, Probably you didn’t know that there is such a rule in TF-M coding standard<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftf-m-user…>: * Use enumeration for error codes to keep the code readable. Personally, I’d prefer macros to enum, for error codes. * The implicit type casting of enum can be an issue in coding. TF-M has a document<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftf-m-user…> to solve this. * Using macros to define error codes aligns with PSA return code definitions. * Enum makes function and variable definitions longer * Enum may help developers skip writing specific error code values. But it becomes a trouble when you see an error number from log. You might need to count the enum fields one by one. * Error codes for errors are usually negative but enums are positive ones by default. I’d like to propose to remove this rule from TF-M coding standard. But it doesn’t mean that enum shall not be used anymore. I’m wondering if macros for error code in TF-M can be approved as well. 😊 May I know your opinions please? If it is a convention or a good practice to use enum for error codes in security/trusted software, please help point me to the reference. I don’t find one via google. Thanks a lot! Best regards, Hu Ziji -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://jpn01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.trus…> ------------------------------ Subject: Digest Footer TF-M mailing list TF-M(a)lists.trustedfirmware.org https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… ------------------------------ End of TF-M Digest, Vol 35, Issue 6 *********************************** Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not an intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you.

4 years, 9 months

2
1
0 0

Unaligned flash read/write is supported in Boot & FWU

by Sherry Zhang

Hi, The following patch enables the flash read/write with unaligned address/cnt for MCUboot and Firmware Update partition. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10947 This patch has been merged and thanks to all who have reviewed on this patch. As this patch can impact the MCUboot booting up on the platforms, if there is any booting up issue on your platform after this commit, do not hesitate to feedback to me. 😊 Thanks, Regards, Sherry Zhang

4 years, 9 months

1
0
0 0

BOOT_TFM_SHARED_DATA_* usage in arm/musca_b1

by Bohdan.Hunko＠infineon.com

Hi everyone! I see definitions of BOOT_TFM_SHARED_DATA_* in platform\ext\target\arm\musca_b1\sse_200\partition\region_defs.h but I don't see any real usage of that memory. I have found TF-M doc<https://tf-m-user-guide.trustedfirmware.org/docs/technical_references/desig…> that describe usage of shared memory for Firmware Update Service but once again I was not able to find any code that uses that. I would appreciate if someone could point to docs on this or to code that actually uses shared data between BL2 and TF-M SPE. Best regards, Bohdan Hunko Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>

4 years, 9 months

4
3
0 0

[RFC] Can we remove the rule to use enum for error code?

by David Hu

Hi all, Probably you didn’t know that there is such a rule in TF-M coding standard<https://tf-m-user-guide.trustedfirmware.org/docs/contributing/coding_guide.…>: * Use enumeration for error codes to keep the code readable. Personally, I’d prefer macros to enum, for error codes. * The implicit type casting of enum can be an issue in coding. TF-M has a document<https://tf-m-user-guide.trustedfirmware.org/docs/technical_references/desig…> to solve this. * Using macros to define error codes aligns with PSA return code definitions. * Enum makes function and variable definitions longer * Enum may help developers skip writing specific error code values. But it becomes a trouble when you see an error number from log. You might need to count the enum fields one by one. * Error codes for errors are usually negative but enums are positive ones by default. I’d like to propose to remove this rule from TF-M coding standard. But it doesn’t mean that enum shall not be used anymore. I’m wondering if macros for error code in TF-M can be approved as well. 😊 May I know your opinions please? If it is a convention or a good practice to use enum for error codes in security/trusted software, please help point me to the reference. I don’t find one via google. Thanks a lot! Best regards, Hu Ziji

4 years, 10 months

4
4
0 0

Re: [TF-M] TF-M v1.3.0 release - Fault Injection and DPA in line with PSA L3 Certification

by Reed Hinkel

Hello Suresh: How are you? I hope all is well with you! Virtual Linaro Connect Fall is next week and there is a presentation relevant to your question along with some others. As an online event, it is free registration and I am listing here below a few sessions that might be of interest to you related to security and AI inferencing for microcontrollers: https://connect.linaro.org/schedule LVC21F-116 Assessing the effectiveness of MCUBoot protections against fault injection attacks https://events.pinetool.ai/2231/#sessions/67139?referrer%5Bpathname%5D=%2Fs… LVC21F-112 Picolibc: A C Library for Smaller Systems https://events.pinetool.ai/2231/#sessions/67136?referrer%5Bpathname%5D=%2Fs… LVC21F-303 Secure Sensor Data Pipeline https://events.pinetool.ai/2231/#sessions/67174?referrer%5Bpathname%5D=%2Fs… LVC21F-312 TrustedFirmware.org panel discussion https://events.pinetool.ai/2231/#sessions/67183?referrer%5Bpathname%5D=%2Fs… LVC21F-319 TVM for micro targets https://events.pinetool.ai/2231/#sessions/67190?referrer%5Bpathname%5D=%2Fs… I thought you may be interested in the AI as well since there are security implications for trusted AI. All the best! Reed From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Suresh Marisetty via TF-M <tf-m(a)lists.trustedfirmware.org> Reply-To: "Suresh.Marisetty(a)infineon.com" <Suresh.Marisetty(a)infineon.com> Date: Thursday, September 2, 2021 at 8:23 AM 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 v1.3.0 release - Fault Injection and DPA in line with PSA L3 Certification Hi, I have a question related to the PSA L3 certification and the requirement to support Side-channel and fault injection attacks. I have noted that TFM and MCUBoot does implement some software countermeasures for Fault Injection. However, I am wondering if there is similar implementation support for the Crypto Lib in TFM (or Mbed TLS) with software counter measures for side channel DPA. Needless to say, there are some known best practices for DPA software countermeasures. thanks Suresh Marisetty Infineon Semiconductor Corporation From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Friday, April 9, 2021 6:25 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M v1.3.0 release Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://goto.infineon.com/SocialEngineering>. Hello, TF-M project released version v1.3.0, tagged as TF-Mv1.3.0. Please take a look into the release notes for the new features and changes: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/refer… The major features: * Support stateless RoT Service defined in FF-M 1.1 * Support Second-Level Interrupt Handling (SLIH) defined in FF-M 1.1 * Add Firmware Update (FWU) secure service, following Platform Security Architecture Firmware Update API * Migrate to Mbed TLS v2.25.0 * Update MCUboot version to v1.7.2 * Add a TF-M generic threat model * Implement Fault Injection Handling library to mitigate physical attacks * Add Profile Large * Enable code sharing between boot loader and TF-M * Support Armv8.1-M Privileged Execute Never (PXN) attribute and Thread reentrancy disabled (TRD) feature * New platforms added * Add a TF-M security landing page * Enhance dual-cpu non-secure mailbox reference implementation This is the first release performed in the OpenCI infrastructure with no single issue encountered. Thanks to everyone who directly and indirectly contributed to this milestone. Anton Komlev TF-M technical lead Arm Ltd.

4 years, 10 months

1
0
0 0

Re: [TF-M] TF-M v1.3.0 release - Fault Injection and DPA in line with PSA L3 Certification

by Suresh.Marisetty＠infineon.com

Hi, I have a question related to the PSA L3 certification and the requirement to support Side-channel and fault injection attacks. I have noted that TFM and MCUBoot does implement some software countermeasures for Fault Injection. However, I am wondering if there is similar implementation support for the Crypto Lib in TFM (or Mbed TLS) with software counter measures for side channel DPA. Needless to say, there are some known best practices for DPA software countermeasures. thanks Suresh Marisetty Infineon Semiconductor Corporation From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Friday, April 9, 2021 6:25 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M v1.3.0 release Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://goto.infineon.com/SocialEngineering>. Hello, TF-M project released version v1.3.0, tagged as TF-Mv1.3.0. Please take a look into the release notes for the new features and changes: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/refer… The major features: * Support stateless RoT Service defined in FF-M 1.1 * Support Second-Level Interrupt Handling (SLIH) defined in FF-M 1.1 * Add Firmware Update (FWU) secure service, following Platform Security Architecture Firmware Update API * Migrate to Mbed TLS v2.25.0 * Update MCUboot version to v1.7.2 * Add a TF-M generic threat model * Implement Fault Injection Handling library to mitigate physical attacks * Add Profile Large * Enable code sharing between boot loader and TF-M * Support Armv8.1-M Privileged Execute Never (PXN) attribute and Thread reentrancy disabled (TRD) feature * New platforms added * Add a TF-M security landing page * Enhance dual-cpu non-secure mailbox reference implementation This is the first release performed in the OpenCI infrastructure with no single issue encountered. Thanks to everyone who directly and indirectly contributed to this milestone. Anton Komlev TF-M technical lead Arm Ltd.

4 years, 10 months

2
1
0 0

Re: [TF-M] Technical Forum call - Sep 2

by Anton Komlev

Hi, The agenda for the forum tomorrow: 1. "Summary of the proposed changes in FF-M v1.1 beta" by Andrew Thoelke 2. "Summary of upcoming significant changes in SPM" by Ken Liu containing: * MMIO and interrupt binding. * Remove unformal symbols such as ARM_LIB_STACK_MSP. Thanks, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Saturday, August 28, 2021 9:36 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Technical Forum call - Sep 2 Hi, There are some significant changes happen in SPM and I want to introduce them in a summary, contains: * MMIO and interrupt binding. * Remove unformal symbols such as ARM_LIB_STACK_MSP. Assuming 30 mins should be good enough. BR /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, August 25, 2021 7:13 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] Technical Forum call - Sep 2 Hi, The next Technical Forum is planned on Thursday, September 2, 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, 10 months

1
0
0 0

Re: [TF-M] [RFC] Changing initialization Stack from PSP to MSP

by Kevin Peng

Hi all, We plan to merge the below patch on next Monday. We will not be able to verify on all platforms. Please do have a test on your platforms. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Peng via TF-M Sent: Tuesday, August 24, 2021 11:02 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] Changing initialization Stack from PSP to MSP Hi dear platform maintainers, I'd like to draw your attention on this patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11165>. It changes the initialization stack from PSP to MSP. Would you please check if this change breaks your platform? Hi Thomas@IAR, would you please check the changes for IAR? Thanks. For the details of the change, please refer to the patch. Best Regards, Kevin

4 years, 10 months

1
0
0 0

Re: [TF-M] [Request Platform Support] Abstracted MMIO HAL

by Ken Liu

The patchset has updated and now CI passed okay: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11187 BR /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Thursday, August 19, 2021 2:16 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [Request Platform Support] Abstracted MMIO HAL Hi everyone, The existing HAL interface for isolation hardware is not unified, we have to call several interfaces to setup isolation boundaries. Hence, a deeper abstracted interface are provided. Here are the details: - It assumes the hardware resources usages are decided by system designer. Hence there are couple of listed hardware data in the platform code, now most of them are defined in C sources. - When a partition is referencing peripheral (represented as MMIO in FFM), the manifest tooling would link specified resources with the data defined in platform. Now it is using a naming pattern, to let the partition found the resources defined above (now it uses linker to do this). - A HAL API 'tfm_hal_bind_partition' is called when a partition runtime structure is created. This API tells partition info to platform, let platform return an encoded 'p_boundaries' for SPM binding partition with platform. - When boundaries related operations happen in future, SPM would delivery this 'p_boundaries' back to platform, let platform perform boundary setup and check, such as boundary switch or memory check. SPM won't care about the hardware specific settings any more, such as privilged, non-secure/secure and how many MMIO the partition claimed, even the MPU/MPC/PPC things. - Resources defined in platform sources but not referenced would be stripped by toolchain flag. Resources not defined but referenced by partition would generate a linker error, as symbol can't be resolved. We created a patch to showcase the usage on AN521: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11036 This patch applies a simple encoding for all isolation levels. You can check how the p_boundaries is used under different isolation levels. Platform can use other encoding mechanism if applicable. Now come to the request: Please review this patch, and port similar HAL API into your platform. We are maintaining the default platforms such as AN521, AN519 and MUSCA_B1, but it need so much effort on port to all the platforms. Current CI cannot pass on this patch (as it contains modification for one platform only), our first goal is to let CI pass build on all checked platforms, and then please platform owner ensures it works on your platform. Any feedbacks are welcome. Thank you very much! /Ken

4 years, 10 months

1
0
0 0

Re: [TF-M] Technical Forum call - Sep 2

by Ken Liu

Hi, There are some significant changes happen in SPM and I want to introduce them in a summary, contains: * MMIO and interrupt binding. * Remove unformal symbols such as ARM_LIB_STACK_MSP. Assuming 30 mins should be good enough. BR /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, August 25, 2021 7:13 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Technical Forum call - Sep 2 Hi, The next Technical Forum is planned on Thursday, September 2, 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, 10 months

1
0
0 0

Re: [TF-M] [RFC] Decoupling tf-m-tests from TF-M

by David Hu

Hi Chris, It is an excellent suggestion. Out-of-tree Secure Partition build can help integrate secure test service. Non-secure tests are a bit limited due to current tf-m-tests framework right now. Do you prefer to run platform-specific tests alone or still integrate platform-specific tests into TF-M regression tests? Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of chris.brand--- via TF-M Sent: Tuesday, August 24, 2021 11:46 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] [RFC] Decoupling tf-m-tests from TF-M Just wondering if any though has been given to supporting platform-specific tests? Chris 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: Tuesday, August 24, 2021 3:21 AM To: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] [RFC] Decoupling tf-m-tests from TF-M Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informati…>. Hi Andrej, Thanks for the suggestion. Sure. I will track it in the backlog. Currently Jianliang and I are more focusing on the structure level enhancement. But definitely later we will take more effort in the detailed optimizations. Please let us know any time if any other potential issue shall be optimized. Best regards, Hu Ziji From: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>> Sent: Tuesday, August 24, 2021 6:15 PM To: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: RE: [RFC] Decoupling tf-m-tests from TF-M Hi Hu Zij, Thank you for adding possibility to select test cases flexibly. Also, there are about 10 "test" services/partitions in addition to the core PSA ones. But every instance allocates own resources, which can be shared. Guess, merging these 10 test services, which have a common structure, can save some memory. Thank you, Andrej From: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>> Sent: Tuesday, August 24, 2021 11:54 AM To: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: RE: [RFC] Decoupling tf-m-tests from TF-M Hi Andrej, Sorry for the trouble. It does be an issue when TF-M features and test cases are growing faster. So now TF-M support to select a single test case or a subset of test cases to build and run. If running all the tests together costs too much memory, you can select some test cases or just a single one in one time. It is also helpful when you focus on a specific test in debug or development. We are also considering other additional mechanisms to select test case flexibly. Regarding "merging existing ones", do you mean that some test cases shall be disabled by default or combining the similar test cases? May I ask for some examples? Best regards, Hu Ziji From: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>> Sent: Tuesday, August 24, 2021 5:44 PM To: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: RE: [RFC] Decoupling tf-m-tests from TF-M Hi Hu Ziji, BTW: The number of the testing partitions and services is growing consuming memory resources. So, we have to disable some tests for our memory constrained devices. Please think about minimizing number of "testing" partitions/services, by merging existing ones, when it is possible. Thank you, Andrej Butok SW Tech Lead Edge Processing NXP Semiconductors 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: Tuesday, August 24, 2021 11:33 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] [RFC] Decoupling tf-m-tests from TF-M Hi all, As you may know, Jianliang and I are working to better decouple tf-m-tests from trusted-firmware-m repo. The purpose of the decoupling enhancement includes: * Making it more easier to integrate TF-M and port tf-m-tests * Making it more easier to develop TF-M tests, to minimize the changes to TF-M source code or build system. * Making it more flexible to re-structure tf-m-tests and minimize the impact to TF-M Previously Jianliang has decouple test case control and enable users to select single NS/S regression test case in build and test. Currently we are focusing on decoupling tf-m-tests specific config setting from TF-M. So far we have proposed the following major changes: * Decouple tf-m-tests specific config setting from trusted-firmware-m. [TF-M patch<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>][tf-m-tests patch<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>] * Move tf-m-tests specific configs to tf-m-tests repo from trusted-firmware-m [TF-M patch<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>][tf-m-tests patch<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>] More patch sets for decoupling are under review as well. * Decouple tf-m-tests secure log from non-secure log. Switch tf-m-tests secure log to TF-M SP log. [TF-M patch<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>][tf-m-tests patch<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>] * Trigger secure regression tests in TF-M SPE in IPC model, to simplify multi-core development/tests [TF-M patch<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>][tf-m-tests patch<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>] I'd appreciate it if you can take a look at the patch sets above. Any suggestion or comment is welcome. If you have any specific requirement or suggestion of tf-m-tests enhancement, please feel free to contact Jianliang and me. Thanks in advance. Best regards, Hu Ziji

4 years, 10 months

2
2
0 0

Technical Forum call - Sep 2

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, September 2, 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, 10 months

1
0
0 0

Re: [TF-M] [RFC] Decoupling tf-m-tests from TF-M

by Chris.Brand＠infineon.com

Just wondering if any though has been given to supporting platform-specific tests? Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Tuesday, August 24, 2021 3:21 AM To: Andrej Butok <andrey.butok(a)nxp.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] [RFC] Decoupling tf-m-tests from TF-M Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informati…>. Hi Andrej, Thanks for the suggestion. Sure. I will track it in the backlog. Currently Jianliang and I are more focusing on the structure level enhancement. But definitely later we will take more effort in the detailed optimizations. Please let us know any time if any other potential issue shall be optimized. Best regards, Hu Ziji From: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>> Sent: Tuesday, August 24, 2021 6:15 PM To: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: RE: [RFC] Decoupling tf-m-tests from TF-M Hi Hu Zij, Thank you for adding possibility to select test cases flexibly. Also, there are about 10 "test" services/partitions in addition to the core PSA ones. But every instance allocates own resources, which can be shared. Guess, merging these 10 test services, which have a common structure, can save some memory. Thank you, Andrej From: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>> Sent: Tuesday, August 24, 2021 11:54 AM To: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: RE: [RFC] Decoupling tf-m-tests from TF-M Hi Andrej, Sorry for the trouble. It does be an issue when TF-M features and test cases are growing faster. So now TF-M support to select a single test case or a subset of test cases to build and run. If running all the tests together costs too much memory, you can select some test cases or just a single one in one time. It is also helpful when you focus on a specific test in debug or development. We are also considering other additional mechanisms to select test case flexibly. Regarding "merging existing ones", do you mean that some test cases shall be disabled by default or combining the similar test cases? May I ask for some examples? Best regards, Hu Ziji From: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>> Sent: Tuesday, August 24, 2021 5:44 PM To: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: RE: [RFC] Decoupling tf-m-tests from TF-M Hi Hu Ziji, BTW: The number of the testing partitions and services is growing consuming memory resources. So, we have to disable some tests for our memory constrained devices. Please think about minimizing number of "testing" partitions/services, by merging existing ones, when it is possible. Thank you, Andrej Butok SW Tech Lead Edge Processing NXP Semiconductors 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: Tuesday, August 24, 2021 11:33 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] [RFC] Decoupling tf-m-tests from TF-M Hi all, As you may know, Jianliang and I are working to better decouple tf-m-tests from trusted-firmware-m repo. The purpose of the decoupling enhancement includes: * Making it more easier to integrate TF-M and port tf-m-tests * Making it more easier to develop TF-M tests, to minimize the changes to TF-M source code or build system. * Making it more flexible to re-structure tf-m-tests and minimize the impact to TF-M Previously Jianliang has decouple test case control and enable users to select single NS/S regression test case in build and test. Currently we are focusing on decoupling tf-m-tests specific config setting from TF-M. So far we have proposed the following major changes: * Decouple tf-m-tests specific config setting from trusted-firmware-m. [TF-M patch<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>][tf-m-tests patch<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>] * Move tf-m-tests specific configs to tf-m-tests repo from trusted-firmware-m [TF-M patch<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>][tf-m-tests patch<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>] More patch sets for decoupling are under review as well. * Decouple tf-m-tests secure log from non-secure log. Switch tf-m-tests secure log to TF-M SP log. [TF-M patch<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>][tf-m-tests patch<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>] * Trigger secure regression tests in TF-M SPE in IPC model, to simplify multi-core development/tests [TF-M patch<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>][tf-m-tests patch<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>] I'd appreciate it if you can take a look at the patch sets above. Any suggestion or comment is welcome. If you have any specific requirement or suggestion of tf-m-tests enhancement, please feel free to contact Jianliang and me. Thanks in advance. Best regards, Hu Ziji

4 years, 10 months

1
0
0 0

Re: [TF-M] [RFC] Decoupling tf-m-tests from TF-M

by Andrej Butok

Hi Hu Ziji, BTW: The number of the testing partitions and services is growing consuming memory resources. So, we have to disable some tests for our memory constrained devices. Please think about minimizing number of "testing" partitions/services, by merging existing ones, when it is possible. Thank you, Andrej Butok SW Tech Lead Edge Processing NXP Semiconductors From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Tuesday, August 24, 2021 11:33 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] Decoupling tf-m-tests from TF-M Hi all, As you may know, Jianliang and I are working to better decouple tf-m-tests from trusted-firmware-m repo. The purpose of the decoupling enhancement includes: * Making it more easier to integrate TF-M and port tf-m-tests * Making it more easier to develop TF-M tests, to minimize the changes to TF-M source code or build system. * Making it more flexible to re-structure tf-m-tests and minimize the impact to TF-M Previously Jianliang has decouple test case control and enable users to select single NS/S regression test case in build and test. Currently we are focusing on decoupling tf-m-tests specific config setting from TF-M. So far we have proposed the following major changes: * Decouple tf-m-tests specific config setting from trusted-firmware-m. [TF-M patch <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr ustedfirmware.org%2Fc%2FTF-M%2Ftrusted-firmware-m%2F%2B%2F11167&data=04%7C01 %7Candrey.butok%40nxp.com%7Ce6deb39c9db74755362008d966e231b0%7C686ea1d3bc2b4 c6fa92cd99c5c301635%7C0%7C0%7C637653943958809255%7CUnknown%7CTWFpbGZsb3d8eyJ WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata =4nA45CyrLoYjN2b9ytZ6HL16Of9ItUs5OAUbPlsFPTM%3D&reserved=0> ][tf-m-tests patch <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr ustedfirmware.org%2Fc%2FTF-M%2Ftf-m-tests%2F%2B%2F11169%2F1&data=04%7C01%7Ca ndrey.butok%40nxp.com%7Ce6deb39c9db74755362008d966e231b0%7C686ea1d3bc2b4c6fa 92cd99c5c301635%7C0%7C0%7C637653943958809255%7CUnknown%7CTWFpbGZsb3d8eyJWIjo iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=aBB 0Wq8QLghyfAdwzpK%2BHR8R8LVN5emXxL0KOc4bPho%3D&reserved=0> ] * Move tf-m-tests specific configs to tf-m-tests repo from trusted-firmware-m [TF-M patch <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr ustedfirmware.org%2Fc%2FTF-M%2Ftrusted-firmware-m%2F%2B%2F10647&data=04%7C01 %7Candrey.butok%40nxp.com%7Ce6deb39c9db74755362008d966e231b0%7C686ea1d3bc2b4 c6fa92cd99c5c301635%7C0%7C0%7C637653943958819210%7CUnknown%7CTWFpbGZsb3d8eyJ WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata =QwtROeuQVK8nWtprtRVZJnzXM2%2FBgX1ZZspl6dsxBFE%3D&reserved=0> ][tf-m-tests patch <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr ustedfirmware.org%2Fc%2FTF-M%2Ftf-m-tests%2F%2B%2F10556&data=04%7C01%7Candre y.butok%40nxp.com%7Ce6deb39c9db74755362008d966e231b0%7C686ea1d3bc2b4c6fa92cd 99c5c301635%7C0%7C0%7C637653943958819210%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4 wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=IYzd75F NoPwLLzoHqvpNJrn4fAaHTeOYzTujFWJDPTQ%3D&reserved=0> ] More patch sets for decoupling are under review as well. * Decouple tf-m-tests secure log from non-secure log. Switch tf-m-tests secure log to TF-M SP log. [TF-M patch <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr ustedfirmware.org%2Fc%2FTF-M%2Ftrusted-firmware-m%2F%2B%2F11153&data=04%7C01 %7Candrey.butok%40nxp.com%7Ce6deb39c9db74755362008d966e231b0%7C686ea1d3bc2b4 c6fa92cd99c5c301635%7C0%7C0%7C637653943958829167%7CUnknown%7CTWFpbGZsb3d8eyJ WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata =27x4o2UrAFCFMFx3fC7ebiv0EAsBvOEtY%2BqtZzc7Q6Q%3D&reserved=0> ][tf-m-tests patch <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr ustedfirmware.org%2Fc%2FTF-M%2Ftf-m-tests%2F%2B%2F11131%2F3&data=04%7C01%7Ca ndrey.butok%40nxp.com%7Ce6deb39c9db74755362008d966e231b0%7C686ea1d3bc2b4c6fa 92cd99c5c301635%7C0%7C0%7C637653943958829167%7CUnknown%7CTWFpbGZsb3d8eyJWIjo iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xT5 oks2R0hXyCorWsfkytx%2FCidUF8%2Bv6jMBAFxrgf2g%3D&reserved=0> ] * Trigger secure regression tests in TF-M SPE in IPC model, to simplify multi-core development/tests [TF-M patch <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr ustedfirmware.org%2Fc%2FTF-M%2Ftrusted-firmware-m%2F%2B%2F11181&data=04%7C01 %7Candrey.butok%40nxp.com%7Ce6deb39c9db74755362008d966e231b0%7C686ea1d3bc2b4 c6fa92cd99c5c301635%7C0%7C0%7C637653943958839123%7CUnknown%7CTWFpbGZsb3d8eyJ WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata =tMKKb6FHOh1pBZg62QKHBUCXaAXmv8o%2F%2Bwabe2XXOnc%3D&reserved=0> ][tf-m-tests patch <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr ustedfirmware.org%2Fc%2FTF-M%2Ftf-m-tests%2F%2B%2F11182&data=04%7C01%7Candre y.butok%40nxp.com%7Ce6deb39c9db74755362008d966e231b0%7C686ea1d3bc2b4c6fa92cd 99c5c301635%7C0%7C0%7C637653943958839123%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4 wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=j6Hf2wa 6wKm8LphtLfo8SK8kkhnazAJ%2F5RrN2eUhFIc%3D&reserved=0> ] I'd appreciate it if you can take a look at the patch sets above. Any suggestion or comment is welcome. If you have any specific requirement or suggestion of tf-m-tests enhancement, please feel free to contact Jianliang and me. Thanks in advance. Best regards, Hu Ziji

4 years, 10 months

2
3
0 0

[RFC] Decoupling tf-m-tests from TF-M

by David Hu

Hi all, As you may know, Jianliang and I are working to better decouple tf-m-tests from trusted-firmware-m repo. The purpose of the decoupling enhancement includes: * Making it more easier to integrate TF-M and port tf-m-tests * Making it more easier to develop TF-M tests, to minimize the changes to TF-M source code or build system. * Making it more flexible to re-structure tf-m-tests and minimize the impact to TF-M Previously Jianliang has decouple test case control and enable users to select single NS/S regression test case in build and test. Currently we are focusing on decoupling tf-m-tests specific config setting from TF-M. So far we have proposed the following major changes: * Decouple tf-m-tests specific config setting from trusted-firmware-m. [TF-M patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11167>][tf-m-tests patch<https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/11169/1>] * Move tf-m-tests specific configs to tf-m-tests repo from trusted-firmware-m [TF-M patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10647>][tf-m-tests patch<https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/10556>] More patch sets for decoupling are under review as well. * Decouple tf-m-tests secure log from non-secure log. Switch tf-m-tests secure log to TF-M SP log. [TF-M patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11153>][tf-m-tests patch<https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/11131/3>] * Trigger secure regression tests in TF-M SPE in IPC model, to simplify multi-core development/tests [TF-M patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11181>][tf-m-tests patch<https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/11182>] I'd appreciate it if you can take a look at the patch sets above. Any suggestion or comment is welcome. If you have any specific requirement or suggestion of tf-m-tests enhancement, please feel free to contact Jianliang and me. Thanks in advance. Best regards, Hu Ziji

4 years, 10 months

1
0
0 0

[RFC] Changing initialization Stack from PSP to MSP

by Kevin Peng

Hi dear platform maintainers, I'd like to draw your attention on this patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11165>. It changes the initialization stack from PSP to MSP. Would you please check if this change breaks your platform? Hi Thomas@IAR, would you please check the changes for IAR? Thanks. For the details of the change, please refer to the patch. Best Regards, Kevin

4 years, 10 months

1
0
0 0

Re: [TF-M] Firmware update API - MCUboot update

by Tamas Ban

Hi Suresh, I think still there is some misunderstanding here about the role of MCUboot in the update process. I try to clarify it: * MCUboot is the *bootloader* in the system, it does not care how the new images are getting installed on the device. * MCUboot defines a static allocation of the flash. There are the primary slot where the active runtime images are stored and executed from there (if upgrade startegy is XIP) and there are the secondary slot where the candidate image is written by the update client, which his part of the runtime firmware. * MCUboot is not involved at all in the process when new image is downloaded from the remote server and written to the flash (to secondary slot). * MCUboot jobs to recognize that there is a new image (magic value is set at the end of secondary slot), validates it (hash + signature) and move it (if valid) to the primary slot to make it executable (because image is XIP and linked to the address space of the primary slot) * When moving is done just jumps to the reset handler of the new image. TF-M expose a standard FWU API, which can be used by any cloud client: * FWU partition in the secure side is responsible to write the new image to the flash * Because TF-M relies on MCUBoot as a bootloader therefore the image must be placed to the right place in the flash (secondary slot) and some MCUboot specific flags must be set (magic value to indicate new image existence). Therefore in the FWU secure partition there is a MCUboot shim layer to handle these bootloader specific task * However, MCUBoot can replaced by any bootloader if one wants and then the shim layer also can be replaced to do other bootloader specific things. * In this architecture update client is responsible to download the image from the remote server and the FWU partition is responsible to write it to the right location. An implementer can choose: * Implement the FWU API on the non-secure side * Do not use FWU API, just writes the image to the right flash location and set certain flags in the flash that allows MCUboot to find the image * Replace MCUboot with custom bootloader if he wants I hope this helps! The call path in the previous mail was incorrect. The correct call path is: Update client application | | Function call V FWU API | | TF-M psa_call() etc. V FWU Partition | | Function call V MCUBoot Shim Layer | | Function call V MCUBoot user API ========================== RESTART ====================== MCUboot engine parse flash, validate new image, if there is any, and move it around to the primary slot | | V Function call, never returns Reset_Handler of new image BR, Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Suresh Marisetty via TF-M Sent: 2021. május 25., kedd 16:16 To: Andrew Thoelke <Andrew.Thoelke(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Firmware update API - MCUboot update Hi Andrew, I am thinking of two paths for the update client application: one through MCUBoot and another direct to the FWU interface. MCUBoot path is for legacy application compatibility purpose. Longer term, I am wondering if MCUBoot is needed. In embedded there is always a challenge to optimize the code size as space in storage is limited and any optimization to remove redundancies will help. Update client application | | Function call V V MCUBoot user API | Shim layer | | | | Function call | V | FWU API <------------| | | TF-M psa_call() etc. V FWU Partition | | Function call V MCUBoot user API MCUBoot engine MCUBoot image size is around 60K and thanks Suresh Marisetty Infineon Semiconductor Corporation From: Andrew Thoelke <Andrew.Thoelke(a)arm.com<mailto:Andrew.Thoelke@arm.com>> Sent: Tuesday, May 25, 2021 1:39 AM To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.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: Firmware update API - MCUboot update Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://goto.infineon.com/SocialEngineering>. Hi Suresh, > I am of the belief that MCUboot will be a very thin shim layer over the FWU API to provide the compatibility interface to legacy software and most of the work that was done earlier in MCUboot is pushed down into the FWU partition. Are you suggesting that the software stack might look like this: Update client application | | Function call V MCUBoot user API Shim layer | | Function call V FWU API | | TF-M psa_call() etc. V FWU Partition | | Function call V MCUBoot user API MCUBoot engine This looks like it has one more layer than it needs, as either: 1. The Update client application could Talk directly to the FWU API, or 2. The first MCUBoot user API could interact with an MCUBoot update partition (RoT Service), without having to tunnel the MCUBoot API over the FWU API. The latter might not be straightforward - I am not sure that anyone has reviewed the two APIs for this purpose. Are you only considering this software stack for a system where touching the update client application source code is not possible (needed for option #1 above)? - and you also cannot introduce a custom MCUBoot RoT Service partition (option #2 above) so you want to reuse TF-M's existing FWU API and partition? Regards, Andrew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Suresh Marisetty via TF-M Sent: 25 May 2021 02:37 To: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@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] Firmware update API - MCUboot update Hi Sherry, Thanks for the info. Wondering if there is some documentation or powerpoint explaining how the MCUBoot is changed to accommodate the FWU API. Details that would help: 1. How the MCUboot works without the FWU API - natively 2. How the MCUBoot needs to be modified to leverage from FWU API 3. What components are retained in MCUBoot ex: image format, signing, metadata, tools I am of the belief that MCUboot will be a very thin shim layer over the FWU API to provide the compatibility interface to legacy software and most of the work that was done earlier in MCUboot is pushed down into the FWU partition. The other way to look at it is: If somebody wants to replace MCUboot with a simple BL to integrate it tightly into TFM, what would that look like? thanks Suresh Marisetty Infineon Semiconductor Corporation From: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>> Sent: Thursday, May 13, 2021 7:51 PM To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.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: Firmware update API - MCUboot update Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://goto.infineon.com/SocialEngineering>. Hi Suresh, The MCUboot update functionality is about validating the existing images on the device which is different from that of the firmware update service which follows mostly with the PSA Firmware Update API spec<https://developer.arm.com/documentation/ihi0093/latest/>. We designed a shim layer between the firmware update partition and bootloader. A specific bootloader can be ported into the firmware update partition via that shim layer. Please refer to the firmware update service document<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/techn…>. In the MCUboot based shim layer implementation, it calls some user/public APIs provided by MCUboot to achieve its functionality. For example, the Firmware Update API spec describes that psa_fwu_install() API should validate the image or defer the validation to a system reboot. In the MCUboot shim layer implementation, it calls the boot_write_magic() API to mark the image as a candidate image for MCUboot and defers the image validation to a system reboot. Please refer to this link<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…>. Can you please provide more specific suggestion or questions? Regards, Sherry Zhang From: Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com> <Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>> Sent: Thursday, May 13, 2021 11:40 PM To: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@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: Firmware update API - MCUboot update Hi Sherry, Please take a closer look at the MCUboot and TFM might want to have a clear position/distinction between these two and how to transition from MCUboot update to this mechanism or it could be that they complement each other. thanks Suresh Marisetty Infineon Semiconductor Corporation From: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>> Sent: Wednesday, May 12, 2021 8:55 PM To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.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: Firmware update API - MCUboot update Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://goto.infineon.com/SocialEngineering>. Hi Suresh, The firmware update service APIs are for updating the firmware. The functionalities of these APIs includes loading the image into its target device(flash), verifying the image and installing it and so on. The user can call the these APIs to achieve update images. For example, in the integration of TF-M and the FreeRTOS OTA<https://github.com/Linaro/amazon-freertos/blob/tfm-fwu/libraries/abstractio…>, the OTA agent calls the firmware update service APIs to achieve an image update remotely. I guess that the "MCUboot update services" you mentioned refers to the functionality of MCUboot which acts as a bootloader. As a bootloader, it can verify the image which already exists on the device and chose the right image to start up. But it cannot, for example, load the image into device or control the image update process. The firmware update partition calls some user APIs provided by MCUboot to cooperate with it. You can refer to https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/techn…. Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Suresh Marisetty via TF-M Sent: Thursday, May 13, 2021 11:09 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Firmware update API - MCUboot update Hi, I would like to see if there is any guidance/documentation on how to coordinate between the firmware update services API with that of MCUboot. Does the use of this API make the MCUboot update services redundant? thanks Suresh Marisetty Infineon Semiconductor Corporation Lead Member of Technical Staff CYSC CSS ICW SW SSE Mobile: +5103863997 Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>

4 years, 10 months

2
4
0 0

Re: [TF-M] Out-of-tree secure partition build support

by David Hu

Hi all, Out-of-tree secure partition build is enabled in TF-M. I'd appreciate it if you are interested to try it in your daily development. Any feedback is welcome! Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Thursday, August 12, 2021 11:54 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Out-of-tree secure partition build support Hi all, Can I ask you to review the following patch set to enable out-of-tree secure partition build in TF-M? https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10562/ The purpose is to enable developers to develop their own secure partitions outside TF-M repo. Developers can maintain their own code and repos, independently. Developers can pass their out-of-tree secure partition paths via TF-M command line, to build out-of-tree partitions with TF-M together. For more details, please check the updated document: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10696 Suggestions and comments are welcome! Best regards, Hu Ziji

4 years, 10 months

1
0
0 0

Test configurations refinements

by Jianliang Shen

Hi all. I have introduced the topic of test configurations refinements in the tech forum on August 5. With this new feature, you can build single test case to decrease the image size and the time to wait irrelevant test cases running when debugging. You can use all the 22 new flags in test repo: TEST_NS TEST_S TEST_NS_ATTESTATION TEST_NS_AUDIT TEST_NS_CRYPTO TEST_NS_ITS TEST_NS_PS TEST_NS_PLATFORM TEST_NS_FWU TEST_NS_IPC TEST_NS_CORE TEST_NS_QCBOR TEST_NS_T_COSE TEST_NS_MULTI_CORE TEST_NS_SLIH_IRQ TEST_NS_FLIH_IRQ TEST_S_ATTESTATION TEST_S_AUDIT TEST_S_CRYPTO TEST_S_ITS TEST_S_PS TEST_S_PLATFORM TEST_S_FWU TEST_S_IPC You can easily use the command below to start single test like NS attestation test case: cmake -S . -B cmake_build -DTFM_PLATFORM=arm/mps2/an521 \ -DTFM_TOOLCHAIN_FILE=toolchain_GNUARM.cmake \ -DCMAKE_BUILD_TYPE=Release \ -DTFM_PSA_API=ON \ -DTEST_NS_ATTESTATION=ON Meanwhile, you may receive the warning messages when your test inputs are not supported on the platform. Here are the patches about this change, any suggestions or improvements are welcome in code review. l 10767: Build: Control single test without TEST_S/TEST_NS [TF-M repo] https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10767 l 10768: Build: Control single test without TEST_S/TEST_NS [Test repo] | https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/10768 Best Regards Jianliang Shen

4 years, 10 months

1
2
0 0

Re: [TF-M] Technical Forum call - Aug 19

by Kevin Peng

Hi Anton, Did you missed my topic below - brief update on the interrupt status in TF-M and an introduction on how to use/enable it Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, August 18, 2021 11:13 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Technical Forum call - Aug 19 The agenda for the forum: 1. "Of out-of-tree Secure Partition build" by David Hu, 2. AOB See you, Anton From: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>> Sent: Wednesday, August 18, 2021 2:30 AM To: 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: Technical Forum call - Aug 19 Hi Anton, I'd like to introduce the proposal of out-of-tree Secure Partition build. It may take 15 ~ 20 mins. Best regards, Hu Ziji 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: Tuesday, August 17, 2021 5:49 PM To: 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] Technical Forum call - Aug 19 Hi Anton, I'd like to give a brief update on the interrupt status in TF-M and an introduction on how to use/enable it. Would take ~20 min. Best Regards, Kevin 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: Tuesday, August 17, 2021 5:26 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] Technical Forum call - Aug 19 Hi, The next Technical Forum is planned on Thursday, Aug 19 at 7:00-8: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

2
1
0 0

[Request Platform Support] Abstracted MMIO HAL

by Ken Liu

Hi everyone, The existing HAL interface for isolation hardware is not unified, we have to call several interfaces to setup isolation boundaries. Hence, a deeper abstracted interface are provided. Here are the details: - It assumes the hardware resources usages are decided by system designer. Hence there are couple of listed hardware data in the platform code, now most of them are defined in C sources. - When a partition is referencing peripheral (represented as MMIO in FFM), the manifest tooling would link specified resources with the data defined in platform. Now it is using a naming pattern, to let the partition found the resources defined above (now it uses linker to do this). - A HAL API 'tfm_hal_bind_partition' is called when a partition runtime structure is created. This API tells partition info to platform, let platform return an encoded 'p_boundaries' for SPM binding partition with platform. - When boundaries related operations happen in future, SPM would delivery this 'p_boundaries' back to platform, let platform perform boundary setup and check, such as boundary switch or memory check. SPM won't care about the hardware specific settings any more, such as privilged, non-secure/secure and how many MMIO the partition claimed, even the MPU/MPC/PPC things. - Resources defined in platform sources but not referenced would be stripped by toolchain flag. Resources not defined but referenced by partition would generate a linker error, as symbol can't be resolved. We created a patch to showcase the usage on AN521: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11036 This patch applies a simple encoding for all isolation levels. You can check how the p_boundaries is used under different isolation levels. Platform can use other encoding mechanism if applicable. Now come to the request: Please review this patch, and port similar HAL API into your platform. We are maintaining the default platforms such as AN521, AN519 and MUSCA_B1, but it need so much effort on port to all the platforms. Current CI cannot pass on this patch (as it contains modification for one platform only), our first goal is to let CI pass build on all checked platforms, and then please platform owner ensures it works on your platform. Any feedbacks are welcome. Thank you very much! /Ken

4 years, 10 months

1
0
0 0

Re: [TF-M] Technical Forum call - Aug 19

by David Hu

Hi Anton, I'd like to introduce the proposal of out-of-tree Secure Partition build. It may take 15 ~ 20 mins. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Peng via TF-M Sent: Tuesday, August 17, 2021 5:49 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 - Aug 19 Hi Anton, I'd like to give a brief update on the interrupt status in TF-M and an introduction on how to use/enable it. Would take ~20 min. Best Regards, Kevin 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: Tuesday, August 17, 2021 5:26 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] Technical Forum call - Aug 19 Hi, The next Technical Forum is planned on Thursday, Aug 19 at 7:00-8: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

2
1
0 0

Re: [TF-M] Technical Forum call - Aug 19

by Kevin Peng

Hi Anton, I'd like to give a brief update on the interrupt status in TF-M and an introduction on how to use/enable it. Would take ~20 min. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Tuesday, August 17, 2021 5:26 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Technical Forum call - Aug 19 Hi, The next Technical Forum is planned on Thursday, Aug 19 at 7:00-8: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

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M