- TF-M - lists.trustedfirmware.org

by Andrej Butok

Hi Antonio, > TF-M Crypto has moved to use the same API as the latest available *release* of Mbed Crypto which is Mbed Crypto 1.0.0 If to follow the latest development branch of Mbed-Crypto, actually it has started using of "handles" instead of "slots" (the obsolete version is using handles). So by using the old mbed-Crypto release, you have downgraded the Crypto API. Please use the latest available mbed-Crypto (do not afraid - it is functional, checked) and avoid this created mess and desynchronization between all PSA related projects. > The psa-arch-test team is in the process of providing an update on the master branch The master branch, as was declared by PSA Test Suite team, is not used for PSA Functional API certification. Instead, as was declared by PSA Test Suite team, it have to be used the ew_beta0 branch. Please clarify what PSA-TestSuite branch must be used with TFM now? Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Monday, May 27, 2019 6:22 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Old Mbed-Crypto library? Hi Andrej, TF-M Crypto has moved to use the same API as the latest available *release* of Mbed Crypto which is Mbed Crypto 1.0.0 . Mbed Crypto is a reference implementation of the PSA Crypto API, which are under active development. TF-M Crypto will align to newest release of Mbed Crypto when they will become available; these new releases will incorporate the new features which are developed as part of the PSA Crypto API, and there will be cases where the new features will break legacy code (i.e. API changes). Regarding the change that you mention, i.e. psa_key_slot_t vs psa_key_handle_t . The concept of psa_key_handle_t that TF-M Crypto is using now is indeed a newer (updated) concept introduced with later versions of the PSA Crypto API to replace the outdated concept of psa_key_slot_t. For example, if you look at the current latest development version of the PSA Crypto API, you will see that psa_key_handle_t is used to handle keys. This is an example of a breaking change in the API that has been introduced by newer releases of the PSA Crypto API. You are right, this change will break regression / PSA API compliance tests, in fact as part of the latest set of patches you can see that the Regression tests are upgraded to use the new concept of psa_key_handle_t instead of psa_key_slot_t. From these updated tests, you can get an idea of how to use the psa_key_handle_t. After this update, TF-M Crypto can't support the PSA API compliance tests (ACK) which were run previously (i.e. the ew_beta0 branch). The psa-arch-test team is in the process of providing an update on the master branch which will enable TF-M Crypto to run compliance tests from there. This should happen in the next couple of weeks. Please let me know in case you need any more clarification. Best regards, Antonio ________________________________ 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: 27 May 2019 12:52 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Old Mbed-Crypto library? Hello, tfm_build_instruction.rst tells to use mbed-Crypto instead of mbedTLS: git clone https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… -b mbedcrypto-1.0<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>.0 But the issue is that it references to the obsolete (3 month old) Mbed-Crypto library. Also, it looks like this old MbedCrypto has downgraded TFM/PSA Crypto API (from key-slot to key-handle) => this is step back in PSA TFM API, which should break crypto regression and PSA tests. We do not want to downgrade our SDK MbedCrypto, better to freeze TFM. Any plans to use the last Crypto Lib and to revert the PSA API degradation? Thanks, Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 5 months

1
0
0 0

Re: [TF-M] Old Mbed-Crypto library?

by Antonio De Angelis

Hi Andrej, TF-M Crypto has moved to use the same API as the latest available *release* of Mbed Crypto which is Mbed Crypto 1.0.0 . Mbed Crypto is a reference implementation of the PSA Crypto API, which are under active development. TF-M Crypto will align to newest release of Mbed Crypto when they will become available; these new releases will incorporate the new features which are developed as part of the PSA Crypto API, and there will be cases where the new features will break legacy code (i.e. API changes). Regarding the change that you mention, i.e. psa_key_slot_t vs psa_key_handle_t . The concept of psa_key_handle_t that TF-M Crypto is using now is indeed a newer (updated) concept introduced with later versions of the PSA Crypto API to replace the outdated concept of psa_key_slot_t. For example, if you look at the current latest development version of the PSA Crypto API, you will see that psa_key_handle_t is used to handle keys. This is an example of a breaking change in the API that has been introduced by newer releases of the PSA Crypto API. You are right, this change will break regression / PSA API compliance tests, in fact as part of the latest set of patches you can see that the Regression tests are upgraded to use the new concept of psa_key_handle_t instead of psa_key_slot_t. From these updated tests, you can get an idea of how to use the psa_key_handle_t. After this update, TF-M Crypto can't support the PSA API compliance tests (ACK) which were run previously (i.e. the ew_beta0 branch). The psa-arch-test team is in the process of providing an update on the master branch which will enable TF-M Crypto to run compliance tests from there. This should happen in the next couple of weeks. Please let me know in case you need any more clarification. Best regards, Antonio ________________________________ 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: 27 May 2019 12:52 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Old Mbed-Crypto library? Hello, tfm_build_instruction.rst tells to use mbed-Crypto instead of mbedTLS: git clone https://github.com/ARMmbed/mbed-crypto.git -b mbedcrypto-1.0<https://github.com/ARMmbed/mbed-crypto.git%20-b%20mbedcrypto-1.0>.0 But the issue is that it references to the obsolete (3 month old) Mbed-Crypto library. Also, it looks like this old MbedCrypto has downgraded TFM/PSA Crypto API (from key-slot to key-handle) => this is step back in PSA TFM API, which should break crypto regression and PSA tests. We do not want to downgrade our SDK MbedCrypto, better to freeze TFM. Any plans to use the last Crypto Lib and to revert the PSA API degradation? Thanks, Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 5 months

1
0
0 0

Old Mbed-Crypto library?

by Andrej Butok

Hello, tfm_build_instruction.rst tells to use mbed-Crypto instead of mbedTLS: git clone https://github.com/ARMmbed/mbed-crypto.git -b mbedcrypto-1.0<https://github.com/ARMmbed/mbed-crypto.git%20-b%20mbedcrypto-1.0>.0 But the issue is that it references to the obsolete (3 month old) Mbed-Crypto library. Also, it looks like this old MbedCrypto has downgraded TFM/PSA Crypto API (from key-slot to key-handle) => this is step back in PSA TFM API, which should break crypto regression and PSA tests. We do not want to downgrade our SDK MbedCrypto, better to freeze TFM. Any plans to use the last Crypto Lib and to revert the PSA API degradation? Thanks, Andrej Butok

6 years, 5 months

1
0
0 0

Re: [TF-M] Trusted boot - rollback protection

by David Brown

On Mon, Mar 11, 2019 at 01:43:19PM +0000, Tamas Ban via TF-M wrote: >Please see the following link for a design proposal on anti-rollback protection in trusted boot: > >https://developer.trustedfirmware.org/w/tf_m/design/trusted_boot/rollback_p… Somewhat related, as I've been working through a prototype implementation of SUIT, the SUIT manifest also wants what they call a "sequence number", which is a monotonically increasing number associated with each version. They've kind of decided they don't want to have to do anything like semantic version parsing as part of the firmware upgrade. I think this sequence number serves the same purpose as this security counter (except that the sequence number is required to increase with each software relase). One of the goals of the MCUboot community is to make sure that however the SUIT manifest is implemented, it must be semantically the same as the existing TLV-format manifest. An easy solution is to just treat the existing version as a 32-bit number (ignoring the build-id, which I think is supposed to be the case, anyway). As far as the possibility of re-using the same security counter value, I don't think that is something that should be done. In general, it isn't possible to know where security bugs will be found in an image. If we always increase the security counter value, someone still running the immediately following image will be prevented from rolling back to the version with the security flaw, whereas if we reused the values, it might be necessary to try to force them to upgrade to a new version that has the counter increased. Also, I think it is important to clarify that the security counter is not required for anti-rollback, it only protects the anti-rollback implementation from a specific threat: something that is able to replace the primary firmware image outside of the control of the bootloader. The cost is that implementing a security counter generally requires specific hardware just for that purpose. An entirely software anti-rollback protects against other threats, including the common case of using the ordinary firmware upgrade process. David

6 years, 5 months

2
3
0 0

Re: [TF-M] TFM and FreeRTOS

by Andrej Butok

Hello, So, the RTX was replaced by FreeRTOS (regression and psa-tests passed). Required changes: 1) Use CMSIS-FreeRTOS adapter from: https://github.com/ARM-software/CMSIS-FreeRTOS 2) Do not call os_wrapper_join_thread()/osThreadJoin() and do not use osThreadJoinable flag. It is not supported by FreeRTOS 3) Add missing osThreadExit(). 4) Add osDelay(1) to tfm_sst_run_test(), as FreeRTOS free some allocated resources only in the idle task. 5) Disable TFM_NS_CLIENT_IDENTIFICATION to avoid SVC conflict. 5) Other minor changes. Proposals for general TFM code: 1) Delete os_wrapper_join_thread()/osThreadJoin() as it is optional. It works without it and not supported by all RTOSes. 2) Add missing osThreadExit() to test_task_runner(). 3) Do not call each SST test in separate task, or to allow switching to idle task after each SST test. 4) Find other TFM_NS_CLIENT_IDENTIFICATION mechanism, which will not use SVC. Thanks, Andrej Butok -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Friday, May 3, 2019 9:36 AM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] [EXT] Re: TFM and FreeRTOS Hello, So, even if the unique User ID is optional, it is mandatory for the case when different NS users must have different security asset policies for SST resources. Is it possible to find another mechanism for the user ID assignment which does not use SVC? To avoid unwanted limitation for FreeRTOS and any other NS application using SVC. Thanks, Andrej -----Original Message----- From: Miklos Balint <Miklos.Balint(a)arm.com> Sent: Tuesday, April 30, 2019 5:19 PM To: Andrej Butok <andrey.butok(a)nxp.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: [TF-M] [EXT] Re: TFM and FreeRTOS Caution: EXT Email Hi Andrej, Your interpretation is correct: if NS client identification is disabled, all non-secure threads are assigned the default non-secure client id (-1). That means that secure services cannot differentiate between various non-secure threads, i.e. they would all be provided the same access policies when requesting secure services. This is in line with PSA Firmware Framework. As described in chapter 3.3.3 of PSA FF 1.0 beta Release 0, "In implementations where NSPE client_id values are provided by the SPM, the same negative client_id must be used for all connections." Note that according to that specification each connection and message would still have their own unique handles - see chapter 3.3.4. Note also that this does not impact the client ID assignments for secure partitions, so any service would be able to identify if it was called by a non-secure entity or a secure one, and if a secure one, then which one. Let me know if you need further assistance in this matter. Regards Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 25 April 2019 12:47 To: David Hu (Arm Technology China) <David.Hu(a)arm.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] [EXT] Re: TFM and FreeRTOS Hi David, OK. We may try to limit FreeRTOS to the case when it starts and runs only in non-secure world and its tasks will call secure world only via PSA/TFM API. In this case, if I understand well, to avoid conflict for non-secure SVC, it is enough to disable TFM_NS_CLIENT_IDENTIFICATION. It means that all user tasks will be assigned to the default user id = DEFAULT_NS_CLIENT_ID. What does it mean? How does it limits the functionality? Is it OK from PSA point of view? Thanks, Andrej -----Original Message----- From: David Hu (Arm Technology China) <David.Hu(a)arm.com> Sent: Thursday, April 25, 2019 11:26 AM To: Andrej Butok <andrey.butok(a)nxp.com>; tf-m(a)lists.trustedfirmware.org Subject: [EXT] Re: [TF-M] TFM and FreeRTOS Caution: EXT Email Hi Andrej, I guess that you may ask about the SVCalls communication between secure world and non-secure world in FreeRTOS. If I misunderstood your question, please ignore the following. In my very own opinion, FreeRTOS has a different concept of how to manage secure stack/context from TF-M does. FreeRTOS prefers to allocate and manage a dedicated secure stack/context for each non-secure task requiring secure service. In its implementation, each time when it does context switch, it invokes SVCalls to also switch the secure stack/context for the next non-secure task. FreeRTOS implements several own APIs to accomplish those functionalities. By contrast, TF-M as a trusted firmware, naturally, manages all the secure resource by its own. Therefore, there is no such dedicated stack in secure world mapping to each non-secure task. Currently, TF-M implements CMSIS RTOS thread context management APIs to execute some management work between non-secure world and secure world, on Armv8-M core. Hope it can hlep you. Best regards, Hu Ziji On 4/25/2019 3:45 PM, Andrej Butok via TF-M wrote: > Hello, > > Do you know about any existing port of FreeRTOS (instead of RTX) to TFM? Did somebody a feasibility study? > I have just started to look at it, and immediately detected a conflict, both are using Supervisor Calls (SVC) for own needs. > > Thanks, > Andrej > > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 5 months

1
0
0 0

Fixing implicit casting of C enumeration in TF-M: design document

by Hugues De Valon

Hi All, Please find under the following link: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1040 the review of a design document which aim is to fix the implicit casting happening with enumerations in TF-M. Feel free to add any comments you want on the review! Kind regards, Hugues IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 5 months

1
0
0 0

TF-M Crypto service design document

by Antonio De Angelis

Hi all, I have uploaded the design document for the TF-M Crypto service at the following Gerrit code review in RST format: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1023 It can be possible to render the HTML format of the design document by checking out the patch above and build the docs (in particular, by building the install_userguide target) Comments are welcome, here in this thread or preferably in the Gerrit review for better tracking. Thanks, Antonio

6 years, 5 months

1
0
0 0

SST 512B write support?

by Andrej Butok

Hello, Current TFM SST service supports 1, 2, 4 and 8 Byte minimum write. Do you have any plan to add the 512 Byte minimal write support to the TFM SST? LPC55S69 Flash has the 512Bytes program size. Guess, all flash modules with ECC has the same requirement. Thanks, Andrej Butok

6 years, 5 months

1
0
0 0

Update to contribution guide

by Ashutosh Singh

Hi, Contribution guide has been updated to reflect current way of working. More details have been added to clarify the steps. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1007/ Feedback welcome and appreciated! Thanks, Ashu

6 years, 5 months

1
0
0 0

Re: [TF-M] FW: Trusted boot - rollback protection

by David Brown

On Mon, Apr 15, 2019 at 02:52:56PM +0000, Tamas Ban via TF-M wrote: >Actually the design doc propose to use a distinct security counter from image version (ih_ver in header). But in the most simple case this security counter can be derived from the image version, to have the exact same value (ignoring the build number). > >The image signature cover these continues blocks in memory: >- image header >- image >- some part of TLV section (currently not covered, but due to multi image support it is planned to introduce a signed TLV section) > >Because these are contiguous regions in the memory it is not possible >to place only the (header + TLV section) to the trusted memory but >miss out the image itself (at least I cannot see how to solve) Could the trusted memory contain a version field, and perhaps a hash of the image? David

6 years, 5 months

1
0
0 0

Re: [TF-M] [EXT] Re: TFM and FreeRTOS

by Miklos Balint

Hi Andrej, Your interpretation is correct: if NS client identification is disabled, all non-secure threads are assigned the default non-secure client id (-1). That means that secure services cannot differentiate between various non-secure threads, i.e. they would all be provided the same access policies when requesting secure services. This is in line with PSA Firmware Framework. As described in chapter 3.3.3 of PSA FF 1.0 beta Release 0, "In implementations where NSPE client_id values are provided by the SPM, the same negative client_id must be used for all connections." Note that according to that specification each connection and message would still have their own unique handles - see chapter 3.3.4. Note also that this does not impact the client ID assignments for secure partitions, so any service would be able to identify if it was called by a non-secure entity or a secure one, and if a secure one, then which one. Let me know if you need further assistance in this matter. Regards Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 25 April 2019 12:47 To: David Hu (Arm Technology China) <David.Hu(a)arm.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] [EXT] Re: TFM and FreeRTOS Hi David, OK. We may try to limit FreeRTOS to the case when it starts and runs only in non-secure world and its tasks will call secure world only via PSA/TFM API. In this case, if I understand well, to avoid conflict for non-secure SVC, it is enough to disable TFM_NS_CLIENT_IDENTIFICATION. It means that all user tasks will be assigned to the default user id = DEFAULT_NS_CLIENT_ID. What does it mean? How does it limits the functionality? Is it OK from PSA point of view? Thanks, Andrej -----Original Message----- From: David Hu (Arm Technology China) <David.Hu(a)arm.com> Sent: Thursday, April 25, 2019 11:26 AM To: Andrej Butok <andrey.butok(a)nxp.com>; tf-m(a)lists.trustedfirmware.org Subject: [EXT] Re: [TF-M] TFM and FreeRTOS Caution: EXT Email Hi Andrej, I guess that you may ask about the SVCalls communication between secure world and non-secure world in FreeRTOS. If I misunderstood your question, please ignore the following. In my very own opinion, FreeRTOS has a different concept of how to manage secure stack/context from TF-M does. FreeRTOS prefers to allocate and manage a dedicated secure stack/context for each non-secure task requiring secure service. In its implementation, each time when it does context switch, it invokes SVCalls to also switch the secure stack/context for the next non-secure task. FreeRTOS implements several own APIs to accomplish those functionalities. By contrast, TF-M as a trusted firmware, naturally, manages all the secure resource by its own. Therefore, there is no such dedicated stack in secure world mapping to each non-secure task. Currently, TF-M implements CMSIS RTOS thread context management APIs to execute some management work between non-secure world and secure world, on Armv8-M core. Hope it can hlep you. Best regards, Hu Ziji On 4/25/2019 3:45 PM, Andrej Butok via TF-M wrote: > Hello, > > Do you know about any existing port of FreeRTOS (instead of RTX) to TFM? Did somebody a feasibility study? > I have just started to look at it, and immediately detected a conflict, both are using Supervisor Calls (SVC) for own needs. > > Thanks, > Andrej > > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 6 months

2
1
0 0

Re: [TF-M] Avoid osThreadJoin()

by Jamie Fox

Hi Andrej, The idea of the OS wrapper layer is to abstract the underlying OS, so that the test app can use generic wrapper APIs, which are implemented using OS-specific APIs. In os_wrapper_rtx.c, we provide an example implementation that targets the CMSIS-RTOS2 APIs for RTX. As osThreadJoinable is not supported by FreeRTOS, you can remove that attribute in your port, and implement os_wrapper_join_thread() as a no-op. We use semaphores for synchronisation in the test app anyway, so os_wrapper_join_thread() only needs to be implemented if threads are joinable and so need join() to be called to free up resources associated with the thread. I do think we could make the OS wrapper layer a bit more generic though. We could replace the only call to os_wrapper_join_thread() that currently exists with a call to a new function os_wrapper_delete_thread(), which is defined to release the resources associated with a thread context. For CMSIS-RTOS2 this can be empty because this happens automatically, but for other RTOS APIs there may be some delete() function that needs to be called. Let me know what you think. Best wishes, Jamie -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 02 May 2019 15:04 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Avoid osThreadJoin() Hello, The TFM test applications are using CMSIS-RTOS2 API. And this is good. But could you delete os_wrapper_join_thread()and avoid using of osThreadJoin(). If I understand well, its support by RTOS tasks is optional (via osThreadJoinable flag). The problem is that the osThreadJoin() functionality is not supported by FreeRTOS (https://arm-software.github.io/CMSIS-FreeRTOS/General/html/tech_data.html). It is critical obstacle. Could you tell what are you going to do with this requirement? To understand, if to continue with a FreeRTOS port. Thank you Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 6 months

1
0
0 0

Avoid osThreadJoin()

by Andrej Butok

Hello, The TFM test applications are using CMSIS-RTOS2 API. And this is good. But could you delete os_wrapper_join_thread()and avoid using of osThreadJoin(). If I understand well, its support by RTOS tasks is optional (via osThreadJoinable flag). The problem is that the osThreadJoin() functionality is not supported by FreeRTOS (https://arm-software.github.io/CMSIS-FreeRTOS/General/html/tech_data.html). It is critical obstacle. Could you tell what are you going to do with this requirement? To understand, if to continue with a FreeRTOS port. Thank you Andrej Butok

6 years, 6 months

1
0
0 0

Re: [TF-M] NS application privilege mode

by Miklos Balint

Hi Andrej, TF-M has no requirement on NS thread execution being unprivileged, nor is it mandated by PSA. It is one of a set of measures that make non-secure thread isolation possible, reduce attack surface and provide a degree of tolerance against programming errors, but its absence does not invalidate the security measures provided by TF-M, so it is a fully valid implementation to make NSPE a single protection domain and all non-secure code execution privileged. Regards Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 02 May 2019 14:19 To: TF-M(a)lists.trustedfirmware.org Subject: [TF-M] NS application privilege mode Hello, May a non-secure TFM user application stay in the privilege mode after start-up? It's needed, as some system registers are accessible only in the privilege mode. Asking, because the TFM NS Musca start-up code is switching to the unprivileged mode from very beginning: MRS R0, control ; Get control value ORR R0, R0, #1 ; Select switch to unprivilage mode ORR R0, R0, #2 ; Select switch to PSP MSR control, R0 Hope, it is not mandatory. Thanks, Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 6 months

2
1
0 0

NS application privilege mode

by Andrej Butok

Hello, May a non-secure TFM user application stay in the privilege mode after start-up? It's needed, as some system registers are accessible only in the privilege mode. Asking, because the TFM NS Musca start-up code is switching to the unprivileged mode from very beginning: MRS R0, control ; Get control value ORR R0, R0, #1 ; Select switch to unprivilage mode ORR R0, R0, #2 ; Select switch to PSP MSR control, R0 Hope, it is not mandatory. Thanks, Andrej Butok

6 years, 6 months

1
0
0 0

TF-M Cooperative Scheduler Design - Scheduling Rules

by Ashutosh Singh

Hi, This is a proposal that introduces scheduling rules in TF-M. Introduction: On ArmV8-M CPUs, NSPE and SPE share the same physical processing element(PE). A TF-M enabled system need to be able to handle asynchronous events (interrupts) regardless of current security state of the PE; and that may lead to scheduling decisions. This introduces significant complexity into TF-M. To keep the integrity of (NSPE and SPE) schedulers and call paths between NSPE and SPE, following set of rules are imposed on the TF-M scheduler design. https://developer.trustedfirmware.org/w/tf_m/design/cooperative_scheduling/ Feedback welcome! Thanks, Ashu

6 years, 6 months

1
0
0 0

Re: [TF-M] Non-secure interrupt handling design proposal

by Mate Toth-Pal

Hi All, The parts that refer to the BASEPRI_NS register being set on return from Secure services has been removed from the document (marked with strikethrough), as the attack surfaces introduced by not doing it are mitigated by the veneer stack checking on secure function entry. Sorry for the inconvenience. Best regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Mate Toth-Pal via TF-M Sent: 29 April 2019 15:21 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Non-secure interrupt handling design proposal Hi All, The design proposal for the Non-secure interrupt handling is available for review at the following link: https://developer.trustedfirmware.org/w/tf_m/design/ns_interrupt_handling/ Please share your thoughts in this mail thread. Thank you! Best regards, Mate -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 6 months

1
0
0 0

Non-secure interrupt handling design proposal

by Mate Toth-Pal

Hi All, The design proposal for the Non-secure interrupt handling is available for review at the following link: https://developer.trustedfirmware.org/w/tf_m/design/ns_interrupt_handling/ Please share your thoughts in this mail thread. Thank you! Best regards, Mate

6 years, 6 months

1
0
0 0

The cmake response file patch

by Ken Liu (Arm Technology China)

Hi, There was a cmake response file patch to fix the linker error especially in windows: https://review.trustedfirmware.org/c/trusted-firmware-m/+/237 In this patch I set proper flags for linkers, but also enable response file as default, which caused some concerns about: is the response file option stable enough, will it break the build? So I created an updated one, which just set correct response file switch for linkers, and do not enable response file as default. In the case if ARMCLANG response is enabled by cmake automatically, cmake could apply correct response flag for ARMCLANG: https://review.trustedfirmware.org/c/trusted-firmware-m/+/925 Because they are pushed towards different branches, so a new gerrit item is generated which lost the history...The only difference with previous one is removed below line : set(CMAKE_${lang}_USE_RESPONSE_FILE_FOR_OBJECTS 1) The reason I raise this patch is because, this problem happens every time in my PC so I have to cherry-pick this patch before building anything. I had seen someone got the same issue, and want to check how you solve this. Call for volunteers to help verifying this patch (925) in your side and provide feedback to ensure it will not break the building, is there anyone could help? Just cherry-pick this patch into your environment is OK. Thanks. -Ken

6 years, 6 months

1
0
0 0

Platform: ioctl function for platform-specific services

by Miklos Balint

Hi all, I've created a change as a follow-on from the mail discussion below to provide a design pattern proposal: IOCTL for platform-specific services. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/951/ Brief problem statement: Some platforms required services and HAL functions that were not generic to warrant their dedicated generic HAL API functions as that implied a requirement for *all* platforms to implement - essentially stub - the implementation if the functionality was not applicable to that platform. The existing solution doesn't scale so I propose to introduce a single mandatory function that serves as a platform-specific wrapper/arbiter for services that are specific to a single platform, or a family of similar platforms. Note that at present the change IS the design proposal - I felt it would make more sense to present it this time as code changes and documentation updates instead of a single linear design document. Let me know your thought in this mail thread for generic observations or on the review page for specific details of the implementation. Thanks Regards, Miklos -----Original Message----- From: Michel JAOUEN <michel.jaouen(a)st.com> Sent: 11 April 2019 17:38 To: Miklos Balint <Miklos.Balint(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: Platform: Create platform service for pin functions Hello, You should detail your proposal with single entry. It should help to implement the function really required for dedicated platform. Regards -----Original Message----- From: Miklos Balint <Miklos.Balint(a)arm.com> Sent: jeudi 11 avril 2019 17:28 To: Michel JAOUEN <michel.jaouen(a)st.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: Platform: Create platform service for pin functions Michel, I agree there is a need for a more generic design pattern for such platform-specific features. I think that there should be a single entry point for any platform specific service request to the platform/ directory and each platform should/could list the specific features it supports. Then the specific function type would be encoded in an invec to the service request. But I think a more detailed design proposal is needed with enough room for discussion before committing to a new pattern, and I'd prefer to avoid introducing platform dependencies in the services/ folder. That folder should ideally just have an indirection across HAL to a platform-specific service request arbiter. Any opinions or should I produce a more detailed proposal to show what I mean? Regards Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Michel JAOUEN via TF-M Sent: 11 April 2019 13:57 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Platform: Create platform service for pin functions I see that there is https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/825/ On review , it adds some dummy functions for the platform not requiring these services Can we think about introducing some configuration on platform basis. As example , I post https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/854/ Best regards From: Michel JAOUEN Sent: mercredi 10 avril 2019 13:05 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: Platform: Create platform service for pin functions Hello, I noticed the merge of this api, which seems require only for platform Musca_a. This create the need to implement dummy functions for the other platform. would it be better to make this configurable for each platform ? I think for the interface connected to platform partition, it is important to have a flexibility. As example some platform , may require an API requesting a pin to be configureable from non secure . Best regards -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 6 months

1
0
0 0

Re: [TF-M] TF-M ARM GCC PSA Test 014 fail

by Jamie Fox

Hi Stanislav, Thanks for reporting the issue. As the issue seems to be in the PSA Tests rather than TF-M, please can you report it directly to the psa-arch-tests project here https://github.com/arm-software/psa-arch-tests as we in the TF-M team do not maintain that code. Best wishes, Jamie -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Stanislav Jancik via TF-M Sent: 25 April 2019 12:51 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] TF-M ARM GCC PSA Test 014 fail Hi, I use "7 2018-q2-update" ARMGCC compiler. The PSA Tests code works when it is compiled by ARMGLANG, but a fail occurs when the same code is compiled by ARMGCC. Issue: When TEST: 414 runs, I've got secure violation fault. See report bellow: TEST: 414 | DESCRIPTION: Optional APIs not supported check [Info] Executing tests from non-secure Optional PS APIs are not supported. [Check 1] Call to create API should fail as API not supported [Check 2] Create valid storage with set API [Check 3] Call to set_extended API call should fail [Check 4] Verify data is unchanged Oops... Secure fault!!! You're not going anywhere! Reason: The valtest_entry_p014 is overwritten by read_buff variable and this caused this fail. Workaround: When I changed read_buff declaration in test_p014.c from static uint8_t read_buff[TEST_BUFF_SIZE/4] = {0}; to static uint32_t read_buff[TEST_BUFF_SIZE/4] = {0}; the code is running correctly. But I think, that it should be officially fixed. Best Regards Stanislav -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 6 months

1
0
0 0

TF-M ARM GCC PSA Test 014 fail

by Stanislav Jancik

Hi, I use "7 2018-q2-update" ARMGCC compiler. The PSA Tests code works when it is compiled by ARMGLANG, but a fail occurs when the same code is compiled by ARMGCC. Issue: When TEST: 414 runs, I've got secure violation fault. See report bellow: TEST: 414 | DESCRIPTION: Optional APIs not supported check [Info] Executing tests from non-secure Optional PS APIs are not supported. [Check 1] Call to create API should fail as API not supported [Check 2] Create valid storage with set API [Check 3] Call to set_extended API call should fail [Check 4] Verify data is unchanged Oops... Secure fault!!! You're not going anywhere! Reason: The valtest_entry_p014 is overwritten by read_buff variable and this caused this fail. Workaround: When I changed read_buff declaration in test_p014.c from static uint8_t read_buff[TEST_BUFF_SIZE/4] = {0}; to static uint32_t read_buff[TEST_BUFF_SIZE/4] = {0}; the code is running correctly. But I think, that it should be officially fixed. Best Regards Stanislav

6 years, 6 months

1
0
0 0

Re: [TF-M] TFM and FreeRTOS

by David Hu (Arm Technology China)

Hi Andrej, I guess that you may ask about the SVCalls communication between secure world and non-secure world in FreeRTOS. If I misunderstood your question, please ignore the following. In my very own opinion, FreeRTOS has a different concept of how to manage secure stack/context from TF-M does. FreeRTOS prefers to allocate and manage a dedicated secure stack/context for each non-secure task requiring secure service. In its implementation, each time when it does context switch, it invokes SVCalls to also switch the secure stack/context for the next non-secure task. FreeRTOS implements several own APIs to accomplish those functionalities. By contrast, TF-M as a trusted firmware, naturally, manages all the secure resource by its own. Therefore, there is no such dedicated stack in secure world mapping to each non-secure task. Currently, TF-M implements CMSIS RTOS thread context management APIs to execute some management work between non-secure world and secure world, on Armv8-M core. Hope it can hlep you. Best regards, Hu Ziji On 4/25/2019 3:45 PM, Andrej Butok via TF-M wrote: > Hello, > > Do you know about any existing port of FreeRTOS (instead of RTX) to TFM? Did somebody a feasibility study? > I have just started to look at it, and immediately detected a conflict, both are using Supervisor Calls (SVC) for own needs. > > Thanks, > Andrej > > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 6 months

2
1
0 0

Re: [TF-M] TFM and FreeRTOS

by Miklos Balint

Hi Andrej, For the SVC issue - that should be easy to resolve: The only point at which the NS application stored in the repo uses SVC is when TFM_NS_CLIENT_IDENTIFICATION is enabled. If your scope is a feasibility study with any OS you can turn off this feature by adding set (TFM_NS_CLIENT_IDENTIFICATION OFF) to your Config*.cmake build configuration or toggle the corresponding line in CommonConfig.cmake to OFF to turn it off globally for all build configs in your repo. Regards Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 25 April 2019 09:46 To: TF-M(a)lists.trustedfirmware.org Subject: [TF-M] TFM and FreeRTOS Hello, Do you know about any existing port of FreeRTOS (instead of RTX) to TFM? Did somebody a feasibility study? I have just started to look at it, and immediately detected a conflict, both are using Supervisor Calls (SVC) for own needs. Thanks, Andrej -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 6 months

1
0
0 0

TFM and FreeRTOS

by Andrej Butok

Hello, Do you know about any existing port of FreeRTOS (instead of RTX) to TFM? Did somebody a feasibility study? I have just started to look at it, and immediately detected a conflict, both are using Supervisor Calls (SVC) for own needs. Thanks, Andrej

6 years, 6 months

1
0
0 0

Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault

by Andrej Butok

Hi Ken, OK. We will disable IPC in the regression tests, till it is fixed. Thank you, Andrej Butok -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Wednesday, April 24, 2019 9:52 AM To: TF-M(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault Hi Andrej, This is caused by one of the working model changing patch: 4d66dc3cca0d8c1eff5a3a41692cf01d69eae6ca. The concept of this series changes is: IPC compatible partition is supported only if IPC working model takes place; and library model partitions works for library working model. Before 1.5 weeks ago IPC model could co-exists with library model so the regression works but it is not good -- we should not enable co-existing of two models since it is a waste of resources. We are working on an a workaround to avoid this problem at first by disable library model test while IPC model is selected; and later on patches will make the test framework under proper way for each working model. Thanks. -Ken > -----Original Message----- > From: Andrej Butok <andrey.butok(a)nxp.com> > Sent: Wednesday, April 24, 2019 3:35 PM > To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > Cc: TF-M(a)lists.trustedfirmware.org > Subject: RE: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault > > Hi Ken, > > The fix has fixed the bus fault. Thanks > > But there are some issues when to run the TFM regression tests > (defined CORE_TEST_IPC and TFM_PSA_API) > > I am getting Security violation > SVC_Handle()=>tfm_core_partition_request_svc_handler()=>tfm_core_sfn_r > equ est_handler()=>tfm_secure_api_error_handler(), > > The log: > > [Sec Thread] Secure image initializing! > [Sec Thread] hello! this is ipc client test sp! > [Sec Thread] Connect success! > [Sec Thread] Call success! > > NS code is running... > [Sec Error] Unauthorized service request! > [Sec Error] Security violation when calling secure API > > > Could you run the regression tests and check if everything is OK. > 1.5 week ago, even when IPC was enabled, all regression tests passed. > Now they are passing only when IPC is disabled. > > Thanks, > Andrej > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > Liu (Arm Technology China) via TF-M > Sent: Wednesday, April 24, 2019 9:02 AM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault > > Hi, > The fix for this problem has been logged here: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeve > lope > r.trustedfirmware.org%2FT327&data=02%7C01%7Candrey.butok%40nxp.c > om%7Ccf08748223284a68708b08d6c882c0a6%7C686ea1d3bc2b4c6fa92cd99c5 > c301635%7C0%7C0%7C636916861232914034&sdata=Zq54%2FpI%2FyTtyv > K5aUhWwdU%2FQGPIhJKKT36Ue8Pnop1U%3D&reserved=0 > And the patch is here: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frevi > ew.tr > ustedfirmware.org%2Fc%2Ftrusted-firmware- > m%2F%2B%2F922&data=02%7C01%7Candrey.butok%40nxp.com%7Ccf087 > 48223284a68708b08d6c882c0a6%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C > 0%7C0%7C636916861232914034&sdata=i1A91n5gv6UocgRCcazmiClhH%2 > F%2BkB%2FxGGU%2FktWWjjLk%3D&reserved=0 > > I used a fake thread object to collect initial context to make > scheduler has an initial CURR_THRD. > This is because I need to avoid unnecessary condition checking while > context switch since CURR_THRD only equals to ZERO for ONCE time: > > ctx_switch: > If (pcurr) > Tfm_memcpy(&pcurr->ctx, pctx, sizeof(*pctx)); Tfm_memcpy(pctx, > &pnext- > >ctx, sizeof(pnext->ctx)): > > The TFM_ASSERT in source is another thing since they may get removed > in a release product. > > Please help to provide feedback on it if you see this patch. And I > will try to merge it after several +1/2 is collected since it is an hotfix patch. > > Thanks. > > -Ken > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > > Liu (Arm Technology China) via TF-M > > Sent: Tuesday, April 23, 2019 10:06 PM > > To: TF-M(a)lists.trustedfirmware.org; nd <nd(a)arm.com> > > Cc: nd <nd(a)arm.com> > > Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault > > > > Hi Andrej, > > Ah, great finding! > > We moved the default IDLE thread into partition now so there is no > > default CUR_THRD at very start. > > I guess reverting the latest commit > > 4dcae6f69db61af31316831d773e5d8777e9fbd3 should fix this problem. > > Sorry I don't have working platform now so can not verify it. > > Will provide a fix soon. > > > > -Ken > > ________________________________ > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of > > Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org> > > Sent: Tuesday, April 23, 2019 9:58 PM > > To: tf-m(a)lists.trustedfirmware.org > > Cc: nd > > Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault > > > > Hi Andrej, > > > > While trying to replicate your issue I have found a (maybe related) > > issue with ConfigCoreIPC.cmake and Regression enabled on the current > > tip, described by the following ticket: > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeve > lope > r.trustedfirmware.org%2FT326&data=02%7C01%7Candrey.butok%40nxp.c > om%7Ccf08748223284a68708b08d6c882c0a6%7C686ea1d3bc2b4c6fa92cd99c5 > c301635%7C0%7C0%7C636916861232924039&sdata=3VroxNyRxDp6DK2Ir > fYjgoE%2BGi0tKJDQL5%2Bbm1UnRHA%3D&reserved=0 . We are > investigating if this can be related to the issue you're observing. > > > > Thanks, > > Antonio > > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > > Andrej Butok via TF-M > > Sent: 23 April 2019 14:50 > > To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > > Cc: TF-M(a)lists.trustedfirmware.org > > Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault > > > > > > Hi Ken, > > May be context is static, but the CURR_THRD (p_curr_thrd) pointer is > > NULL, before the first tfm_thrd_context_switch() call. > > OR I have something wrong. > > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > > Liu (Arm Technology China) via TF-M > > Sent: Tuesday, April 23, 2019 3:43 PM > > To: tf-m(a)lists.trustedfirmware.org > > Cc: nd <nd(a)arm.com> > > Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault > > > > WARNING: This email was created outside of NXP. DO NOT CLICK links > > or attachments unless you recognize the sender and know the content is safe. > > > > > > > > Hi Andrej, > > Thanks for the investigation, we will take a look ASAP. > > > > The thread context is allocated statically in global which should > > not have chance to be NULL. If you have time for digging, you can > > put message in function > > './secure_fw/core/ipc/tfm_spm.c:tfm_spm_init()' to show all thread context value of partitions. > > > > Thanks. > > > > -Ken > > ________________________________ > > 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: Tuesday, April 23, 2019 9:16 PM > > To: Antonio De Angelis > > Cc: TF-M(a)lists.trustedfirmware.org > > Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault > > > > Hi Antonio, > > > > We have own port for LPC55S69, so not sure if you are able to run it. > > But, the issues happens in general code (master branch, the latest > > current commit). Defined TFM_PSA_API, TFM_LVL = 1. > > The NULL parameter is causing fault in the first call of > > tfm_thrd_context_switch(..., NULL,...) => tfm_memcpy(&NULL- > > >state_ctx.ctxb, ...) => memcpy(wrong address), and should cause an > > >issue on > > any platform. > > > > Thanks, > > Andrej > > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > > Antonio De Angelis via TF-M > > Sent: Tuesday, April 23, 2019 3:02 PM > > To: tf-m(a)lists.trustedfirmware.org > > Cc: nd <nd(a)arm.com> > > Subject: [EXT] Re: [TF-M] TFM_PSA_API =>BusFault > > > > WARNING: This email was created outside of NXP. DO NOT CLICK links > > or attachments unless you recognize the sender and know the content is safe. > > > > > > > > Hi Andrej, > > > > Could you provide us with instructions on how to replicate the issue > > you're observing? In particular, which build configuration you're > > building (.cmake), compiler, platform used and if it's observed on > > board or FVP/model? Also, are you able to identify the latest commit > > which was still working in your setup / identify the commit which > > brings in this > issue? > > > > Thanks, > > Antonio > > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > > Andrej Butok via TF-M > > Sent: 23 April 2019 13:19 > > To: Andrej Butok <andrey.butok(a)nxp.com> > > Cc: TF-M(a)lists.trustedfirmware.org > > Subject: Re: [TF-M] TFM_PSA_API =>BusFault > > > > Father investigation shows, that tfm_pendsv_do_schedule() calls > > tfm_thrd_context_switch() and passing pth_curr which is set to > > NULL, so it is causing memcpy() to 0 address => Bus Fault. > > So this code may not work properly. > > Please provide a fix. > > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > > Andrej Butok via TF-M > > Sent: Tuesday, April 23, 2019 1:38 PM > > To: TF-M(a)lists.trustedfirmware.org > > Subject: [EXT] [TF-M] TFM_PSA_API =>BusFault > > > > Hello, > > > > After last commits on TFM master branch, when TFM_PSA_API is > > defined, the tfm examples finish in main()=>tfm_spm_init()=>....=> > > tfm_thrd_context_switch()=>tfm_memcpy()=>BusFault_Handler(). > > When TFM_PSA_API is not defined, everything is OK. > > Also, TFM examples were OK at least 2 weeks ago, even when > > TFM_PSA_API was defined. > > > > Is it known issue? Or something new (during last week) must be added > > into our target-specific code? > > > > Thanks, > > Andrej Butok > > > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli > > st > > s.trust > > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > > > m&data=02%7C01%7Candrey.butok%40nxp.com%7C594516635db840889 > > > 6ee08d6c7f19eeb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 > > > 916237904331396&sdata=663%2F9XukXmp8lCoKUM6qEa4h5mxn6I9my0jh > > W8P9wLM%3D&reserved=0 > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli > > st > > s.trust > > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > > > m&data=02%7C01%7Candrey.butok%40nxp.com%7C594516635db840889 > > > 6ee08d6c7f19eeb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 > > > 916237904331396&sdata=663%2F9XukXmp8lCoKUM6qEa4h5mxn6I9my0jh > > W8P9wLM%3D&reserved=0 > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli > > st > > s.trust > > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > > > m&data=02%7C01%7Candrey.butok%40nxp.com%7C594516635db840889 > > > 6ee08d6c7f19eeb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 > > > 916237904341405&sdata=QvbSlGT7udwTcKcJajgtO8rvCvH0UJOMMqOJUc > > 2YPMo%3D&reserved=0 > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli > > st > > s.trust > > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > > > m&data=02%7C01%7Candrey.butok%40nxp.com%7C594516635db840889 > > > 6ee08d6c7f19eeb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 > > > 916237904341405&sdata=QvbSlGT7udwTcKcJajgtO8rvCvH0UJOMMqOJUc > > 2YPMo%3D&reserved=0 > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli > > st > > s.trust > > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > > > m&data=02%7C01%7Candrey.butok%40nxp.com%7C594516635db840889 > > > 6ee08d6c7f19eeb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 > > > 916237904341405&sdata=QvbSlGT7udwTcKcJajgtO8rvCvH0UJOMMqOJUc > > 2YPMo%3D&reserved=0 > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli > > st > > s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Ca > > > ndrey.butok%40nxp.com%7Ccf08748223284a68708b08d6c882c0a6%7C686ea1 > d3bc2 > > > b4c6fa92cd99c5c301635%7C0%7C0%7C636916861232924039&sdata=i4R0 > 4%2BC > > zqYsB2bIBHHVUI1aOMNSEVKJa17ABl1vamUM%3D&reserved=0 > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli > > st > > s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Ca > > > ndrey.butok%40nxp.com%7Ccf08748223284a68708b08d6c882c0a6%7C686ea1 > d3bc2 > > > b4c6fa92cd99c5c301635%7C0%7C0%7C636916861232924039&sdata=i4R0 > 4%2BC > > zqYsB2bIBHHVUI1aOMNSEVKJa17ABl1vamUM%3D&reserved=0 > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli > > st > > s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Ca > > > ndrey.butok%40nxp.com%7Ccf08748223284a68708b08d6c882c0a6%7C686ea1 > d3bc2 > > > b4c6fa92cd99c5c301635%7C0%7C0%7C636916861232924039&sdata=i4R0 > 4%2BC > > zqYsB2bIBHHVUI1aOMNSEVKJa17ABl1vamUM%3D&reserved=0 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trust > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7Ccf08748223284a6870 > 8b08d6c882c0a6%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6369 > 16861232924039&sdata=i4R04%2BCzqYsB2bIBHHVUI1aOMNSEVKJa17ABl > 1vamUM%3D&reserved=0 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 6 months

1
0
0 0

Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault

by Andrej Butok

Hi Ken, The fix has fixed the bus fault. Thanks But there are some issues when to run the TFM regression tests (defined CORE_TEST_IPC and TFM_PSA_API) I am getting Security violation SVC_Handle()=>tfm_core_partition_request_svc_handler()=>tfm_core_sfn_request_handler()=>tfm_secure_api_error_handler(), The log: [Sec Thread] Secure image initializing! [Sec Thread] hello! this is ipc client test sp! [Sec Thread] Connect success! [Sec Thread] Call success! NS code is running... [Sec Error] Unauthorized service request! [Sec Error] Security violation when calling secure API Could you run the regression tests and check if everything is OK. 1.5 week ago, even when IPC was enabled, all regression tests passed. Now they are passing only when IPC is disabled. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Wednesday, April 24, 2019 9:02 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault Hi, The fix for this problem has been logged here: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper… And the patch is here: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… I used a fake thread object to collect initial context to make scheduler has an initial CURR_THRD. This is because I need to avoid unnecessary condition checking while context switch since CURR_THRD only equals to ZERO for ONCE time: ctx_switch: If (pcurr) Tfm_memcpy(&pcurr->ctx, pctx, sizeof(*pctx)); Tfm_memcpy(pctx, &pnext->ctx, sizeof(pnext->ctx)): The TFM_ASSERT in source is another thing since they may get removed in a release product. Please help to provide feedback on it if you see this patch. And I will try to merge it after several +1/2 is collected since it is an hotfix patch. Thanks. -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > Liu (Arm Technology China) via TF-M > Sent: Tuesday, April 23, 2019 10:06 PM > To: TF-M(a)lists.trustedfirmware.org; nd <nd(a)arm.com> > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault > > Hi Andrej, > Ah, great finding! > We moved the default IDLE thread into partition now so there is no > default CUR_THRD at very start. > I guess reverting the latest commit > 4dcae6f69db61af31316831d773e5d8777e9fbd3 should fix this problem. > Sorry I don't have working platform now so can not verify it. > Will provide a fix soon. > > -Ken > ________________________________ > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of > Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org> > Sent: Tuesday, April 23, 2019 9:58 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd > Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault > > Hi Andrej, > > While trying to replicate your issue I have found a (maybe related) > issue with ConfigCoreIPC.cmake and Regression enabled on the current > tip, described by the following ticket: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper… . We are investigating if this can be related to the issue you're observing. > > Thanks, > Antonio > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > Andrej Butok via TF-M > Sent: 23 April 2019 14:50 > To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > Cc: TF-M(a)lists.trustedfirmware.org > Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault > > > Hi Ken, > May be context is static, but the CURR_THRD (p_curr_thrd) pointer is > NULL, before the first tfm_thrd_context_switch() call. > OR I have something wrong. > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > Liu (Arm Technology China) via TF-M > Sent: Tuesday, April 23, 2019 3:43 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault > > WARNING: This email was created outside of NXP. DO NOT CLICK links or > attachments unless you recognize the sender and know the content is safe. > > > > Hi Andrej, > Thanks for the investigation, we will take a look ASAP. > > The thread context is allocated statically in global which should not > have chance to be NULL. If you have time for digging, you can put > message in function './secure_fw/core/ipc/tfm_spm.c:tfm_spm_init()' to > show all thread context value of partitions. > > Thanks. > > -Ken > ________________________________ > 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: Tuesday, April 23, 2019 9:16 PM > To: Antonio De Angelis > Cc: TF-M(a)lists.trustedfirmware.org > Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault > > Hi Antonio, > > We have own port for LPC55S69, so not sure if you are able to run it. > But, the issues happens in general code (master branch, the latest > current commit). Defined TFM_PSA_API, TFM_LVL = 1. > The NULL parameter is causing fault in the first call of > tfm_thrd_context_switch(..., NULL,...) => tfm_memcpy(&NULL- > >state_ctx.ctxb, ...) => memcpy(wrong address), and should cause an > >issue on > any platform. > > Thanks, > Andrej > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > Antonio De Angelis via TF-M > Sent: Tuesday, April 23, 2019 3:02 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [EXT] Re: [TF-M] TFM_PSA_API =>BusFault > > WARNING: This email was created outside of NXP. DO NOT CLICK links or > attachments unless you recognize the sender and know the content is safe. > > > > Hi Andrej, > > Could you provide us with instructions on how to replicate the issue > you're observing? In particular, which build configuration you're > building (.cmake), compiler, platform used and if it's observed on > board or FVP/model? Also, are you able to identify the latest commit > which was still working in your setup / identify the commit which brings in this issue? > > Thanks, > Antonio > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > Andrej Butok via TF-M > Sent: 23 April 2019 13:19 > To: Andrej Butok <andrey.butok(a)nxp.com> > Cc: TF-M(a)lists.trustedfirmware.org > Subject: Re: [TF-M] TFM_PSA_API =>BusFault > > Father investigation shows, that tfm_pendsv_do_schedule() calls > tfm_thrd_context_switch() and passing pth_curr which is set to NULL, > so it is causing memcpy() to 0 address => Bus Fault. > So this code may not work properly. > Please provide a fix. > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > Andrej Butok via TF-M > Sent: Tuesday, April 23, 2019 1:38 PM > To: TF-M(a)lists.trustedfirmware.org > Subject: [EXT] [TF-M] TFM_PSA_API =>BusFault > > Hello, > > After last commits on TFM master branch, when TFM_PSA_API is defined, > the tfm examples finish in main()=>tfm_spm_init()=>....=> > tfm_thrd_context_switch()=>tfm_memcpy()=>BusFault_Handler(). > When TFM_PSA_API is not defined, everything is OK. > Also, TFM examples were OK at least 2 weeks ago, even when TFM_PSA_API > was defined. > > Is it known issue? Or something new (during last week) must be added > into our target-specific code? > > Thanks, > Andrej Butok > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trust > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C594516635db840889 > 6ee08d6c7f19eeb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 > 916237904331396&sdata=663%2F9XukXmp8lCoKUM6qEa4h5mxn6I9my0jh > W8P9wLM%3D&reserved=0 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trust > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C594516635db840889 > 6ee08d6c7f19eeb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 > 916237904331396&sdata=663%2F9XukXmp8lCoKUM6qEa4h5mxn6I9my0jh > W8P9wLM%3D&reserved=0 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trust > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C594516635db840889 > 6ee08d6c7f19eeb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 > 916237904341405&sdata=QvbSlGT7udwTcKcJajgtO8rvCvH0UJOMMqOJUc > 2YPMo%3D&reserved=0 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trust > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C594516635db840889 > 6ee08d6c7f19eeb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 > 916237904341405&sdata=QvbSlGT7udwTcKcJajgtO8rvCvH0UJOMMqOJUc > 2YPMo%3D&reserved=0 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trust > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C594516635db840889 > 6ee08d6c7f19eeb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 > 916237904341405&sdata=QvbSlGT7udwTcKcJajgtO8rvCvH0UJOMMqOJUc > 2YPMo%3D&reserved=0 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-m&data=02%7C01%7Ca > ndrey.butok%40nxp.com%7Ccf08748223284a68708b08d6c882c0a6%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636916861232924039&sdata=i4R04%2BC > zqYsB2bIBHHVUI1aOMNSEVKJa17ABl1vamUM%3D&reserved=0 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-m&data=02%7C01%7Ca > ndrey.butok%40nxp.com%7Ccf08748223284a68708b08d6c882c0a6%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636916861232924039&sdata=i4R04%2BC > zqYsB2bIBHHVUI1aOMNSEVKJa17ABl1vamUM%3D&reserved=0 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-m&data=02%7C01%7Ca > ndrey.butok%40nxp.com%7Ccf08748223284a68708b08d6c882c0a6%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636916861232924039&sdata=i4R04%2BC > zqYsB2bIBHHVUI1aOMNSEVKJa17ABl1vamUM%3D&reserved=0 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 6 months

2
1
0 0

Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault

by Ken Liu (Arm Technology China)

Hi, The fix for this problem has been logged here: https://developer.trustedfirmware.org/T327 And the patch is here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/922 I used a fake thread object to collect initial context to make scheduler has an initial CURR_THRD. This is because I need to avoid unnecessary condition checking while context switch since CURR_THRD only equals to ZERO for ONCE time: ctx_switch: If (pcurr) Tfm_memcpy(&pcurr->ctx, pctx, sizeof(*pctx)); Tfm_memcpy(pctx, &pnext->ctx, sizeof(pnext->ctx)): The TFM_ASSERT in source is another thing since they may get removed in a release product. Please help to provide feedback on it if you see this patch. And I will try to merge it after several +1/2 is collected since it is an hotfix patch. Thanks. -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu > (Arm Technology China) via TF-M > Sent: Tuesday, April 23, 2019 10:06 PM > To: TF-M(a)lists.trustedfirmware.org; nd <nd(a)arm.com> > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault > > Hi Andrej, > Ah, great finding! > We moved the default IDLE thread into partition now so there is no default > CUR_THRD at very start. > I guess reverting the latest commit > 4dcae6f69db61af31316831d773e5d8777e9fbd3 should fix this problem. > Sorry I don't have working platform now so can not verify it. > Will provide a fix soon. > > -Ken > ________________________________ > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Antonio De > Angelis via TF-M <tf-m(a)lists.trustedfirmware.org> > Sent: Tuesday, April 23, 2019 9:58 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd > Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault > > Hi Andrej, > > While trying to replicate your issue I have found a (maybe related) issue with > ConfigCoreIPC.cmake and Regression enabled on the current tip, described by > the following ticket: https://developer.trustedfirmware.org/T326 . We are > investigating if this can be related to the issue you're observing. > > Thanks, > Antonio > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej > Butok via TF-M > Sent: 23 April 2019 14:50 > To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > Cc: TF-M(a)lists.trustedfirmware.org > Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault > > > Hi Ken, > May be context is static, but the CURR_THRD (p_curr_thrd) pointer is NULL, > before the first tfm_thrd_context_switch() call. > OR I have something wrong. > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu > (Arm Technology China) via TF-M > Sent: Tuesday, April 23, 2019 3:43 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault > > WARNING: This email was created outside of NXP. DO NOT CLICK links or > attachments unless you recognize the sender and know the content is safe. > > > > Hi Andrej, > Thanks for the investigation, we will take a look ASAP. > > The thread context is allocated statically in global which should not have chance > to be NULL. If you have time for digging, you can put message in function > './secure_fw/core/ipc/tfm_spm.c:tfm_spm_init()' to show all thread context > value of partitions. > > Thanks. > > -Ken > ________________________________ > 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: Tuesday, April 23, 2019 9:16 PM > To: Antonio De Angelis > Cc: TF-M(a)lists.trustedfirmware.org > Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault > > Hi Antonio, > > We have own port for LPC55S69, so not sure if you are able to run it. > But, the issues happens in general code (master branch, the latest current > commit). Defined TFM_PSA_API, TFM_LVL = 1. > The NULL parameter is causing fault in the first call of > tfm_thrd_context_switch(..., NULL,...) => tfm_memcpy(&NULL- > >state_ctx.ctxb, ...) => memcpy(wrong address), and should cause an issue on > any platform. > > Thanks, > Andrej > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De > Angelis via TF-M > Sent: Tuesday, April 23, 2019 3:02 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [EXT] Re: [TF-M] TFM_PSA_API =>BusFault > > WARNING: This email was created outside of NXP. DO NOT CLICK links or > attachments unless you recognize the sender and know the content is safe. > > > > Hi Andrej, > > Could you provide us with instructions on how to replicate the issue you're > observing? In particular, which build configuration you're building (.cmake), > compiler, platform used and if it's observed on board or FVP/model? Also, are > you able to identify the latest commit which was still working in your setup / > identify the commit which brings in this issue? > > Thanks, > Antonio > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej > Butok via TF-M > Sent: 23 April 2019 13:19 > To: Andrej Butok <andrey.butok(a)nxp.com> > Cc: TF-M(a)lists.trustedfirmware.org > Subject: Re: [TF-M] TFM_PSA_API =>BusFault > > Father investigation shows, that tfm_pendsv_do_schedule() calls > tfm_thrd_context_switch() and passing pth_curr which is set to NULL, so it is > causing memcpy() to 0 address => Bus Fault. > So this code may not work properly. > Please provide a fix. > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej > Butok via TF-M > Sent: Tuesday, April 23, 2019 1:38 PM > To: TF-M(a)lists.trustedfirmware.org > Subject: [EXT] [TF-M] TFM_PSA_API =>BusFault > > Hello, > > After last commits on TFM master branch, when TFM_PSA_API is defined, the > tfm examples finish in main()=>tfm_spm_init()=>....=> > tfm_thrd_context_switch()=>tfm_memcpy()=>BusFault_Handler(). > When TFM_PSA_API is not defined, everything is OK. > Also, TFM examples were OK at least 2 weeks ago, even when TFM_PSA_API > was defined. > > Is it known issue? Or something new (during last week) must be added into our > target-specific code? > > Thanks, > Andrej Butok > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C594516635db840889 > 6ee08d6c7f19eeb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 > 916237904331396&sdata=663%2F9XukXmp8lCoKUM6qEa4h5mxn6I9my0jh > W8P9wLM%3D&reserved=0 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C594516635db840889 > 6ee08d6c7f19eeb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 > 916237904331396&sdata=663%2F9XukXmp8lCoKUM6qEa4h5mxn6I9my0jh > W8P9wLM%3D&reserved=0 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C594516635db840889 > 6ee08d6c7f19eeb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 > 916237904341405&sdata=QvbSlGT7udwTcKcJajgtO8rvCvH0UJOMMqOJUc > 2YPMo%3D&reserved=0 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C594516635db840889 > 6ee08d6c7f19eeb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 > 916237904341405&sdata=QvbSlGT7udwTcKcJajgtO8rvCvH0UJOMMqOJUc > 2YPMo%3D&reserved=0 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C594516635db840889 > 6ee08d6c7f19eeb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 > 916237904341405&sdata=QvbSlGT7udwTcKcJajgtO8rvCvH0UJOMMqOJUc > 2YPMo%3D&reserved=0 > -- > 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 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 6 months

1
0
0 0

Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault

by Andrej Butok

Good, will wait for the official fix ;) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Tuesday, April 23, 2019 4:06 PM To: TF-M(a)lists.trustedfirmware.org; nd <nd(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault Hi Andrej, Ah, great finding! We moved the default IDLE thread into partition now so there is no default CUR_THRD at very start. I guess reverting the latest commit 4dcae6f69db61af31316831d773e5d8777e9fbd3 should fix this problem. Sorry I don't have working platform now so can not verify it. Will provide a fix soon. -Ken ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Tuesday, April 23, 2019 9:58 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault Hi Andrej, While trying to replicate your issue I have found a (maybe related) issue with ConfigCoreIPC.cmake and Regression enabled on the current tip, described by the following ticket: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper… . We are investigating if this can be related to the issue you're observing. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 23 April 2019 14:50 To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault Hi Ken, May be context is static, but the CURR_THRD (p_curr_thrd) pointer is NULL, before the first tfm_thrd_context_switch() call. OR I have something wrong. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Tuesday, April 23, 2019 3:43 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault WARNING: This email was created outside of NXP. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe. Hi Andrej, Thanks for the investigation, we will take a look ASAP. The thread context is allocated statically in global which should not have chance to be NULL. If you have time for digging, you can put message in function './secure_fw/core/ipc/tfm_spm.c:tfm_spm_init()' to show all thread context value of partitions. Thanks. -Ken ________________________________ 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: Tuesday, April 23, 2019 9:16 PM To: Antonio De Angelis Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault Hi Antonio, We have own port for LPC55S69, so not sure if you are able to run it. But, the issues happens in general code (master branch, the latest current commit). Defined TFM_PSA_API, TFM_LVL = 1. The NULL parameter is causing fault in the first call of tfm_thrd_context_switch(..., NULL,...) => tfm_memcpy(&NULL->state_ctx.ctxb, ...) => memcpy(wrong address), and should cause an issue on any platform. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Tuesday, April 23, 2019 3:02 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [EXT] Re: [TF-M] TFM_PSA_API =>BusFault WARNING: This email was created outside of NXP. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe. Hi Andrej, Could you provide us with instructions on how to replicate the issue you're observing? In particular, which build configuration you're building (.cmake), compiler, platform used and if it's observed on board or FVP/model? Also, are you able to identify the latest commit which was still working in your setup / identify the commit which brings in this issue? Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 23 April 2019 13:19 To: Andrej Butok <andrey.butok(a)nxp.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] TFM_PSA_API =>BusFault Father investigation shows, that tfm_pendsv_do_schedule() calls tfm_thrd_context_switch() and passing pth_curr which is set to NULL, so it is causing memcpy() to 0 address => Bus Fault. So this code may not work properly. Please provide a fix. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, April 23, 2019 1:38 PM To: TF-M(a)lists.trustedfirmware.org Subject: [EXT] [TF-M] TFM_PSA_API =>BusFault Hello, After last commits on TFM master branch, when TFM_PSA_API is defined, the tfm examples finish in main()=>tfm_spm_init()=>....=> tfm_thrd_context_switch()=>tfm_memcpy()=>BusFault_Handler(). When TFM_PSA_API is not defined, everything is OK. Also, TFM examples were OK at least 2 weeks ago, even when TFM_PSA_API was defined. Is it known issue? Or something new (during last week) must be added into our target-specific code? Thanks, Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 6 months

1
0
0 0

Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault

by Ken Liu (Arm Technology China)

Hi Andrej, Ah, great finding! We moved the default IDLE thread into partition now so there is no default CUR_THRD at very start. I guess reverting the latest commit 4dcae6f69db61af31316831d773e5d8777e9fbd3 should fix this problem. Sorry I don't have working platform now so can not verify it. Will provide a fix soon. -Ken ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Tuesday, April 23, 2019 9:58 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault Hi Andrej, While trying to replicate your issue I have found a (maybe related) issue with ConfigCoreIPC.cmake and Regression enabled on the current tip, described by the following ticket: https://developer.trustedfirmware.org/T326 . We are investigating if this can be related to the issue you're observing. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 23 April 2019 14:50 To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault Hi Ken, May be context is static, but the CURR_THRD (p_curr_thrd) pointer is NULL, before the first tfm_thrd_context_switch() call. OR I have something wrong. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Tuesday, April 23, 2019 3:43 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault WARNING: This email was created outside of NXP. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe. Hi Andrej, Thanks for the investigation, we will take a look ASAP. The thread context is allocated statically in global which should not have chance to be NULL. If you have time for digging, you can put message in function './secure_fw/core/ipc/tfm_spm.c:tfm_spm_init()' to show all thread context value of partitions. Thanks. -Ken ________________________________ 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: Tuesday, April 23, 2019 9:16 PM To: Antonio De Angelis Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault Hi Antonio, We have own port for LPC55S69, so not sure if you are able to run it. But, the issues happens in general code (master branch, the latest current commit). Defined TFM_PSA_API, TFM_LVL = 1. The NULL parameter is causing fault in the first call of tfm_thrd_context_switch(..., NULL,...) => tfm_memcpy(&NULL->state_ctx.ctxb, ...) => memcpy(wrong address), and should cause an issue on any platform. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Tuesday, April 23, 2019 3:02 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [EXT] Re: [TF-M] TFM_PSA_API =>BusFault WARNING: This email was created outside of NXP. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe. Hi Andrej, Could you provide us with instructions on how to replicate the issue you're observing? In particular, which build configuration you're building (.cmake), compiler, platform used and if it's observed on board or FVP/model? Also, are you able to identify the latest commit which was still working in your setup / identify the commit which brings in this issue? Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 23 April 2019 13:19 To: Andrej Butok <andrey.butok(a)nxp.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] TFM_PSA_API =>BusFault Father investigation shows, that tfm_pendsv_do_schedule() calls tfm_thrd_context_switch() and passing pth_curr which is set to NULL, so it is causing memcpy() to 0 address => Bus Fault. So this code may not work properly. Please provide a fix. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, April 23, 2019 1:38 PM To: TF-M(a)lists.trustedfirmware.org Subject: [EXT] [TF-M] TFM_PSA_API =>BusFault Hello, After last commits on TFM master branch, when TFM_PSA_API is defined, the tfm examples finish in main()=>tfm_spm_init()=>....=> tfm_thrd_context_switch()=>tfm_memcpy()=>BusFault_Handler(). When TFM_PSA_API is not defined, everything is OK. Also, TFM examples were OK at least 2 weeks ago, even when TFM_PSA_API was defined. Is it known issue? Or something new (during last week) must be added into our target-specific code? Thanks, Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- 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

6 years, 6 months

1
0
0 0

Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault

by Antonio De Angelis

Hi Andrej, While trying to replicate your issue I have found a (maybe related) issue with ConfigCoreIPC.cmake and Regression enabled on the current tip, described by the following ticket: https://developer.trustedfirmware.org/T326 . We are investigating if this can be related to the issue you're observing. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 23 April 2019 14:50 To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault Hi Ken, May be context is static, but the CURR_THRD (p_curr_thrd) pointer is NULL, before the first tfm_thrd_context_switch() call. OR I have something wrong. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Tuesday, April 23, 2019 3:43 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault WARNING: This email was created outside of NXP. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe. Hi Andrej, Thanks for the investigation, we will take a look ASAP. The thread context is allocated statically in global which should not have chance to be NULL. If you have time for digging, you can put message in function './secure_fw/core/ipc/tfm_spm.c:tfm_spm_init()' to show all thread context value of partitions. Thanks. -Ken ________________________________ 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: Tuesday, April 23, 2019 9:16 PM To: Antonio De Angelis Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault Hi Antonio, We have own port for LPC55S69, so not sure if you are able to run it. But, the issues happens in general code (master branch, the latest current commit). Defined TFM_PSA_API, TFM_LVL = 1. The NULL parameter is causing fault in the first call of tfm_thrd_context_switch(..., NULL,...) => tfm_memcpy(&NULL->state_ctx.ctxb, ...) => memcpy(wrong address), and should cause an issue on any platform. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Tuesday, April 23, 2019 3:02 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [EXT] Re: [TF-M] TFM_PSA_API =>BusFault WARNING: This email was created outside of NXP. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe. Hi Andrej, Could you provide us with instructions on how to replicate the issue you're observing? In particular, which build configuration you're building (.cmake), compiler, platform used and if it's observed on board or FVP/model? Also, are you able to identify the latest commit which was still working in your setup / identify the commit which brings in this issue? Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 23 April 2019 13:19 To: Andrej Butok <andrey.butok(a)nxp.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] TFM_PSA_API =>BusFault Father investigation shows, that tfm_pendsv_do_schedule() calls tfm_thrd_context_switch() and passing pth_curr which is set to NULL, so it is causing memcpy() to 0 address => Bus Fault. So this code may not work properly. Please provide a fix. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, April 23, 2019 1:38 PM To: TF-M(a)lists.trustedfirmware.org Subject: [EXT] [TF-M] TFM_PSA_API =>BusFault Hello, After last commits on TFM master branch, when TFM_PSA_API is defined, the tfm examples finish in main()=>tfm_spm_init()=>....=> tfm_thrd_context_switch()=>tfm_memcpy()=>BusFault_Handler(). When TFM_PSA_API is not defined, everything is OK. Also, TFM examples were OK at least 2 weeks ago, even when TFM_PSA_API was defined. Is it known issue? Or something new (during last week) must be added into our target-specific code? Thanks, Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 6 months

1
0
0 0

Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault

by Andrej Butok

Hi Ken, May be context is static, but the CURR_THRD (p_curr_thrd) pointer is NULL, before the first tfm_thrd_context_switch() call. OR I have something wrong. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Tuesday, April 23, 2019 3:43 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault WARNING: This email was created outside of NXP. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe. Hi Andrej, Thanks for the investigation, we will take a look ASAP. The thread context is allocated statically in global which should not have chance to be NULL. If you have time for digging, you can put message in function './secure_fw/core/ipc/tfm_spm.c:tfm_spm_init()' to show all thread context value of partitions. Thanks. -Ken ________________________________ 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: Tuesday, April 23, 2019 9:16 PM To: Antonio De Angelis Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault Hi Antonio, We have own port for LPC55S69, so not sure if you are able to run it. But, the issues happens in general code (master branch, the latest current commit). Defined TFM_PSA_API, TFM_LVL = 1. The NULL parameter is causing fault in the first call of tfm_thrd_context_switch(..., NULL,...) => tfm_memcpy(&NULL->state_ctx.ctxb, ...) => memcpy(wrong address), and should cause an issue on any platform. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Tuesday, April 23, 2019 3:02 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [EXT] Re: [TF-M] TFM_PSA_API =>BusFault WARNING: This email was created outside of NXP. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe. Hi Andrej, Could you provide us with instructions on how to replicate the issue you're observing? In particular, which build configuration you're building (.cmake), compiler, platform used and if it's observed on board or FVP/model? Also, are you able to identify the latest commit which was still working in your setup / identify the commit which brings in this issue? Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 23 April 2019 13:19 To: Andrej Butok <andrey.butok(a)nxp.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] TFM_PSA_API =>BusFault Father investigation shows, that tfm_pendsv_do_schedule() calls tfm_thrd_context_switch() and passing pth_curr which is set to NULL, so it is causing memcpy() to 0 address => Bus Fault. So this code may not work properly. Please provide a fix. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, April 23, 2019 1:38 PM To: TF-M(a)lists.trustedfirmware.org Subject: [EXT] [TF-M] TFM_PSA_API =>BusFault Hello, After last commits on TFM master branch, when TFM_PSA_API is defined, the tfm examples finish in main()=>tfm_spm_init()=>....=> tfm_thrd_context_switch()=>tfm_memcpy()=>BusFault_Handler(). When TFM_PSA_API is not defined, everything is OK. Also, TFM examples were OK at least 2 weeks ago, even when TFM_PSA_API was defined. Is it known issue? Or something new (during last week) must be added into our target-specific code? Thanks, Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 6 months

1
0
0 0

Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault

by Ken Liu (Arm Technology China)

Hi Andrej, Thanks for the investigation, we will take a look ASAP. The thread context is allocated statically in global which should not have chance to be NULL. If you have time for digging, you can put message in function './secure_fw/core/ipc/tfm_spm.c:tfm_spm_init()' to show all thread context value of partitions. Thanks. -Ken ________________________________ 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: Tuesday, April 23, 2019 9:16 PM To: Antonio De Angelis Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault Hi Antonio, We have own port for LPC55S69, so not sure if you are able to run it. But, the issues happens in general code (master branch, the latest current commit). Defined TFM_PSA_API, TFM_LVL = 1. The NULL parameter is causing fault in the first call of tfm_thrd_context_switch(..., NULL,...) => tfm_memcpy(&NULL->state_ctx.ctxb, ...) => memcpy(wrong address), and should cause an issue on any platform. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Tuesday, April 23, 2019 3:02 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [EXT] Re: [TF-M] TFM_PSA_API =>BusFault WARNING: This email was created outside of NXP. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe. Hi Andrej, Could you provide us with instructions on how to replicate the issue you're observing? In particular, which build configuration you're building (.cmake), compiler, platform used and if it's observed on board or FVP/model? Also, are you able to identify the latest commit which was still working in your setup / identify the commit which brings in this issue? Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 23 April 2019 13:19 To: Andrej Butok <andrey.butok(a)nxp.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] TFM_PSA_API =>BusFault Father investigation shows, that tfm_pendsv_do_schedule() calls tfm_thrd_context_switch() and passing pth_curr which is set to NULL, so it is causing memcpy() to 0 address => Bus Fault. So this code may not work properly. Please provide a fix. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, April 23, 2019 1:38 PM To: TF-M(a)lists.trustedfirmware.org Subject: [EXT] [TF-M] TFM_PSA_API =>BusFault Hello, After last commits on TFM master branch, when TFM_PSA_API is defined, the tfm examples finish in main()=>tfm_spm_init()=>....=> tfm_thrd_context_switch()=>tfm_memcpy()=>BusFault_Handler(). When TFM_PSA_API is not defined, everything is OK. Also, TFM examples were OK at least 2 weeks ago, even when TFM_PSA_API was defined. Is it known issue? Or something new (during last week) must be added into our target-specific code? Thanks, Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 6 months

1
0
0 0

Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault

by Andrej Butok

Hi Antonio, We have own port for LPC55S69, so not sure if you are able to run it. But, the issues happens in general code (master branch, the latest current commit). Defined TFM_PSA_API, TFM_LVL = 1. The NULL parameter is causing fault in the first call of tfm_thrd_context_switch(..., NULL,...) => tfm_memcpy(&NULL->state_ctx.ctxb, ...) => memcpy(wrong address), and should cause an issue on any platform. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Tuesday, April 23, 2019 3:02 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [EXT] Re: [TF-M] TFM_PSA_API =>BusFault WARNING: This email was created outside of NXP. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe. Hi Andrej, Could you provide us with instructions on how to replicate the issue you're observing? In particular, which build configuration you're building (.cmake), compiler, platform used and if it's observed on board or FVP/model? Also, are you able to identify the latest commit which was still working in your setup / identify the commit which brings in this issue? Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 23 April 2019 13:19 To: Andrej Butok <andrey.butok(a)nxp.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] TFM_PSA_API =>BusFault Father investigation shows, that tfm_pendsv_do_schedule() calls tfm_thrd_context_switch() and passing pth_curr which is set to NULL, so it is causing memcpy() to 0 address => Bus Fault. So this code may not work properly. Please provide a fix. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, April 23, 2019 1:38 PM To: TF-M(a)lists.trustedfirmware.org Subject: [EXT] [TF-M] TFM_PSA_API =>BusFault Hello, After last commits on TFM master branch, when TFM_PSA_API is defined, the tfm examples finish in main()=>tfm_spm_init()=>....=> tfm_thrd_context_switch()=>tfm_memcpy()=>BusFault_Handler(). When TFM_PSA_API is not defined, everything is OK. Also, TFM examples were OK at least 2 weeks ago, even when TFM_PSA_API was defined. Is it known issue? Or something new (during last week) must be added into our target-specific code? Thanks, Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 6 months

1
0
0 0

Re: [TF-M] TFM_PSA_API =>BusFault

by Antonio De Angelis

Hi Andrej, Could you provide us with instructions on how to replicate the issue you're observing? In particular, which build configuration you're building (.cmake), compiler, platform used and if it's observed on board or FVP/model? Also, are you able to identify the latest commit which was still working in your setup / identify the commit which brings in this issue? Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 23 April 2019 13:19 To: Andrej Butok <andrey.butok(a)nxp.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] TFM_PSA_API =>BusFault Father investigation shows, that tfm_pendsv_do_schedule() calls tfm_thrd_context_switch() and passing pth_curr which is set to NULL, so it is causing memcpy() to 0 address => Bus Fault. So this code may not work properly. Please provide a fix. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, April 23, 2019 1:38 PM To: TF-M(a)lists.trustedfirmware.org Subject: [EXT] [TF-M] TFM_PSA_API =>BusFault Hello, After last commits on TFM master branch, when TFM_PSA_API is defined, the tfm examples finish in main()=>tfm_spm_init()=>....=> tfm_thrd_context_switch()=>tfm_memcpy()=>BusFault_Handler(). When TFM_PSA_API is not defined, everything is OK. Also, TFM examples were OK at least 2 weeks ago, even when TFM_PSA_API was defined. Is it known issue? Or something new (during last week) must be added into our target-specific code? Thanks, Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 6 months

1
0
0 0

Re: [TF-M] TFM_PSA_API =>BusFault

by Andrej Butok

Father investigation shows, that tfm_pendsv_do_schedule() calls tfm_thrd_context_switch() and passing pth_curr which is set to NULL, so it is causing memcpy() to 0 address => Bus Fault. So this code may not work properly. Please provide a fix. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, April 23, 2019 1:38 PM To: TF-M(a)lists.trustedfirmware.org Subject: [EXT] [TF-M] TFM_PSA_API =>BusFault Hello, After last commits on TFM master branch, when TFM_PSA_API is defined, the tfm examples finish in main()=>tfm_spm_init()=>....=> tfm_thrd_context_switch()=>tfm_memcpy()=>BusFault_Handler(). When TFM_PSA_API is not defined, everything is OK. Also, TFM examples were OK at least 2 weeks ago, even when TFM_PSA_API was defined. Is it known issue? Or something new (during last week) must be added into our target-specific code? Thanks, Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 6 months

1
0
0 0

TFM_PSA_API =>BusFault

by Andrej Butok

Hello, After last commits on TFM master branch, when TFM_PSA_API is defined, the tfm examples finish in main()=>tfm_spm_init()=>....=> tfm_thrd_context_switch()=>tfm_memcpy()=>BusFault_Handler(). When TFM_PSA_API is not defined, everything is OK. Also, TFM examples were OK at least 2 weeks ago, even when TFM_PSA_API was defined. Is it known issue? Or something new (during last week) must be added into our target-specific code? Thanks, Andrej Butok

6 years, 6 months

1
0
0 0

Re: [TF-M] FW: Trusted boot - rollback protection

by Michel JAOUEN

For solving the placement in contiguous region. One possible solution is to modify image format as follow : header can contain manifest and ih_hdr_size still fixes payload start offset and TLV section starts after sizeof(struct image_header) Michel -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M Sent: lundi 15 avril 2019 16:53 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] FW: Trusted boot - rollback protection Actually the design doc propose to use a distinct security counter from image version (ih_ver in header). But in the most simple case this security counter can be derived from the image version, to have the exact same value (ignoring the build number). The image signature cover these continues blocks in memory: - image header - image - some part of TLV section (currently not covered, but due to multi image support it is planned to introduce a signed TLV section) Because these are contiguous regions in the memory it is not possible to place only the (header + TLV section) to the trusted memory but miss out the image itself (at least I cannot see how to solve) Tamas -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Michel JAOUEN via TF-M Sent: 08 April 2019 16:20 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Trusted boot - rollback protection For the platform without hardware for NV counter, but having trusted memory It is mentioned that the support is possible as follow : "an active image and related manifest data is stored in trusted memory then the included security counter cannot be compromised." the impact for this implementation in mcu-boot is limited to : * The test of the version (security counter is ih_ver from mcuboot header) * The placement of active image and related manifest data in a trusted memory. Is my understanding correct ? As the placement of full image in a trusted memory is a constraint. Can we limit the information placed in a trusted memory to : * image header, * TLV sections. This seems sufficient to support anti roll back. Of course additional impact on mcu-boot must be planned but as multi image support is also targeted , the placement of all images in a trusted memory is likely to be unachievable for all configurations. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 6 months

1
0
0 0

General mailbox design for TF-M in dual core system

by David Hu (Arm Technology China)

Hi all, I post a design document for mailbox design for TF-M in dual core system. Could you please please take a look at https://developer.trustedfirmware.org/w/tf_m/design/twin-cpu/general_mailbo… Any comment is welcome. :) Thank you. Best regards, Hu Ziji

6 years, 6 months

1
0
0 0

Re: [TF-M] TF-M ARM GCC Optimization issue

by Antonio De Angelis

Hi, We have a candidate fix for issues reported with -Os builds with IPC mode builds, available here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/882 could you please help verify if this fixes the issue you're seeing? Note that also with this patch, the Secure side of SST regression in IPC mode fails, but that is another issue that we have identified and we have a separate patch which will be ready shortly for that. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Stanislav Jancik via TF-M Sent: 16 April 2019 13:26 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] TF-M ARM GCC Optimization issue Hi Gyorgy, Yes, it looks that this is the issue. I saw exactly this behavior when optimization was set to -O1. Do you think, that ARM will prepare official fix of this file? Moreover, when I tried to set optimization to -Os, the regression tests have stopped working at TFM_SST_TEST_1XXX test suite. But I did not try to find the reason why, therefore I cannot say more. Regards Stanislav -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of tf-m-request(a)lists.trustedfirmware.org Sent: Tuesday, April 16, 2019 2:00 PM To: tf-m(a)lists.trustedfirmware.org Subject: [EXT] TF-M Digest, Vol 6, Issue 12 WARNING: This email was created outside of NXP. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe. Send TF-M mailing list submissions to tf-m(a)lists.trustedfirmware.org To subscribe or unsubscribe via the World Wide Web, visit https://eur01.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. FW: Trusted boot - rollback protection (Tamas Ban) 2. TF-M ARM GCC Optimization issue (Stanislav Jancik) 3. Re: TF-M ARM GCC Optimization issue (Gyorgy Szing) ---------------------------------------------------------------------- Message: 1 Date: Mon, 15 Apr 2019 14:52:49 +0000 From: Tamas Ban <Tamas.Ban(a)arm.com> To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] FW: Trusted boot - rollback protection Message-ID: <AM6PR08MB3126592CF647127402DB91C4E22B0(a)AM6PR08MB3126.eurprd08.prod.outlook.com> Content-Type: text/plain; charset="utf-8" Actually the design doc propose to use a distinct security counter from image version (ih_ver in header). But in the most simple case this security counter can be derived from the image version, to have the exact same value (ignoring the build number). The image signature cover these continues blocks in memory: - image header - image - some part of TLV section (currently not covered, but due to multi image support it is planned to introduce a signed TLV section) Because these are contiguous regions in the memory it is not possible to place only the (header + TLV section) to the trusted memory but miss out the image itself (at least I cannot see how to solve) Tamas -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Michel JAOUEN via TF-M Sent: 08 April 2019 16:20 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Trusted boot - rollback protection For the platform without hardware for NV counter, but having trusted memory It is mentioned that the support is possible as follow : "an active image and related manifest data is stored in trusted memory then the included security counter cannot be compromised." the impact for this implementation in mcu-boot is limited to : * The test of the version (security counter is ih_ver from mcuboot header) * The placement of active image and related manifest data in a trusted memory. Is my understanding correct ? As the placement of full image in a trusted memory is a constraint. Can we limit the information placed in a trusted memory to : * image header, * TLV sections. This seems sufficient to support anti roll back. Of course additional impact on mcu-boot must be planned but as multi image support is also targeted , the placement of all images in a trusted memory is likely to be unachievable for all configurations. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ------------------------------ Message: 2 Date: Tue, 16 Apr 2019 11:21:05 +0000 From: Stanislav Jancik <stanislav.jancik(a)nxp.com> To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] TF-M ARM GCC Optimization issue Message-ID: <VI1PR04MB63200EB729C45B420D211A2890240(a)VI1PR04MB6320.eurprd04.prod.outlook.com> Content-Type: text/plain; charset="us-ascii" Hi, I am currently working on porting TF-M to our (NXP's) LPC55S69 platform. We have supported armclang compiler and we work on support of armgcc compiler. I found out, that the TF-M is working correctly only with optimization -O0 for secure code. I use "7 2018-q2-update" compiler. For example, when optimization -O1 is set for secure code, the regression tests are running correctly until TFM_IPC_TEST_1XXX test suite. When I debugged this issue, I found out that function and arguments are not properly assigned in function tfm_core_ns_ipc_request (tfm_psa_api_client.c). When I updated this function so the variables int32_t args[4]; struct tfm_sfn_req_s desc, *desc_ptr = &desc; and nt32_t res; were global instead of local. The tests have started running correctly. I so similar issue, when optimization was -Os, but only secure test suites run correctly in this case. I did not see such a behavior when I used armclang compiler. Did you try to use different optimization at Musca boards as well? Regards Stanislav ------------------------------ Message: 3 Date: Tue, 16 Apr 2019 11:58:29 +0000 From: Gyorgy Szing <Gyorgy.Szing(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] TF-M ARM GCC Optimization issue Message-ID: <VE1PR08MB4928420C61B16FA35C6F9A4D91240(a)VE1PR08MB4928.eurprd08.prod.outlook.com> Content-Type: text/plain; charset="utf-8" Hi Stanislav, Can you please check if the issue described here https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper… is the same as you are reporting? /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Stanislav Jancik via TF-M Sent: 16 April 2019 13:21 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] TF-M ARM GCC Optimization issue Hi, I am currently working on porting TF-M to our (NXP's) LPC55S69 platform. We have supported armclang compiler and we work on support of armgcc compiler. I found out, that the TF-M is working correctly only with optimization -O0 for secure code. I use "7 2018-q2-update" compiler. For example, when optimization -O1 is set for secure code, the regression tests are running correctly until TFM_IPC_TEST_1XXX test suite. When I debugged this issue, I found out that function and arguments are not properly assigned in function tfm_core_ns_ipc_request (tfm_psa_api_client.c). When I updated this function so the variables int32_t args[4]; struct tfm_sfn_req_s desc, *desc_ptr = &desc; and nt32_t res; were global instead of local. The tests have started running correctly. I so similar issue, when optimization was -Os, but only secure test suites run correctly in this case. I did not see such a behavior when I used armclang compiler. Did you try to use different optimization at Musca boards as well? Regards Stanislav -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… ------------------------------ Subject: Digest Footer TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… ------------------------------ End of TF-M Digest, Vol 6, Issue 12 *********************************** -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 6 months

1
0
0 0

TF-M ARM GCC Optimization issue

by Stanislav Jancik

Hi Gyorgy, Yes, it looks that this is the issue. I saw exactly this behavior when optimization was set to -O1. Do you think, that ARM will prepare official fix of this file? Moreover, when I tried to set optimization to -Os, the regression tests have stopped working at TFM_SST_TEST_1XXX test suite. But I did not try to find the reason why, therefore I cannot say more. Regards Stanislav -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of tf-m-request(a)lists.trustedfirmware.org Sent: Tuesday, April 16, 2019 2:00 PM To: tf-m(a)lists.trustedfirmware.org Subject: [EXT] TF-M Digest, Vol 6, Issue 12 WARNING: This email was created outside of NXP. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe. Send TF-M mailing list submissions to tf-m(a)lists.trustedfirmware.org To subscribe or unsubscribe via the World Wide Web, visit https://eur01.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. FW: Trusted boot - rollback protection (Tamas Ban) 2. TF-M ARM GCC Optimization issue (Stanislav Jancik) 3. Re: TF-M ARM GCC Optimization issue (Gyorgy Szing) ---------------------------------------------------------------------- Message: 1 Date: Mon, 15 Apr 2019 14:52:49 +0000 From: Tamas Ban <Tamas.Ban(a)arm.com> To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] FW: Trusted boot - rollback protection Message-ID: <AM6PR08MB3126592CF647127402DB91C4E22B0(a)AM6PR08MB3126.eurprd08.prod.outlook.com> Content-Type: text/plain; charset="utf-8" Actually the design doc propose to use a distinct security counter from image version (ih_ver in header). But in the most simple case this security counter can be derived from the image version, to have the exact same value (ignoring the build number). The image signature cover these continues blocks in memory: - image header - image - some part of TLV section (currently not covered, but due to multi image support it is planned to introduce a signed TLV section) Because these are contiguous regions in the memory it is not possible to place only the (header + TLV section) to the trusted memory but miss out the image itself (at least I cannot see how to solve) Tamas -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Michel JAOUEN via TF-M Sent: 08 April 2019 16:20 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Trusted boot - rollback protection For the platform without hardware for NV counter, but having trusted memory It is mentioned that the support is possible as follow : "an active image and related manifest data is stored in trusted memory then the included security counter cannot be compromised." the impact for this implementation in mcu-boot is limited to : * The test of the version (security counter is ih_ver from mcuboot header) * The placement of active image and related manifest data in a trusted memory. Is my understanding correct ? As the placement of full image in a trusted memory is a constraint. Can we limit the information placed in a trusted memory to : * image header, * TLV sections. This seems sufficient to support anti roll back. Of course additional impact on mcu-boot must be planned but as multi image support is also targeted , the placement of all images in a trusted memory is likely to be unachievable for all configurations. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ------------------------------ Message: 2 Date: Tue, 16 Apr 2019 11:21:05 +0000 From: Stanislav Jancik <stanislav.jancik(a)nxp.com> To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] TF-M ARM GCC Optimization issue Message-ID: <VI1PR04MB63200EB729C45B420D211A2890240(a)VI1PR04MB6320.eurprd04.prod.outlook.com> Content-Type: text/plain; charset="us-ascii" Hi, I am currently working on porting TF-M to our (NXP's) LPC55S69 platform. We have supported armclang compiler and we work on support of armgcc compiler. I found out, that the TF-M is working correctly only with optimization -O0 for secure code. I use "7 2018-q2-update" compiler. For example, when optimization -O1 is set for secure code, the regression tests are running correctly until TFM_IPC_TEST_1XXX test suite. When I debugged this issue, I found out that function and arguments are not properly assigned in function tfm_core_ns_ipc_request (tfm_psa_api_client.c). When I updated this function so the variables int32_t args[4]; struct tfm_sfn_req_s desc, *desc_ptr = &desc; and nt32_t res; were global instead of local. The tests have started running correctly. I so similar issue, when optimization was -Os, but only secure test suites run correctly in this case. I did not see such a behavior when I used armclang compiler. Did you try to use different optimization at Musca boards as well? Regards Stanislav ------------------------------ Message: 3 Date: Tue, 16 Apr 2019 11:58:29 +0000 From: Gyorgy Szing <Gyorgy.Szing(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] TF-M ARM GCC Optimization issue Message-ID: <VE1PR08MB4928420C61B16FA35C6F9A4D91240(a)VE1PR08MB4928.eurprd08.prod.outlook.com> Content-Type: text/plain; charset="utf-8" Hi Stanislav, Can you please check if the issue described here https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper… is the same as you are reporting? /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Stanislav Jancik via TF-M Sent: 16 April 2019 13:21 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] TF-M ARM GCC Optimization issue Hi, I am currently working on porting TF-M to our (NXP's) LPC55S69 platform. We have supported armclang compiler and we work on support of armgcc compiler. I found out, that the TF-M is working correctly only with optimization -O0 for secure code. I use "7 2018-q2-update" compiler. For example, when optimization -O1 is set for secure code, the regression tests are running correctly until TFM_IPC_TEST_1XXX test suite. When I debugged this issue, I found out that function and arguments are not properly assigned in function tfm_core_ns_ipc_request (tfm_psa_api_client.c). When I updated this function so the variables int32_t args[4]; struct tfm_sfn_req_s desc, *desc_ptr = &desc; and nt32_t res; were global instead of local. The tests have started running correctly. I so similar issue, when optimization was -Os, but only secure test suites run correctly in this case. I did not see such a behavior when I used armclang compiler. Did you try to use different optimization at Musca boards as well? Regards Stanislav -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… ------------------------------ Subject: Digest Footer TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… ------------------------------ End of TF-M Digest, Vol 6, Issue 12 ***********************************

6 years, 6 months

1
0
0 0

Re: [TF-M] TF-M ARM GCC Optimization issue

by Gyorgy Szing

Hi Stanislav, Can you please check if the issue described here https://developer.trustedfirmware.org/T234 is the same as you are reporting? /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Stanislav Jancik via TF-M Sent: 16 April 2019 13:21 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] TF-M ARM GCC Optimization issue Hi, I am currently working on porting TF-M to our (NXP's) LPC55S69 platform. We have supported armclang compiler and we work on support of armgcc compiler. I found out, that the TF-M is working correctly only with optimization -O0 for secure code. I use "7 2018-q2-update" compiler. For example, when optimization -O1 is set for secure code, the regression tests are running correctly until TFM_IPC_TEST_1XXX test suite. When I debugged this issue, I found out that function and arguments are not properly assigned in function tfm_core_ns_ipc_request (tfm_psa_api_client.c). When I updated this function so the variables int32_t args[4]; struct tfm_sfn_req_s desc, *desc_ptr = &desc; and nt32_t res; were global instead of local. The tests have started running correctly. I so similar issue, when optimization was -Os, but only secure test suites run correctly in this case. I did not see such a behavior when I used armclang compiler. Did you try to use different optimization at Musca boards as well? Regards Stanislav -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 6 months

1
0
0 0

TF-M ARM GCC Optimization issue

by Stanislav Jancik

Hi, I am currently working on porting TF-M to our (NXP's) LPC55S69 platform. We have supported armclang compiler and we work on support of armgcc compiler. I found out, that the TF-M is working correctly only with optimization -O0 for secure code. I use "7 2018-q2-update" compiler. For example, when optimization -O1 is set for secure code, the regression tests are running correctly until TFM_IPC_TEST_1XXX test suite. When I debugged this issue, I found out that function and arguments are not properly assigned in function tfm_core_ns_ipc_request (tfm_psa_api_client.c). When I updated this function so the variables int32_t args[4]; struct tfm_sfn_req_s desc, *desc_ptr = &desc; and nt32_t res; were global instead of local. The tests have started running correctly. I so similar issue, when optimization was -Os, but only secure test suites run correctly in this case. I did not see such a behavior when I used armclang compiler. Did you try to use different optimization at Musca boards as well? Regards Stanislav

6 years, 6 months

1
0
0 0

FW: Trusted boot - rollback protection

by Tamas Ban

Actually the design doc propose to use a distinct security counter from image version (ih_ver in header). But in the most simple case this security counter can be derived from the image version, to have the exact same value (ignoring the build number). The image signature cover these continues blocks in memory: - image header - image - some part of TLV section (currently not covered, but due to multi image support it is planned to introduce a signed TLV section) Because these are contiguous regions in the memory it is not possible to place only the (header + TLV section) to the trusted memory but miss out the image itself (at least I cannot see how to solve) Tamas -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Michel JAOUEN via TF-M Sent: 08 April 2019 16:20 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Trusted boot - rollback protection For the platform without hardware for NV counter, but having trusted memory It is mentioned that the support is possible as follow : "an active image and related manifest data is stored in trusted memory then the included security counter cannot be compromised." the impact for this implementation in mcu-boot is limited to : * The test of the version (security counter is ih_ver from mcuboot header) * The placement of active image and related manifest data in a trusted memory. Is my understanding correct ? As the placement of full image in a trusted memory is a constraint. Can we limit the information placed in a trusted memory to : * image header, * TLV sections. This seems sufficient to support anti roll back. Of course additional impact on mcu-boot must be planned but as multi image support is also targeted , the placement of all images in a trusted memory is likely to be unachievable for all configurations. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 6 months

1
0
0 0

Re: [TF-M] Platform: Create platform service for pin functions

by Miklos Balint

Michel, I agree there is a need for a more generic design pattern for such platform-specific features. I think that there should be a single entry point for any platform specific service request to the platform/ directory and each platform should/could list the specific features it supports. Then the specific function type would be encoded in an invec to the service request. But I think a more detailed design proposal is needed with enough room for discussion before committing to a new pattern, and I'd prefer to avoid introducing platform dependencies in the services/ folder. That folder should ideally just have an indirection across HAL to a platform-specific service request arbiter. Any opinions or should I produce a more detailed proposal to show what I mean? Regards Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Michel JAOUEN via TF-M Sent: 11 April 2019 13:57 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Platform: Create platform service for pin functions I see that there is https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/825/ On review , it adds some dummy functions for the platform not requiring these services Can we think about introducing some configuration on platform basis. As example , I post https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/854/ Best regards From: Michel JAOUEN Sent: mercredi 10 avril 2019 13:05 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: Platform: Create platform service for pin functions Hello, I noticed the merge of this api, which seems require only for platform Musca_a. This create the need to implement dummy functions for the other platform. would it be better to make this configurable for each platform ? I think for the interface connected to platform partition, it is important to have a flexibility. As example some platform , may require an API requesting a pin to be configureable from non secure . Best regards -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 6 months

2
1
0 0

Re: [TF-M] Platform: Create platform service for pin functions

by Michel JAOUEN

I see that there is https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/825/ On review , it adds some dummy functions for the platform not requiring these services Can we think about introducing some configuration on platform basis. As example , I post https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/854/ Best regards From: Michel JAOUEN Sent: mercredi 10 avril 2019 13:05 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: Platform: Create platform service for pin functions Hello, I noticed the merge of this api, which seems require only for platform Musca_a. This create the need to implement dummy functions for the other platform. would it be better to make this configurable for each platform ? I think for the interface connected to platform partition, it is important to have a flexibility. As example some platform , may require an API requesting a pin to be configureable from non secure . Best regards

6 years, 6 months

1
0
0 0

Re: [TF-M] psa_invec type mismatch in tfm_psa_call_veneer?

by Ken Liu (Arm Technology China)

Hi Both, The intention of doing this is for packing parameters while handling non-secure psa_call(). This function has five parameters, which means the 5th one needs to be put in NS stack. If we extract 5th parameter in veneer function we need to enable non-secure memory accessing for veneer and implement some assembler code there to fetch PSP_NS. To make it simple at first stage we just pack 'psa_invec' and 'psa_outvec' as two inputs of tfm_psa_call_veneer(); that why the two types are invec -- because they really are inputs. This part really causes confuse and need to be discussed if we need to implement more proper way for this. Let's track it in the ticket. -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De > Angelis via TF-M > Sent: Thursday, April 11, 2019 6:31 AM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] psa_invec type mismatch in tfm_psa_call_veneer? > > Hi Alan, > > I think you're right, the prototypes of these functions should be fixed. Moreover, > I think psa_outvec *out_vecs should drop the const qualifier to match > psa_call(...) prototypes, as it's an output parameter and needs to be non-const. > I have raised https://developer.trustedfirmware.org/T313 to keep track of this. > > Thanks, > Antonio > > ________________________________ > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of DeMars, > Alan via TF-M <tf-m(a)lists.trustedfirmware.org> > Sent: 10 April 2019 22:12 > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] psa_invec type mismatch in tfm_psa_call_veneer? > > It seems to me that the 'psa_invec' type is incorrectly being used where the > 'psa_outvec' type should be used everywhere tfm_psa_call_veneer() is used. > > > > In tfm_api.h, I think this: > > > > psa_status_t tfm_psa_call_veneer(psa_handle_t handle, > > const psa_invec *in_vecs, > > const psa_invec *out_vecs); > > > > should be this: > > > > psa_status_t tfm_psa_call_veneer(psa_handle_t handle, > > const psa_invec *in_vecs, > > const psa_outvec *out_vecs); > > > > > > And, in the implementation of the tfm_psa_call_veneer > > within tfm_psa_api_client.c, I think this: > > > > __tfm_secure_gateway_attributes__ > > psa_status_t tfm_psa_call_veneer(psa_handle_t handle, > > const psa_invec *in_vecs, > > const psa_invec *out_vecs) > > > > should be this: > > > > __tfm_secure_gateway_attributes__ > > psa_status_t tfm_psa_call_veneer(psa_handle_t handle, > > const psa_invec *in_vecs, > > const psa_outvec *out_vecs) > > > > > > And, in the NS implementation of psa_call() within tfm_psa_ns_api.c, I think this: > > > > psa_invec in_vecs, out_vecs; > > > > should be this: > > > > psa_invec in_vecs; > > psa_outvec out_vecs; > > > > > > Alan > > > -- > 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

6 years, 6 months

1
0
0 0

Re: [TF-M] psa_invec type mismatch in tfm_psa_call_veneer?

by Antonio De Angelis

Hi Alan, I think you're right, the prototypes of these functions should be fixed. Moreover, I think psa_outvec *out_vecs should drop the const qualifier to match psa_call(...) prototypes, as it's an output parameter and needs to be non-const. I have raised https://developer.trustedfirmware.org/T313 to keep track of this. Thanks, Antonio ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of DeMars, Alan via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 10 April 2019 22:12 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] psa_invec type mismatch in tfm_psa_call_veneer? It seems to me that the 'psa_invec' type is incorrectly being used where the 'psa_outvec' type should be used everywhere tfm_psa_call_veneer() is used. In tfm_api.h, I think this: psa_status_t tfm_psa_call_veneer(psa_handle_t handle, const psa_invec *in_vecs, const psa_invec *out_vecs); should be this: psa_status_t tfm_psa_call_veneer(psa_handle_t handle, const psa_invec *in_vecs, const psa_outvec *out_vecs); And, in the implementation of the tfm_psa_call_veneer within tfm_psa_api_client.c, I think this: __tfm_secure_gateway_attributes__ psa_status_t tfm_psa_call_veneer(psa_handle_t handle, const psa_invec *in_vecs, const psa_invec *out_vecs) should be this: __tfm_secure_gateway_attributes__ psa_status_t tfm_psa_call_veneer(psa_handle_t handle, const psa_invec *in_vecs, const psa_outvec *out_vecs) And, in the NS implementation of psa_call() within tfm_psa_ns_api.c, I think this: psa_invec in_vecs, out_vecs; should be this: psa_invec in_vecs; psa_outvec out_vecs; Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 6 months

1
0
0 0

psa_invec type mismatch in tfm_psa_call_veneer?

by DeMars, Alan

It seems to me that the 'psa_invec' type is incorrectly being used where the 'psa_outvec' type should be used everywhere tfm_psa_call_veneer() is used. In tfm_api.h, I think this: psa_status_t tfm_psa_call_veneer(psa_handle_t handle, const psa_invec *in_vecs, const psa_invec *out_vecs); should be this: psa_status_t tfm_psa_call_veneer(psa_handle_t handle, const psa_invec *in_vecs, const psa_outvec *out_vecs); And, in the implementation of the tfm_psa_call_veneer within tfm_psa_api_client.c, I think this: __tfm_secure_gateway_attributes__ psa_status_t tfm_psa_call_veneer(psa_handle_t handle, const psa_invec *in_vecs, const psa_invec *out_vecs) should be this: __tfm_secure_gateway_attributes__ psa_status_t tfm_psa_call_veneer(psa_handle_t handle, const psa_invec *in_vecs, const psa_outvec *out_vecs) And, in the NS implementation of psa_call() within tfm_psa_ns_api.c, I think this: psa_invec in_vecs, out_vecs; should be this: psa_invec in_vecs; psa_outvec out_vecs; Alan

6 years, 6 months

1
0
0 0

Platform: Create platform service for pin functions

by Michel JAOUEN

Hello, I noticed the merge of this api, which seems require only for platform Musca_a. This create the need to implement dummy functions for the other platform. would it be better to make this configurable for each platform ? I think for the interface connected to platform partition, it is important to have a flexibility. As example some platform , may require an API requesting a pin to be configureable from non secure . Best regards

6 years, 6 months

1
0
0 0

[RFC] Core: Set PendSV priority to lowest

by Ken Liu (Arm Technology China)

Hi, I have created a patch to set PenSV priority as lowest, which makes more sense that other high priority interrupts may preempt scheduling and affect the scheduling result. The issue is created here and you can find gerrit link in comment: https://developer.trustedfirmware.org/T310 Please publish your comments under this issue if you have. Thanks -Ken

6 years, 6 months

1
0
0 0

Re: [TF-M] Trusted boot - rollback protection

by Michel JAOUEN

For the platform without hardware for NV counter, but having trusted memory It is mentioned that the support is possible as follow : "an active image and related manifest data is stored in trusted memory then the included security counter cannot be compromised." the impact for this implementation in mcu-boot is limited to : * The test of the version (security counter is ih_ver from mcuboot header) * The placement of active image and related manifest data in a trusted memory. Is my understanding correct ? As the placement of full image in a trusted memory is a constraint. Can we limit the information placed in a trusted memory to : * image header, * TLV sections. This seems sufficient to support anti roll back. Of course additional impact on mcu-boot must be planned but as multi image support is also targeted , the placement of all images in a trusted memory is likely to be unachievable for all configurations.

6 years, 6 months

1
0
0 0

Support SST_FLASH_PROGRAM_UNIT=8

by Michel JAOUEN

Hello, For this support , I created https://developer.trustedfirmware.org/T305 Best regards

6 years, 7 months

1
0
0 0

Re: [TF-M] build of NSPE with flag __ARM_FEATURE_CMSE=3

by Gyorgy Szing

Hi Michel, Apologies, somehow my response yesterday got lost, so here it goes again: I re-read the documentation and the way you use this macro seems to be valid when targeting v8-M based chips. I see two solutions for your problem: 1. I created a ticket to remove the --mcmse compile flag for non-secure projects. See: https://developer.trustedfirmware.org/T304 After this is fixed, your current code will work as expected. 2. Currently TF-M uses the __DOMAIN_NS macro to define the target domain for the source-code. It is an option to change your code to use this macro. I suggest going for this option if your code is not v8-M specific, and may need to support other architectures in the future. /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: 03 April 2019 17:40 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] build of NSPE with flag __ARM_FEATURE_CMSE=3 Hi Michel, A ticket has been raised by Gyorgy to track this: https://developer.trustedfirmware.org/T304 Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Michel JAOUEN via TF-M Sent: 03 April 2019 03:03 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] build of NSPE with flag __ARM_FEATURE_CMSE=3 Hello, The flag is defined to __ARM_FEATURE_CMSE == 3U. In documentation, I can read : __ARM_FEATURE_CMSE == 3U when Toolchain targets the secure state of CMSE (implies the availability of the TT instruction). My soc files relies on this flag to select by default a secure peripheral register address or a non secure peripheral address. With the non secure compiled with __ARM_FEATURE_CMSE == 3U , by default secure peripheral address are selected. Is it a correct usage to build NSPE with __ARM_FEATURE_CMSE == 3U ? Best regards -- 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

6 years, 7 months

1
0
0 0

Re: [TF-M] build with GNUARM with option -Os

by Edison Ai (Arm Technology China)

Hi Michel, We will pick up this and try to push a patch to fix it soon. Hi Alan, Thanks for your workaround, and it is very helpful. We will update the T234 as soon as possible after the patch ready. Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: Wednesday, April 3, 2019 9:32 PM To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] build with GNUARM with option -Os I assumed there was an outstanding pull request for this ticket: https://developer.trustedfirmware.org/T234 Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Tuesday, April 02, 2019 6:59 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] build with GNUARM with option -Os Hi Alan, Is it OK for you to commit this change? -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > DeMars, Alan via TF-M > Sent: Wednesday, April 3, 2019 5:50 AM > To: Michel JAOUEN <michel.jaouen(a)st.com> > Cc: tf-m(a)lists.trustedfirmware.org > Subject: Re: [TF-M] build with GNUARM with option -Os > > I had a similar problem. Upon advice in this email list, I fixed it by > changing the implementation of "tfm_core_ns_ipc_request()" in > secure_fw/core/tfm_psa_api_client.c. > > Add 'volatile' to the declaration of these variables: > > struct tfm_sfn_req_s desc, *desc_ptr = &desc; > > change to: > > volatile struct tfm_sfn_req_s desc, *desc_ptr = &desc; > > After this change, I am able to build and run with -O3 as well as -Os. > > I don't know why this fix hasn't been added to the master branch as > this problem has already been identified. > > Alan > > -----Original Message----- > From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf > Of Michel JAOUEN via TF-M > Sent: Tuesday, April 02, 2019 4:11 AM > To: tf-m(a)lists.trustedfirmware.org > Subject: [EXTERNAL] [TF-M] build with GNUARM with option -Os > > Hello, > I tested my board port on top of > 1c266ae74bd93c2ef290e9aac0caecf92b06b93d > Without option -Os , the tests with ConfigCoreIPC.cmake are passed . > When I put the option -Os , 1st test is failing in Hardware Fault. > > For info, the test with ConfigRegression.cmake and option -Os is passed . > > With the configuration -Os , code footprint is much better. > > Is it plan to activate this option in master ? Is the same issue > reproduced on another board ? > > Best regards > > -- > 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 -- 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

6 years, 7 months

1
0
0 0

Re: [TF-M] build of NSPE with flag __ARM_FEATURE_CMSE=3

by Antonio De Angelis

Hi Michel, A ticket has been raised by Gyorgy to track this: https://developer.trustedfirmware.org/T304 Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Michel JAOUEN via TF-M Sent: 03 April 2019 03:03 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] build of NSPE with flag __ARM_FEATURE_CMSE=3 Hello, The flag is defined to __ARM_FEATURE_CMSE == 3U. In documentation, I can read : __ARM_FEATURE_CMSE == 3U when Toolchain targets the secure state of CMSE (implies the availability of the TT instruction). My soc files relies on this flag to select by default a secure peripheral register address or a non secure peripheral address. With the non secure compiled with __ARM_FEATURE_CMSE == 3U , by default secure peripheral address are selected. Is it a correct usage to build NSPE with __ARM_FEATURE_CMSE == 3U ? Best regards -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 7 months

1
0
0 0

Re: [TF-M] build with GNUARM with option -Os

by DeMars, Alan

I assumed there was an outstanding pull request for this ticket: https://developer.trustedfirmware.org/T234 Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Tuesday, April 02, 2019 6:59 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] build with GNUARM with option -Os Hi Alan, Is it OK for you to commit this change? -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, > Alan via TF-M > Sent: Wednesday, April 3, 2019 5:50 AM > To: Michel JAOUEN <michel.jaouen(a)st.com> > Cc: tf-m(a)lists.trustedfirmware.org > Subject: Re: [TF-M] build with GNUARM with option -Os > > I had a similar problem. Upon advice in this email list, I fixed it by changing the > implementation of "tfm_core_ns_ipc_request()" in > secure_fw/core/tfm_psa_api_client.c. > > Add 'volatile' to the declaration of these variables: > > struct tfm_sfn_req_s desc, *desc_ptr = &desc; > > change to: > > volatile struct tfm_sfn_req_s desc, *desc_ptr = &desc; > > After this change, I am able to build and run with -O3 as well as -Os. > > I don't know why this fix hasn't been added to the master branch as this problem > has already been identified. > > Alan > > -----Original Message----- > From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of > Michel JAOUEN via TF-M > Sent: Tuesday, April 02, 2019 4:11 AM > To: tf-m(a)lists.trustedfirmware.org > Subject: [EXTERNAL] [TF-M] build with GNUARM with option -Os > > Hello, > I tested my board port on top of > 1c266ae74bd93c2ef290e9aac0caecf92b06b93d > Without option -Os , the tests with ConfigCoreIPC.cmake are passed . > When I put the option -Os , 1st test is failing in Hardware Fault. > > For info, the test with ConfigRegression.cmake and option -Os is passed . > > With the configuration -Os , code footprint is much better. > > Is it plan to activate this option in master ? Is the same issue reproduced on > another board ? > > Best regards > > -- > 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 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 7 months

1
0
0 0

build of NSPE with flag __ARM_FEATURE_CMSE=3

by Michel JAOUEN

Hello, The flag is defined to __ARM_FEATURE_CMSE == 3U. In documentation, I can read : __ARM_FEATURE_CMSE == 3U when Toolchain targets the secure state of CMSE (implies the availability of the TT instruction). My soc files relies on this flag to select by default a secure peripheral register address or a non secure peripheral address. With the non secure compiled with __ARM_FEATURE_CMSE == 3U , by default secure peripheral address are selected. Is it a correct usage to build NSPE with __ARM_FEATURE_CMSE == 3U ? Best regards

6 years, 7 months

1
0
0 0

Re: [TF-M] build with GNUARM with option -Os

by Ken Liu (Arm Technology China)

Hi Alan, Is it OK for you to commit this change? -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, > Alan via TF-M > Sent: Wednesday, April 3, 2019 5:50 AM > To: Michel JAOUEN <michel.jaouen(a)st.com> > Cc: tf-m(a)lists.trustedfirmware.org > Subject: Re: [TF-M] build with GNUARM with option -Os > > I had a similar problem. Upon advice in this email list, I fixed it by changing the > implementation of "tfm_core_ns_ipc_request()" in > secure_fw/core/tfm_psa_api_client.c. > > Add 'volatile' to the declaration of these variables: > > struct tfm_sfn_req_s desc, *desc_ptr = &desc; > > change to: > > volatile struct tfm_sfn_req_s desc, *desc_ptr = &desc; > > After this change, I am able to build and run with -O3 as well as -Os. > > I don't know why this fix hasn't been added to the master branch as this problem > has already been identified. > > Alan > > -----Original Message----- > From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of > Michel JAOUEN via TF-M > Sent: Tuesday, April 02, 2019 4:11 AM > To: tf-m(a)lists.trustedfirmware.org > Subject: [EXTERNAL] [TF-M] build with GNUARM with option -Os > > Hello, > I tested my board port on top of > 1c266ae74bd93c2ef290e9aac0caecf92b06b93d > Without option -Os , the tests with ConfigCoreIPC.cmake are passed . > When I put the option -Os , 1st test is failing in Hardware Fault. > > For info, the test with ConfigRegression.cmake and option -Os is passed . > > With the configuration -Os , code footprint is much better. > > Is it plan to activate this option in master ? Is the same issue reproduced on > another board ? > > Best regards > > -- > 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

6 years, 7 months

1
0
0 0

Re: [TF-M] build with GNUARM with option -Os

by DeMars, Alan

I had a similar problem. Upon advice in this email list, I fixed it by changing the implementation of "tfm_core_ns_ipc_request()" in secure_fw/core/tfm_psa_api_client.c. Add 'volatile' to the declaration of these variables: struct tfm_sfn_req_s desc, *desc_ptr = &desc; change to: volatile struct tfm_sfn_req_s desc, *desc_ptr = &desc; After this change, I am able to build and run with -O3 as well as -Os. I don't know why this fix hasn't been added to the master branch as this problem has already been identified. Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Michel JAOUEN via TF-M Sent: Tuesday, April 02, 2019 4:11 AM To: tf-m(a)lists.trustedfirmware.org Subject: [EXTERNAL] [TF-M] build with GNUARM with option -Os Hello, I tested my board port on top of 1c266ae74bd93c2ef290e9aac0caecf92b06b93d Without option -Os , the tests with ConfigCoreIPC.cmake are passed . When I put the option -Os , 1st test is failing in Hardware Fault. For info, the test with ConfigRegression.cmake and option -Os is passed . With the configuration -Os , code footprint is much better. Is it plan to activate this option in master ? Is the same issue reproduced on another board ? Best regards -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 7 months

1
0
0 0

build with GNUARM with option -Os

by Michel JAOUEN

Hello, I tested my board port on top of 1c266ae74bd93c2ef290e9aac0caecf92b06b93d Without option -Os , the tests with ConfigCoreIPC.cmake are passed . When I put the option -Os , 1st test is failing in Hardware Fault. For info, the test with ConfigRegression.cmake and option -Os is passed . With the configuration -Os , code footprint is much better. Is it plan to activate this option in master ? Is the same issue reproduced on another board ? Best regards

6 years, 7 months

1
0
0 0

Re: [TF-M] PSA Test Suite forum?

by Andrej Butok

Hi Antonio, Ok, so the TFM is using the old API. Hope, it will be updated soon. I prefer do not downgrade the test suite from master, as it contains >50 of new commits. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Monday, April 1, 2019 11:24 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] PSA Test Suite forum? Hi Andrej, I have replied on the GitHub issue as well, copy-pasting my reply below: TF-M uses a version of the API which is marked 0.1.0b. The psa-arch-tests, on the master branch, have moved to use a newer version of the API, while on the branch marked ew_beta0 they use the version of the API compatible with the one TF-M uses, hence TF-M PSA API compliance needs to be tests using the ew_beta0 branch. Work is ongoing on TF-M side to move to newer versions of the API. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Qixiang Xu (Arm Technology China) via TF-M Sent: 01 April 2019 09:14 To: Andrej Butok <andrey.butok(a)nxp.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] PSA Test Suite forum? Andrej, Yes, the PSA test suite was developed by different team. If it is a common topic, you can report the issue at any of the site, then we will sync it internal. Thanks. Best Regards, Qixiang Xu -----Original Message----- From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Monday, April 1, 2019 3:59 PM To: Qixiang Xu (Arm Technology China) <Qixiang.Xu(a)arm.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: RE: PSA Test Suite forum? Hi Qixiang Xu, I have added https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… Not sure, what forum to use if it is a common topic related to both TFM and Test-suite. Is the PSA test suite developed by other independent team? Thanks, Andrej -----Original Message----- From: Qixiang Xu (Arm Technology China) <Qixiang.Xu(a)arm.com> Sent: Monday, April 1, 2019 9:41 AM To: Andrej Butok <andrey.butok(a)nxp.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: RE: PSA Test Suite forum? Andrej, You can report any issue or concern at: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… Best Regards, Qixiang Xu -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Monday, April 1, 2019 3:29 PM To: TF-M(a)lists.trustedfirmware.org Subject: [TF-M] PSA Test Suite forum? Hello, Do you have a forum dedicated to the PSA Test-suite (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… )? Or we may use this one? Thanks Andrej -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 7 months

2
1
0 0

Re: [TF-M] PSA Test Suite forum?

by Antonio De Angelis

Hi Andrej, I have replied on the GitHub issue as well, copy-pasting my reply below: TF-M uses a version of the API which is marked 0.1.0b. The psa-arch-tests, on the master branch, have moved to use a newer version of the API, while on the branch marked ew_beta0 they use the version of the API compatible with the one TF-M uses, hence TF-M PSA API compliance needs to be tests using the ew_beta0 branch. Work is ongoing on TF-M side to move to newer versions of the API. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Qixiang Xu (Arm Technology China) via TF-M Sent: 01 April 2019 09:14 To: Andrej Butok <andrey.butok(a)nxp.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] PSA Test Suite forum? Andrej, Yes, the PSA test suite was developed by different team. If it is a common topic, you can report the issue at any of the site, then we will sync it internal. Thanks. Best Regards, Qixiang Xu -----Original Message----- From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Monday, April 1, 2019 3:59 PM To: Qixiang Xu (Arm Technology China) <Qixiang.Xu(a)arm.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: RE: PSA Test Suite forum? Hi Qixiang Xu, I have added https://github.com/ARM-software/psa-arch-tests/issues/79 Not sure, what forum to use if it is a common topic related to both TFM and Test-suite. Is the PSA test suite developed by other independent team? Thanks, Andrej -----Original Message----- From: Qixiang Xu (Arm Technology China) <Qixiang.Xu(a)arm.com> Sent: Monday, April 1, 2019 9:41 AM To: Andrej Butok <andrey.butok(a)nxp.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: RE: PSA Test Suite forum? Andrej, You can report any issue or concern at: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… Best Regards, Qixiang Xu -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Monday, April 1, 2019 3:29 PM To: TF-M(a)lists.trustedfirmware.org Subject: [TF-M] PSA Test Suite forum? Hello, Do you have a forum dedicated to the PSA Test-suite (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… )? Or we may use this one? Thanks Andrej -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 7 months

1
0
0 0

Re: [TF-M] PSA Test Suite forum?

by Qixiang Xu (Arm Technology China)

Andrej, You can report any issue or concern at: https://github.com/ARM-software/psa-arch-tests/issues Best Regards, Qixiang Xu -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Monday, April 1, 2019 3:29 PM To: TF-M(a)lists.trustedfirmware.org Subject: [TF-M] PSA Test Suite forum? Hello, Do you have a forum dedicated to the PSA Test-suite (https://github.com/ARM-software/psa-arch-tests )? Or we may use this one? Thanks Andrej -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 7 months

2
2
0 0

PSA Test Suite forum?

by Andrej Butok

Hello, Do you have a forum dedicated to the PSA Test-suite (https://github.com/ARM-software/psa-arch-tests )? Or we may use this one? Thanks Andrej

6 years, 7 months

1
0
0 0

[twin-cpu]Dual core communication design document for review

by David Hu (Arm Technology China)

Hi all, I've posted a design document for dual core communication in twin cpu project. Could you please review it at https://developer.trustedfirmware.org/w/tf_m/design/twin-cpu/communication_… Any comment is welcome. Thank you. Best regards, Hu Ziji

6 years, 7 months

2
4
0 0

[RFC] Isolation level 2 patches

by Ken Liu (Arm Technology China)

Hi, The isolation level 2 patches are pushed for reviewing; you can find all of them under the issue: https://developer.trustedfirmware.org/T294 The design document was put at: https://developer.trustedfirmware.org/w/tf_m/design/trusted_firmware-m_isol… The first group of patches are working on AN521 with ARMCLANG build. Rest options supporting would come later. With higher isolation level, some functions may not work such as CLIB (malloc/free e.g.). These features need to be supported after dedicated implementation is done. You can check the [RFC] discussion sent in mailing list of the isolation level 2 for details. Isolation level 2 use dedicated config file: "ConfigCoreIPCTfmLevel2.cmake" so the IPC on isolation level 1 is not affected by this change. Please help to comment in documents and patches - current the document has no comment area so you can put comments under the issue link, or just reply in mailing list. Creating issues is another valid options ; ) Thanks! -Ken

6 years, 7 months

1
0
0 0

Re: [TF-M] [EXTERNAL] Re: Please explain tfm_register_client_id() use case

by DeMars, Alan

Yes, that idea would resolve the problem. I’m not sure I understand the use case for multiple updates to a context’s client Id. What is the thought behind that? Alan > On Mar 28, 2019, at 2:23 AM, Miklos Balint via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Alan, > > You are absolutely right that registering client ID should normally be done once, preferably right after AllocModule. > > The current design allows multiple updates to be made, and for this to be possible, we identify the one to be updated by it being the active one. > > I do see an opportunity to extend this so that the last NS context to be Allocated can also be assumed to be the target of a registration in lieu of the active context if there isn't one. > This way we keep the option to update ID when a context is active while also allow an easy and low overhead registration for the context that's latest to have been Allocated. > > Is this an acceptable amendment? > > Regards > Miklos > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M > Sent: 26 March 2019 00:00 > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] Please explain tfm_register_client_id() use case > > As currently specified, I don't see a simple way to invoke the tfm_register_client_id() API ONLY ONCE for each NS client thread. > > It appears that tfm_register_client_id() must be called after TZ_LoadContext_S() because the clientId provided by tfm_register_client_id() is always associated with the CURRENT NS MemoryId. > > However, TZ_LoadContext_S() is designed to be called only when the NS OS actually switches to a new NS thread. This creates pressure for tfm_register_client_id() to be called during a NS thread switch. However, calling tfm_register_client_id() on EVERY NS context switch is redundant and CPU wasteful. Adding code to test whether tfm_register_client_id() has already been called for a particular NS thread also seems wasteful. > > What seems natural to me is to add a MemoryId argument to tfm_register_client_id() so that the clientID can be mapped to the MemoryId provided by TZ_AllocModuleContext_S() right after TZ_AllocModuleContext_S() is called (ie only once). > > Please correct my understanding of how tfm_register_client_id() is intended to be used if the above analysis is off base. > > Alan > > > -- > 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

6 years, 7 months

2
1
0 0

Re: [TF-M] [RFC] twin cpu bootloader design document

by David Hu (Arm Technology China)

Hi Chris, Sorry for the delayed reply. Please check my comments in below. Just about small details. Please correct me if I misunderstand anything. 1. In my own opinion, it can be possible to use IPC to synchronize mailbox services between two cores, during initialization. The synchronization is only trigged when the mailbox mechanism is ready on mailbox server or client. It means that the IPC module should be also configured. Based on the above assumption, using IPC to synchronize the two cores is more generic and convenient than accessing shared memory. If using shared memory to pass status flag, it can be necessary to adjust the address of the shared memory occasionally according to the memory assignment in different applications. 2. I'd like to suggest that we shall discuss more about when the booting HAL APIs are invoked in TF-M. `tfm_core_init()` initializes the TF-M core. Thus in theory, `tfm_core_init()` is irrelevant to the system topology or platform implementations. As a result, IMO, it can be more reasonable to put the HAL APIs outside the `tfm_core_init()`. 3. ` tfm_spm_hal_wait_for_ns_cpu_ready()` can be optional. The secure core acts as a server and it is driven by the request from NS core. The secure core actually doesn't have to wait for an explicit signal to know NS is ready. The synchronization can be guaranteed if NS core starts request via mailbox only after secure core is available. 4. It can be unnecessary to require calling `tfm_spm_hal_wait_for_s_cpu_ready()` in NS `main()`. It might be too early to wait in `main()` and may block other initializations which don't rely on mailbox. This API can be invoked in mailbox functionalities. The whole NS initialization can continue, including enabling application threads, until a NS application requests Secure services via mailbox at the very first time. Thus the whole dual core design can be more generic since the mailbox workflow should be identical on diverse platforms. And we can save the time and effort to hack each RTOS initialization. In other words, I wonder if we can make calling `tfm_spm_hal_wait_for_s_cpu_ready()` in NS `main() as an option and allow other implementations. Thank you. Best regards, Hu Ziji -------------------------------------------------------------------------------------------------------------- Date: Thu, 14 Mar 2019 18:50:56 +0000 From: Christopher Brand <chris.brand(a)cypress.com> To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] [RFC] twin cpu bootloader design document Message-ID: <BYAPR06MB5301EBF02F4C0B60A9BB7742FE4B0(a)BYAPR06MB5301.namprd06.prod.outlook.com> Content-Type: text/plain; charset="us-ascii" Hi, I've posted a design document for bootloader changes to support twin cpu at https://developer.trustedfirmware.org/w/tf_m/design/twin-cpu/bootloader/ Comments appreciated! Thanks, Chris

6 years, 7 months

3
7
0 0

proposed change in Musca B1

by Tamas Kaman

Hi All, I'd like to notify everyone about a proposed change in Musca B1 platform in TF-M. Everyone who is using that platform might be affected. The code on Musca B1 is currently running from the external QSPI flash. With the coming change this moves to a much faster internal embedded Flash, so all you might observe is faster code execution. Link to review: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/669/ Also, for loading the image to the a board another version of DAPLink FW will be needed. The eFlash type DAPLink FW can be downloaded from Arm Community page: https://community.arm.com/developer/tools-software/oss-platforms/w/docs/425… A short description of how to update the DAPLink FW can be found here as well. Thanks, Tamas IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 7 months

1
0
0 0

Re: [TF-M] Please explain tfm_register_client_id() use case

by Miklos Balint

Alan, You are absolutely right that registering client ID should normally be done once, preferably right after AllocModule. The current design allows multiple updates to be made, and for this to be possible, we identify the one to be updated by it being the active one. I do see an opportunity to extend this so that the last NS context to be Allocated can also be assumed to be the target of a registration in lieu of the active context if there isn't one. This way we keep the option to update ID when a context is active while also allow an easy and low overhead registration for the context that's latest to have been Allocated. Is this an acceptable amendment? Regards Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 26 March 2019 00:00 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Please explain tfm_register_client_id() use case As currently specified, I don't see a simple way to invoke the tfm_register_client_id() API ONLY ONCE for each NS client thread. It appears that tfm_register_client_id() must be called after TZ_LoadContext_S() because the clientId provided by tfm_register_client_id() is always associated with the CURRENT NS MemoryId. However, TZ_LoadContext_S() is designed to be called only when the NS OS actually switches to a new NS thread. This creates pressure for tfm_register_client_id() to be called during a NS thread switch. However, calling tfm_register_client_id() on EVERY NS context switch is redundant and CPU wasteful. Adding code to test whether tfm_register_client_id() has already been called for a particular NS thread also seems wasteful. What seems natural to me is to add a MemoryId argument to tfm_register_client_id() so that the clientID can be mapped to the MemoryId provided by TZ_AllocModuleContext_S() right after TZ_AllocModuleContext_S() is called (ie only once). Please correct my understanding of how tfm_register_client_id() is intended to be used if the above analysis is off base. Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 7 months

1
0
0 0

Re: [TF-M] SYSTICK ownership

by Ken Liu (Arm Technology China)

Hi Alan, Sorry for the late response - the secure IRQ patches are on the way but currently we don't have scenarios for this case. We would create a ticket for tracking this question and let's collect comment there. And, this topic sounds like a timer requirement, so can you tell the actual user scenario? For example, would there still be requirements of using SYSTICK in secure partition if some timer things is available? Thanks. -Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of DeMars, Alan via TF-M Sent: 19 February 2019 02:47 To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com<mailto:Ken.Liu@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] SYSTICK ownership My concern was the value one would provide for the "line_num" field within the manifest. The SYSTICK uses vector 15 which I believe would correspond to "line_num" = -1. I'm not sure the design accommodates negative line_nums. Also, disabling the SYSTICK interrupt while servicing its interrupt can't be handled in the normal way user IRQs are disabled. Special case code would be required in the SPM to support the SYSTICK as a secure partition interrupt. Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Monday, February 18, 2019 5:34 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd Subject: [EXTERNAL] Re: [TF-M] SYSTICK ownership Hi Alan, >From your description, it looks like you want to use secure SYSTICK as an interrupt for Secure Partition, is this correct? In this case, it is similar to the secure interrupt usage. Since the interrupt handling is under developing, I will add a note in the task to remind how we could add SYSTICK as an interrupt in the manifest. BR -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of > DeMars, Alan via TF-M > Sent: Saturday, February 16, 2019 7:02 AM > To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> > Subject: [TF-M] SYSTICK ownership > > If not used anywhere else, can a Secure Partition own the secure > SYSTICK timer and its interrupt? > If so, how is it specified in the SP manifest? > > Alan > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 7 months

1
0
0 0

Re: [TF-M] TFM Core regression tests

by Andrej Butok

Hi Mate, OK. It's good to know that this is the known issue. I will wait for a final review and merge. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Mate Toth-Pal via TF-M Sent: Wednesday, March 27, 2019 2:45 PM To: TF-M(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TFM Core regression tests Hi Andrej, Yes, on the master branch this is a limitation. I already have a few patches on review to fix this: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… They are most probably going to be merged with the secure IRQ handling commits. You can also cherry pick those for yourself for testing purposes, there should be no conflict, as it is quite independent from the parent commits on review. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 27 March 2019 14:32 To: TF-M(a)lists.trustedfirmware.org Subject: [TF-M] TFM Core regression tests Hello We are trying to enable & compile TFM Core tests. But it looks like they are only for MPS2 platform: 1) tfm_ss_core_test.c: .... #include "smm_mps2.h" ... static psa_status_t test_peripheral_access(void) { struct arm_mps2_fpgaio_t *fpgaio = SEC_MPS2_FPGAIO; ... etc. 2) tfm_partition_list.inc ... #ifdef TFM_PARTITION_TEST_CORE ... PARTITION_ADD_PERIPHERAL(TFM_SP_CORE_TEST, TFM_PERIPHERAL_FPGA_IO); #endif /* TFM_PARTITION_TEST_CORE */ ... What do you suggest ? What is the plan? Should we to skip/ignore the TFM Core regression tests now? Thanks Andrej Butok SW Tech Lead Security & Connectivity, Microcontrollers NXP Semiconductors -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 7 months

1
0
0 0

Re: [TF-M] TFM Core regression tests

by Mate Toth-Pal

Hi Andrej, Yes, on the master branch this is a limitation. I already have a few patches on review to fix this: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/693/10 https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/683/11 They are most probably going to be merged with the secure IRQ handling commits. You can also cherry pick those for yourself for testing purposes, there should be no conflict, as it is quite independent from the parent commits on review. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 27 March 2019 14:32 To: TF-M(a)lists.trustedfirmware.org Subject: [TF-M] TFM Core regression tests Hello We are trying to enable & compile TFM Core tests. But it looks like they are only for MPS2 platform: 1) tfm_ss_core_test.c: .... #include "smm_mps2.h" ... static psa_status_t test_peripheral_access(void) { struct arm_mps2_fpgaio_t *fpgaio = SEC_MPS2_FPGAIO; ... etc. 2) tfm_partition_list.inc ... #ifdef TFM_PARTITION_TEST_CORE ... PARTITION_ADD_PERIPHERAL(TFM_SP_CORE_TEST, TFM_PERIPHERAL_FPGA_IO); #endif /* TFM_PARTITION_TEST_CORE */ ... What do you suggest ? What is the plan? Should we to skip/ignore the TFM Core regression tests now? Thanks Andrej Butok SW Tech Lead Security & Connectivity, Microcontrollers NXP Semiconductors -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 7 months

1
0
0 0

TFM Core regression tests

by Andrej Butok

Hello We are trying to enable & compile TFM Core tests. But it looks like they are only for MPS2 platform: 1) tfm_ss_core_test.c: .... #include "smm_mps2.h" ... static psa_status_t test_peripheral_access(void) { struct arm_mps2_fpgaio_t *fpgaio = SEC_MPS2_FPGAIO; ... etc. 2) tfm_partition_list.inc ... #ifdef TFM_PARTITION_TEST_CORE ... PARTITION_ADD_PERIPHERAL(TFM_SP_CORE_TEST, TFM_PERIPHERAL_FPGA_IO); #endif /* TFM_PARTITION_TEST_CORE */ ... What do you suggest ? What is the plan? Should we to skip/ignore the TFM Core regression tests now? Thanks Andrej Butok SW Tech Lead Security & Connectivity, Microcontrollers NXP Semiconductors

6 years, 7 months

1
0
0 0

Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M

by Andrej Butok

Thank you, Antonio Looking forward for the 100% Crypto Service usage, it will solve the mbedTLS duplication issue. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Tuesday, March 26, 2019 4:37 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi, Regarding the below: > Why the TFM services (SST, attestation) do not call PSA Crypto API? Attestation already calls the PSA Crypto APIs, and we are working actively on implementing the crypto bindings for SST to call the corresponding PSA Crypto API's. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang (Arm Technology China) via TF-M Sent: 26 March 2019 08:18 To: tf-m(a)lists.trustedfirmware.org; Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi Andrej, Yes, I agree this is a useful design to mitigate the code size issue. Just sharing the advice from security perspective. Basically, we need to review the shared libs carefully(one of the focus of threat modelling). It's not a mandatory limit. From PSA FF spec v1.0 beta1 section 3.1.4 (Mandatory isolation rules) and 3.1.5 (Optional isolation rules), it's OK to have the shared RO code sections. It doesn't break the mandatory isolation rule I3 - If domain A needs protection from domain B, then Private data in domain A cannot be accessed by domain B. But it's worth to notice/mention that this will break optional isolation rules I4 and I5. I4 - If domain A needs protection from domain B, then Code and Constant data in domain A is not readable or executable by domain B. I5 - Code in a domain is not executable by any other domain. It makes sense to give the choice to the users. (may notify the user about the potential security risk) > Why the TFM services (SST, attestation) do not call PSA Crypto API? I think the experts of the modules might be more suitable than me to answer this question. 😊 Thanks. Hi @Ken Liu (Arm Technology China), I got your reply in another thread, so just to gather them here. >For first point, we can take a security analysis on this part and check if there are vulnerabilities. >The security requirement for these code are quite high, you can take 'memset' as example, it is read-only, caller stack based so no footprint would leave to another caller. Yes, like I mentioned above it's one of the focus of threat modelling. >For seconds point, it is do-able -- but need big change everywhere; and it back to the per-partition library design while we move to isolation level 3. Understand. Just thinking if we can keep the shared libs in the same protection domain. (to avoid breaking optional isolation rules) BTW, from PSA FF spec v1.0 beta1 section 3.1.2(memory access rules) rule l1, we may need to consider the separation of RO-Code and RO-data(execution never). Thanks. Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Monday, March 25, 2019 7:04 PM To: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi David, > Using shared libraries may give the window to exploit the vulnerabilities. Yes, you are right. BUT Code size may be a very critical parameter especially for constrained MCUs. Please do not give any mandatory limits. If any, they should be configurable. Let's give a possibility to choose for final users. BTW: 1) Current TF-M is using library approach with mbedTLS copy per each service. OK, security => but wasting of resources. In our code, we are using one copy of mbedTLS to avoid this type of wasting, but it requires original code modification. Please, give more freedom to final TFM users! 2) Why the TFM services (SST, attestation) do not call PSA Crypto API? It will eliminates mbedTLS duplication. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang (Arm Technology China) via TF-M Sent: Monday, March 25, 2019 10:57 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi Ken, Some comments from security review's perspective. * Using shared libraries may give the window to exploit the vulnerabilities. App RoT can analyze the shared lib to find out the useable vulnerabilities for attacking PSA RoT. * Is it a good idea to have two separate shared libs - one for all app RoT and one for all PSA RoT for isolation level2? (can still share one copy for level1.) Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Monday, March 25, 2019 5:05 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi, The document is updated due to a change in MPU regions part: In original design, some partition libraries like 'thread_exit' is going to be linked with partition statically, which means there would be multiple copies of these libraries for each partition. This provided strict protection of isolation but it looks over-protect. If we keep one shared code region for each partition to call these libraries, we could: * Save memory * The protection is enough if we mark the code area as read-only. In this case, the unprivileged code and RO region needs to be kept and these shared codes could be put there. The requirement of these codes are: * These codes must be thread safe and reentrant * These codes must be put in read-only region The change mainly happen under section "Linker script sections re-arrangement". Please help to comment. Thanks! -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > Liu (Arm Technology China) via TF-M > Sent: Thursday, March 21, 2019 3:20 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M > > Hi, > The document is updated, and keep open for comments ; ) > > The updated content is: > > 1. Available MPU regions for peripheral has number limitation based > on platform. If a SP needs many un-continuous peripheral registers and > the number exceeds available MPU number, it needs further investigation. > 2. Rely on linker to clean the unused object files instead of > remove them in scatter before the dependency is fully figured out. > > Thanks! > > -Ken > > From: Ken Liu (Arm Technology China) > Sent: Tuesday, February 19, 2019 6:44 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [RFC] Design document of isolation level 2 on TF-M > > Hello, > The first IPC implementation works under isolation level 1. The high > isolation levels need to be there to get compatible with PSA Firmware > Framework. A design document is created about implementing isolation level 2 for IPC model: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeve > loper.trustedfirmware.org%2Fw%2Ftf_m%2Fdesign%2Ftrusted_firmware-& > data=02%7C01%7Candrey.butok%40nxp.com%7C6a9c2cb6a5034aec48b908d6b10845 > 48%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636891046406628979&amp > ;sdata=yPus0lkd4L71ng5Z5o2hu2bDEMBAzSwUxAm1fyYf564%3D&reserved=0 > m_isolation_level_2/ > > The mainly change of isolation level 2 compare to isolation level 1 is: > * Put AppRoT Secure Partitions' components with same attribute (code, > read- only data, read-write data) into the same region, which helps > MPU setting region attributes. > * Change Secure Partition privileged setting based on Secure Partition > type while scheduling. > * Change mechanism of privileged API, such as printf. > > If you have any comments please share it. You can reply in mailing > list if there is no place for putting comments on the page. > > Thank you! > > -Ken > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-m&data=02%7C01%7Ca > ndrey.butok%40nxp.com%7C6a9c2cb6a5034aec48b908d6b1084548%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636891046406638984&sdata=7Wva1R6Lv > EKMxCpaVr6gRE26Fodub%2FPTQlLOiB2YvX0%3D&reserved=0 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 7 months

1
0
0 0

Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M

by Antonio De Angelis

Hi, Regarding the below: > Why the TFM services (SST, attestation) do not call PSA Crypto API? Attestation already calls the PSA Crypto APIs, and we are working actively on implementing the crypto bindings for SST to call the corresponding PSA Crypto API's. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang (Arm Technology China) via TF-M Sent: 26 March 2019 08:18 To: tf-m(a)lists.trustedfirmware.org; Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi Andrej, Yes, I agree this is a useful design to mitigate the code size issue. Just sharing the advice from security perspective. Basically, we need to review the shared libs carefully(one of the focus of threat modelling). It's not a mandatory limit. From PSA FF spec v1.0 beta1 section 3.1.4 (Mandatory isolation rules) and 3.1.5 (Optional isolation rules), it's OK to have the shared RO code sections. It doesn't break the mandatory isolation rule I3 - If domain A needs protection from domain B, then Private data in domain A cannot be accessed by domain B. But it's worth to notice/mention that this will break optional isolation rules I4 and I5. I4 - If domain A needs protection from domain B, then Code and Constant data in domain A is not readable or executable by domain B. I5 - Code in a domain is not executable by any other domain. It makes sense to give the choice to the users. (may notify the user about the potential security risk) > Why the TFM services (SST, attestation) do not call PSA Crypto API? I think the experts of the modules might be more suitable than me to answer this question. 😊 Thanks. Hi @Ken Liu (Arm Technology China), I got your reply in another thread, so just to gather them here. >For first point, we can take a security analysis on this part and check if there are vulnerabilities. >The security requirement for these code are quite high, you can take 'memset' as example, it is read-only, caller stack based so no footprint would leave to another caller. Yes, like I mentioned above it's one of the focus of threat modelling. >For seconds point, it is do-able -- but need big change everywhere; and it back to the per-partition library design while we move to isolation level 3. Understand. Just thinking if we can keep the shared libs in the same protection domain. (to avoid breaking optional isolation rules) BTW, from PSA FF spec v1.0 beta1 section 3.1.2(memory access rules) rule l1, we may need to consider the separation of RO-Code and RO-data(execution never). Thanks. Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Monday, March 25, 2019 7:04 PM To: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi David, > Using shared libraries may give the window to exploit the vulnerabilities. Yes, you are right. BUT Code size may be a very critical parameter especially for constrained MCUs. Please do not give any mandatory limits. If any, they should be configurable. Let's give a possibility to choose for final users. BTW: 1) Current TF-M is using library approach with mbedTLS copy per each service. OK, security => but wasting of resources. In our code, we are using one copy of mbedTLS to avoid this type of wasting, but it requires original code modification. Please, give more freedom to final TFM users! 2) Why the TFM services (SST, attestation) do not call PSA Crypto API? It will eliminates mbedTLS duplication. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang (Arm Technology China) via TF-M Sent: Monday, March 25, 2019 10:57 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi Ken, Some comments from security review's perspective. * Using shared libraries may give the window to exploit the vulnerabilities. App RoT can analyze the shared lib to find out the useable vulnerabilities for attacking PSA RoT. * Is it a good idea to have two separate shared libs - one for all app RoT and one for all PSA RoT for isolation level2? (can still share one copy for level1.) Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Monday, March 25, 2019 5:05 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi, The document is updated due to a change in MPU regions part: In original design, some partition libraries like 'thread_exit' is going to be linked with partition statically, which means there would be multiple copies of these libraries for each partition. This provided strict protection of isolation but it looks over-protect. If we keep one shared code region for each partition to call these libraries, we could: * Save memory * The protection is enough if we mark the code area as read-only. In this case, the unprivileged code and RO region needs to be kept and these shared codes could be put there. The requirement of these codes are: * These codes must be thread safe and reentrant * These codes must be put in read-only region The change mainly happen under section "Linker script sections re-arrangement". Please help to comment. Thanks! -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > Liu (Arm Technology China) via TF-M > Sent: Thursday, March 21, 2019 3:20 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M > > Hi, > The document is updated, and keep open for comments ; ) > > The updated content is: > > 1. Available MPU regions for peripheral has number limitation based > on platform. If a SP needs many un-continuous peripheral registers and > the number exceeds available MPU number, it needs further investigation. > 2. Rely on linker to clean the unused object files instead of > remove them in scatter before the dependency is fully figured out. > > Thanks! > > -Ken > > From: Ken Liu (Arm Technology China) > Sent: Tuesday, February 19, 2019 6:44 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [RFC] Design document of isolation level 2 on TF-M > > Hello, > The first IPC implementation works under isolation level 1. The high > isolation levels need to be there to get compatible with PSA Firmware > Framework. A design document is created about implementing isolation level 2 for IPC model: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeve > loper.trustedfirmware.org%2Fw%2Ftf_m%2Fdesign%2Ftrusted_firmware-& > data=02%7C01%7Candrey.butok%40nxp.com%7C6a9c2cb6a5034aec48b908d6b10845 > 48%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636891046406628979&amp > ;sdata=yPus0lkd4L71ng5Z5o2hu2bDEMBAzSwUxAm1fyYf564%3D&reserved=0 > m_isolation_level_2/ > > The mainly change of isolation level 2 compare to isolation level 1 is: > * Put AppRoT Secure Partitions' components with same attribute (code, > read- only data, read-write data) into the same region, which helps > MPU setting region attributes. > * Change Secure Partition privileged setting based on Secure Partition > type while scheduling. > * Change mechanism of privileged API, such as printf. > > If you have any comments please share it. You can reply in mailing > list if there is no place for putting comments on the page. > > Thank you! > > -Ken > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-m&data=02%7C01%7Ca > ndrey.butok%40nxp.com%7C6a9c2cb6a5034aec48b908d6b1084548%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636891046406638984&sdata=7Wva1R6Lv > EKMxCpaVr6gRE26Fodub%2FPTQlLOiB2YvX0%3D&reserved=0 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- 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

6 years, 7 months

1
0
0 0

Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M

by David Wang (Arm Technology China)

Hi Andrej, Yes, I agree this is a useful design to mitigate the code size issue. Just sharing the advice from security perspective. Basically, we need to review the shared libs carefully(one of the focus of threat modelling). It's not a mandatory limit. From PSA FF spec v1.0 beta1 section 3.1.4 (Mandatory isolation rules) and 3.1.5 (Optional isolation rules), it's OK to have the shared RO code sections. It doesn't break the mandatory isolation rule I3 - If domain A needs protection from domain B, then Private data in domain A cannot be accessed by domain B. But it's worth to notice/mention that this will break optional isolation rules I4 and I5. I4 - If domain A needs protection from domain B, then Code and Constant data in domain A is not readable or executable by domain B. I5 - Code in a domain is not executable by any other domain. It makes sense to give the choice to the users. (may notify the user about the potential security risk) > Why the TFM services (SST, attestation) do not call PSA Crypto API? I think the experts of the modules might be more suitable than me to answer this question. 😊 Thanks. Hi @Ken Liu (Arm Technology China), I got your reply in another thread, so just to gather them here. >For first point, we can take a security analysis on this part and check if there are vulnerabilities. >The security requirement for these code are quite high, you can take 'memset' as example, it is read-only, caller stack based so no footprint would leave to another caller. Yes, like I mentioned above it's one of the focus of threat modelling. >For seconds point, it is do-able -- but need big change everywhere; and it back to the per-partition library design while we move to isolation level 3. Understand. Just thinking if we can keep the shared libs in the same protection domain. (to avoid breaking optional isolation rules) BTW, from PSA FF spec v1.0 beta1 section 3.1.2(memory access rules) rule l1, we may need to consider the separation of RO-Code and RO-data(execution never). Thanks. Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Monday, March 25, 2019 7:04 PM To: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi David, > Using shared libraries may give the window to exploit the vulnerabilities. Yes, you are right. BUT Code size may be a very critical parameter especially for constrained MCUs. Please do not give any mandatory limits. If any, they should be configurable. Let's give a possibility to choose for final users. BTW: 1) Current TF-M is using library approach with mbedTLS copy per each service. OK, security => but wasting of resources. In our code, we are using one copy of mbedTLS to avoid this type of wasting, but it requires original code modification. Please, give more freedom to final TFM users! 2) Why the TFM services (SST, attestation) do not call PSA Crypto API? It will eliminates mbedTLS duplication. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang (Arm Technology China) via TF-M Sent: Monday, March 25, 2019 10:57 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi Ken, Some comments from security review's perspective. * Using shared libraries may give the window to exploit the vulnerabilities. App RoT can analyze the shared lib to find out the useable vulnerabilities for attacking PSA RoT. * Is it a good idea to have two separate shared libs - one for all app RoT and one for all PSA RoT for isolation level2? (can still share one copy for level1.) Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Monday, March 25, 2019 5:05 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi, The document is updated due to a change in MPU regions part: In original design, some partition libraries like 'thread_exit' is going to be linked with partition statically, which means there would be multiple copies of these libraries for each partition. This provided strict protection of isolation but it looks over-protect. If we keep one shared code region for each partition to call these libraries, we could: * Save memory * The protection is enough if we mark the code area as read-only. In this case, the unprivileged code and RO region needs to be kept and these shared codes could be put there. The requirement of these codes are: * These codes must be thread safe and reentrant * These codes must be put in read-only region The change mainly happen under section "Linker script sections re-arrangement". Please help to comment. Thanks! -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > Liu (Arm Technology China) via TF-M > Sent: Thursday, March 21, 2019 3:20 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M > > Hi, > The document is updated, and keep open for comments ; ) > > The updated content is: > > 1. Available MPU regions for peripheral has number limitation based > on platform. If a SP needs many un-continuous peripheral registers and > the number exceeds available MPU number, it needs further investigation. > 2. Rely on linker to clean the unused object files instead of > remove them in scatter before the dependency is fully figured out. > > Thanks! > > -Ken > > From: Ken Liu (Arm Technology China) > Sent: Tuesday, February 19, 2019 6:44 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [RFC] Design document of isolation level 2 on TF-M > > Hello, > The first IPC implementation works under isolation level 1. The high > isolation levels need to be there to get compatible with PSA Firmware > Framework. A design document is created about implementing isolation level 2 for IPC model: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeve > loper.trustedfirmware.org%2Fw%2Ftf_m%2Fdesign%2Ftrusted_firmware-& > data=02%7C01%7Candrey.butok%40nxp.com%7C6a9c2cb6a5034aec48b908d6b10845 > 48%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636891046406628979&amp > ;sdata=yPus0lkd4L71ng5Z5o2hu2bDEMBAzSwUxAm1fyYf564%3D&reserved=0 > m_isolation_level_2/ > > The mainly change of isolation level 2 compare to isolation level 1 is: > * Put AppRoT Secure Partitions' components with same attribute (code, > read- only data, read-write data) into the same region, which helps > MPU setting region attributes. > * Change Secure Partition privileged setting based on Secure Partition > type while scheduling. > * Change mechanism of privileged API, such as printf. > > If you have any comments please share it. You can reply in mailing > list if there is no place for putting comments on the page. > > Thank you! > > -Ken > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-m&data=02%7C01%7Ca > ndrey.butok%40nxp.com%7C6a9c2cb6a5034aec48b908d6b1084548%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636891046406638984&sdata=7Wva1R6Lv > EKMxCpaVr6gRE26Fodub%2FPTQlLOiB2YvX0%3D&reserved=0 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 7 months

1
0
0 0

Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M

by Ken Liu (Arm Technology China)

Hi, For first point, we can take a security analysis on this part and check if there are vulnerabilities. The security requirement for these code are quite high, you can take 'memset' as example, it is read-only, caller stack based so no footprint would leave to another caller. For seconds point, it is do-able -- but need big change everywhere; and it back to the per-partition library design while we move to isolation level 3. -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David > Wang (Arm Technology China) via TF-M > Sent: Monday, March 25, 2019 5:57 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M > > Hi Ken, > Some comments from security review's perspective. > * Using shared libraries may give the window to exploit the vulnerabilities. App > RoT can analyze the shared lib to find out the useable vulnerabilities for > attacking PSA RoT. > * Is it a good idea to have two separate shared libs - one for all app RoT and one > for all PSA RoT for isolation level2? (can still share one copy for level1.) > > Regards, > David Wang > Arm Electronic Technology (Shanghai) Co., Ltd > Phone: +86-21-6154 9142 (ext. 59142) > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu > (Arm Technology China) via TF-M > Sent: Monday, March 25, 2019 5:05 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M > > Hi, > > The document is updated due to a change in MPU regions part: > > In original design, some partition libraries like 'thread_exit' is going to be linked > with partition statically, which means there would be multiple copies of these > libraries for each partition. This provided strict protection of isolation but it > looks over-protect. > > If we keep one shared code region for each partition to call these libraries, we > could: > * Save memory > * The protection is enough if we mark the code area as read-only. > > In this case, the unprivileged code and RO region needs to be kept and these > shared codes could be put there. > The requirement of these codes are: > * These codes must be thread safe and reentrant > * These codes must be put in read-only region > > The change mainly happen under section "Linker script sections re-arrangement". > Please help to comment. > > Thanks! > > -Ken > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > > Liu (Arm Technology China) via TF-M > > Sent: Thursday, March 21, 2019 3:20 PM > > To: tf-m(a)lists.trustedfirmware.org > > Cc: nd <nd(a)arm.com> > > Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M > > > > Hi, > > The document is updated, and keep open for comments ; ) > > > > The updated content is: > > > > 1. Available MPU regions for peripheral has number limitation based > > on platform. If a SP needs many un-continuous peripheral registers and > > the number exceeds available MPU number, it needs further investigation. > > 2. Rely on linker to clean the unused object files instead of > > remove them in scatter before the dependency is fully figured out. > > > > Thanks! > > > > -Ken > > > > From: Ken Liu (Arm Technology China) > > Sent: Tuesday, February 19, 2019 6:44 PM > > To: tf-m(a)lists.trustedfirmware.org > > Cc: nd <nd(a)arm.com> > > Subject: [RFC] Design document of isolation level 2 on TF-M > > > > Hello, > > The first IPC implementation works under isolation level 1. The high > > isolation levels need to be there to get compatible with PSA Firmware > > Framework. A design document is created about implementing isolation level 2 > for IPC model: > > https://developer.trustedfirmware.org/w/tf_m/design/trusted_firmware- > > m_isolation_level_2/ > > > > The mainly change of isolation level 2 compare to isolation level 1 is: > > * Put AppRoT Secure Partitions' components with same attribute (code, > > read- only data, read-write data) into the same region, which helps > > MPU setting region attributes. > > * Change Secure Partition privileged setting based on Secure Partition > > type while scheduling. > > * Change mechanism of privileged API, such as printf. > > > > If you have any comments please share it. You can reply in mailing > > list if there is no place for putting comments on the page. > > > > Thank you! > > > > -Ken > > > > -- > > 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 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 7 months

1
0
0 0

Please explain tfm_register_client_id() use case

by DeMars, Alan

As currently specified, I don't see a simple way to invoke the tfm_register_client_id() API ONLY ONCE for each NS client thread. It appears that tfm_register_client_id() must be called after TZ_LoadContext_S() because the clientId provided by tfm_register_client_id() is always associated with the CURRENT NS MemoryId. However, TZ_LoadContext_S() is designed to be called only when the NS OS actually switches to a new NS thread. This creates pressure for tfm_register_client_id() to be called during a NS thread switch. However, calling tfm_register_client_id() on EVERY NS context switch is redundant and CPU wasteful. Adding code to test whether tfm_register_client_id() has already been called for a particular NS thread also seems wasteful. What seems natural to me is to add a MemoryId argument to tfm_register_client_id() so that the clientID can be mapped to the MemoryId provided by TZ_AllocModuleContext_S() right after TZ_AllocModuleContext_S() is called (ie only once). Please correct my understanding of how tfm_register_client_id() is intended to be used if the above analysis is off base. Alan

6 years, 7 months

1
0
0 0

Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M

by Andrej Butok

Hi David, > Using shared libraries may give the window to exploit the vulnerabilities. Yes, you are right. BUT Code size may be a very critical parameter especially for constrained MCUs. Please do not give any mandatory limits. If any, they should be configurable. Let's give a possibility to choose for final users. BTW: 1) Current TF-M is using library approach with mbedTLS copy per each service. OK, security => but wasting of resources. In our code, we are using one copy of mbedTLS to avoid this type of wasting, but it requires original code modification. Please, give more freedom to final TFM users! 2) Why the TFM services (SST, attestation) do not call PSA Crypto API? It will eliminates mbedTLS duplication. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang (Arm Technology China) via TF-M Sent: Monday, March 25, 2019 10:57 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi Ken, Some comments from security review's perspective. * Using shared libraries may give the window to exploit the vulnerabilities. App RoT can analyze the shared lib to find out the useable vulnerabilities for attacking PSA RoT. * Is it a good idea to have two separate shared libs - one for all app RoT and one for all PSA RoT for isolation level2? (can still share one copy for level1.) Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Monday, March 25, 2019 5:05 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi, The document is updated due to a change in MPU regions part: In original design, some partition libraries like 'thread_exit' is going to be linked with partition statically, which means there would be multiple copies of these libraries for each partition. This provided strict protection of isolation but it looks over-protect. If we keep one shared code region for each partition to call these libraries, we could: * Save memory * The protection is enough if we mark the code area as read-only. In this case, the unprivileged code and RO region needs to be kept and these shared codes could be put there. The requirement of these codes are: * These codes must be thread safe and reentrant * These codes must be put in read-only region The change mainly happen under section "Linker script sections re-arrangement". Please help to comment. Thanks! -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > Liu (Arm Technology China) via TF-M > Sent: Thursday, March 21, 2019 3:20 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M > > Hi, > The document is updated, and keep open for comments ; ) > > The updated content is: > > 1. Available MPU regions for peripheral has number limitation based > on platform. If a SP needs many un-continuous peripheral registers and > the number exceeds available MPU number, it needs further investigation. > 2. Rely on linker to clean the unused object files instead of > remove them in scatter before the dependency is fully figured out. > > Thanks! > > -Ken > > From: Ken Liu (Arm Technology China) > Sent: Tuesday, February 19, 2019 6:44 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [RFC] Design document of isolation level 2 on TF-M > > Hello, > The first IPC implementation works under isolation level 1. The high > isolation levels need to be there to get compatible with PSA Firmware > Framework. A design document is created about implementing isolation level 2 for IPC model: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeve > loper.trustedfirmware.org%2Fw%2Ftf_m%2Fdesign%2Ftrusted_firmware-& > data=02%7C01%7Candrey.butok%40nxp.com%7C6a9c2cb6a5034aec48b908d6b10845 > 48%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636891046406628979&amp > ;sdata=yPus0lkd4L71ng5Z5o2hu2bDEMBAzSwUxAm1fyYf564%3D&reserved=0 > m_isolation_level_2/ > > The mainly change of isolation level 2 compare to isolation level 1 is: > * Put AppRoT Secure Partitions' components with same attribute (code, > read- only data, read-write data) into the same region, which helps > MPU setting region attributes. > * Change Secure Partition privileged setting based on Secure Partition > type while scheduling. > * Change mechanism of privileged API, such as printf. > > If you have any comments please share it. You can reply in mailing > list if there is no place for putting comments on the page. > > Thank you! > > -Ken > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-m&data=02%7C01%7Ca > ndrey.butok%40nxp.com%7C6a9c2cb6a5034aec48b908d6b1084548%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636891046406638984&sdata=7Wva1R6Lv > EKMxCpaVr6gRE26Fodub%2FPTQlLOiB2YvX0%3D&reserved=0 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 7 months

1
0
0 0

Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M

by David Wang (Arm Technology China)

Hi Ken, Some comments from security review's perspective. * Using shared libraries may give the window to exploit the vulnerabilities. App RoT can analyze the shared lib to find out the useable vulnerabilities for attacking PSA RoT. * Is it a good idea to have two separate shared libs - one for all app RoT and one for all PSA RoT for isolation level2? (can still share one copy for level1.) Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Monday, March 25, 2019 5:05 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi, The document is updated due to a change in MPU regions part: In original design, some partition libraries like 'thread_exit' is going to be linked with partition statically, which means there would be multiple copies of these libraries for each partition. This provided strict protection of isolation but it looks over-protect. If we keep one shared code region for each partition to call these libraries, we could: * Save memory * The protection is enough if we mark the code area as read-only. In this case, the unprivileged code and RO region needs to be kept and these shared codes could be put there. The requirement of these codes are: * These codes must be thread safe and reentrant * These codes must be put in read-only region The change mainly happen under section "Linker script sections re-arrangement". Please help to comment. Thanks! -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > Liu (Arm Technology China) via TF-M > Sent: Thursday, March 21, 2019 3:20 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M > > Hi, > The document is updated, and keep open for comments ; ) > > The updated content is: > > 1. Available MPU regions for peripheral has number limitation based > on platform. If a SP needs many un-continuous peripheral registers and > the number exceeds available MPU number, it needs further investigation. > 2. Rely on linker to clean the unused object files instead of > remove them in scatter before the dependency is fully figured out. > > Thanks! > > -Ken > > From: Ken Liu (Arm Technology China) > Sent: Tuesday, February 19, 2019 6:44 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [RFC] Design document of isolation level 2 on TF-M > > Hello, > The first IPC implementation works under isolation level 1. The high > isolation levels need to be there to get compatible with PSA Firmware > Framework. A design document is created about implementing isolation level 2 for IPC model: > https://developer.trustedfirmware.org/w/tf_m/design/trusted_firmware- > m_isolation_level_2/ > > The mainly change of isolation level 2 compare to isolation level 1 is: > * Put AppRoT Secure Partitions' components with same attribute (code, > read- only data, read-write data) into the same region, which helps > MPU setting region attributes. > * Change Secure Partition privileged setting based on Secure Partition > type while scheduling. > * Change mechanism of privileged API, such as printf. > > If you have any comments please share it. You can reply in mailing > list if there is no place for putting comments on the page. > > Thank you! > > -Ken > > -- > 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

6 years, 7 months

1
0
0 0

Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M

by Ken Liu (Arm Technology China)

Hi, The document is updated due to a change in MPU regions part: In original design, some partition libraries like 'thread_exit' is going to be linked with partition statically, which means there would be multiple copies of these libraries for each partition. This provided strict protection of isolation but it looks over-protect. If we keep one shared code region for each partition to call these libraries, we could: * Save memory * The protection is enough if we mark the code area as read-only. In this case, the unprivileged code and RO region needs to be kept and these shared codes could be put there. The requirement of these codes are: * These codes must be thread safe and reentrant * These codes must be put in read-only region The change mainly happen under section "Linker script sections re-arrangement". Please help to comment. Thanks! -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu > (Arm Technology China) via TF-M > Sent: Thursday, March 21, 2019 3:20 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M > > Hi, > The document is updated, and keep open for comments ; ) > > The updated content is: > > 1. Available MPU regions for peripheral has number limitation based on > platform. If a SP needs many un-continuous peripheral registers and the number > exceeds available MPU number, it needs further investigation. > 2. Rely on linker to clean the unused object files instead of remove them in > scatter before the dependency is fully figured out. > > Thanks! > > -Ken > > From: Ken Liu (Arm Technology China) > Sent: Tuesday, February 19, 2019 6:44 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [RFC] Design document of isolation level 2 on TF-M > > Hello, > The first IPC implementation works under isolation level 1. The high isolation > levels need to be there to get compatible with PSA Firmware Framework. A > design document is created about implementing isolation level 2 for IPC model: > https://developer.trustedfirmware.org/w/tf_m/design/trusted_firmware- > m_isolation_level_2/ > > The mainly change of isolation level 2 compare to isolation level 1 is: > * Put AppRoT Secure Partitions' components with same attribute (code, read- > only data, read-write data) into the same region, which helps MPU setting > region attributes. > * Change Secure Partition privileged setting based on Secure Partition type while > scheduling. > * Change mechanism of privileged API, such as printf. > > If you have any comments please share it. You can reply in mailing list if there is > no place for putting comments on the page. > > Thank you! > > -Ken > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 7 months

1
0
0 0

Re: [TF-M] English topics

by Summer Qin (Arm Technology China)

Really sorry! sent by mistake. On 3/21/19, 5:41 PM, "TF-M on behalf of Summer Qin (Arm Technology China) via TF-M" <tf-m-bounces(a)lists.trustedfirmware.org on behalf of tf-m(a)lists.trustedfirmware.org> wrote: IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 7 months

1
0
0 0

English topics

by Summer Qin (Arm Technology China)

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 7 months

1
0
0 0

[RFC] Design document of SST IPC model

by Summer Qin (Arm Technology China)

Hi, The design document of SST IPC compatibility has been updated due to SST supports Protected Storage API now. Please take a look at the document and give feedback if you have: https://developer.trustedfirmware.org/w/tf_m/design/sst_ipc_compatibility/ Thanks a lot! Summer

6 years, 7 months

1
0
0 0

File attribute and line ending in sources

by Edison Ai (Arm Technology China)

Hi， I created two patches to fix the line ending and file attribute problem in the source code. Could you take a look that these patches and mind the file attribute and line ending change while submitting patches? Patches links are here: * https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/723/ * https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/724/ Thanks, Edison

6 years, 7 months

1
0
0 0

[RFC] Design document of isolation level 2 on TF-M

by Ken Liu (Arm Technology China)

Hello, The first IPC implementation works under isolation level 1. The high isolation levels need to be there to get compatible with PSA Firmware Framework. A design document is created about implementing isolation level 2 for IPC model: https://developer.trustedfirmware.org/w/tf_m/design/trusted_firmware-m_isol… The mainly change of isolation level 2 compare to isolation level 1 is: * Put AppRoT Secure Partitions' components with same attribute (code, read-only data, read-write data) into the same region, which helps MPU setting region attributes. * Change Secure Partition privileged setting based on Secure Partition type while scheduling. * Change mechanism of privileged API, such as printf. If you have any comments please share it. You can reply in mailing list if there is no place for putting comments on the page. Thank you! -Ken

6 years, 7 months

1
1
0 0

Re: [TF-M] IPC and clang

by Edison Ai (Arm Technology China)

Hi Andrej, For you question, please see my comments: If I understand well, the Crypto, SST and Attestation services do not use IPC, so far. Right? - Yes. Should the SST/Crypto/Attestation services be disabled when IPC is enabled? - No, we do not have to disable them. May the Library and IPC APIs be used simultaneously? - Yes. When using " ConfigCoreIPC.cmake" configure file with enabling the " REGRESSION", you can see all the regression test can work. What part of TFM is using IPC? - There are two IPC test partitions to use the IPC: trusted-firmware-m/test/test_services/tfm_ipc_client and trusted-firmware-m/test/test_services/tfm_ipc_service. They are used to do basic IPC function tests. Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Wednesday, March 20, 2019 3:36 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] IPC and clang Hi Edison, If I understand well, the Crypto, SST and Attestation services do not use IPC, so far. Right? Should the SST/Crypto/Attestation services be disabled when IPC is enabled? May the Library and IPC APIs be used simultaneously? What part of TFM is using IPC? Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, March 20, 2019 8:22 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] IPC and clang Hi Andrej, We tested the IPC works on Musca A but not try it on Musca B yet. The current IPC related patches are used to enable IPC mechanism, but services such as crypto, protect storage and attestation are yet to make use of IPC. Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, March 19, 2019 6:06 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] IPC and clang Hi Edison, OK. So, according to https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… the armclang IPC was added only to one platform (target/mps2/an521/armclang/mps2_an521_s.sct). What about Musca A and Musca B? Thanks, Andrej -----Original Message----- From: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Sent: Tuesday, March 19, 2019 9:52 AM To: Andrej Butok <andrey.butok(a)nxp.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Hi Andrej, You can see the log history of master branch: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust…p;reserved=0. All the IPC patches had been existed in master branch. You can use the master branch now, all the IPC functions had been ready for GCC and ARMCLANG. Thanks, Edison -----Original Message----- From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Tuesday, March 19, 2019 4:43 PM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Hi Edison, https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust… master head the latest commit is still 4-day old (4 days Core: Retrieve extra parameter from correct positionHEADmaster Summer Qin). Should I wait some time till it will be propagated to the public git? Thanks, Andrej -----Original Message----- From: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Sent: Tuesday, March 19, 2019 9:26 AM To: Andrej Butok <andrey.butok(a)nxp.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Hi Andrej, You are welcome. Now, the "feature-ipc" branch had been merge into the master branch with the merge patch mentioned below. So all the patches in "feature-ipc" branch had been merge into master too. You can find the related IPC patch in the log history of master branch. The IPC can works rightly in GCC and ARMCLANG on master branch. Thanks, Edison -----Original Message----- From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Tuesday, March 19, 2019 4:10 PM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Thanks Adison, Yes, we are using the master branch. When are you planning to merge the mentioned fix to the mainline? Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Tuesday, March 19, 2019 9:00 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] IPC and clang Hi Andrej, I think you mention the "Merge remote-tracking branch 'feature-ipc' into 'master" patch: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…p;reserved=0. This is a merge patch to fix the merge conflicts. The original patch to support to change the linker file is here: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…p;reserved=0. You can see both the linker files for GCC and ARMCLANG are changed. IPC had been developed and tested on both the GCC and ARMLANG already. Thanks for your question. Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, March 19, 2019 3:35 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] IPC and clang Hello, I have noticed, that with adding the IPC feature to master branch, it were updated GCC linker files (#ifdef TFM_PSA_API sections), but ARMCLANG linker files are without any change. Does it mean that IPC was developed and tested only using GCC? Is there a plan to updated the armclang linker files? Thanks, Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 7 months

1
0
0 0

Re: [TF-M] IPC and clang

by Andrej Butok

Hi Edison, If I understand well, the Crypto, SST and Attestation services do not use IPC, so far. Right? Should the SST/Crypto/Attestation services be disabled when IPC is enabled? May the Library and IPC APIs be used simultaneously? What part of TFM is using IPC? Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, March 20, 2019 8:22 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] IPC and clang Hi Andrej, We tested the IPC works on Musca A but not try it on Musca B yet. The current IPC related patches are used to enable IPC mechanism, but services such as crypto, protect storage and attestation are yet to make use of IPC. Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, March 19, 2019 6:06 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] IPC and clang Hi Edison, OK. So, according to https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… the armclang IPC was added only to one platform (target/mps2/an521/armclang/mps2_an521_s.sct). What about Musca A and Musca B? Thanks, Andrej -----Original Message----- From: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Sent: Tuesday, March 19, 2019 9:52 AM To: Andrej Butok <andrey.butok(a)nxp.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Hi Andrej, You can see the log history of master branch: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust…p;reserved=0. All the IPC patches had been existed in master branch. You can use the master branch now, all the IPC functions had been ready for GCC and ARMCLANG. Thanks, Edison -----Original Message----- From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Tuesday, March 19, 2019 4:43 PM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Hi Edison, https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust… master head the latest commit is still 4-day old (4 days Core: Retrieve extra parameter from correct positionHEADmaster Summer Qin). Should I wait some time till it will be propagated to the public git? Thanks, Andrej -----Original Message----- From: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Sent: Tuesday, March 19, 2019 9:26 AM To: Andrej Butok <andrey.butok(a)nxp.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Hi Andrej, You are welcome. Now, the "feature-ipc" branch had been merge into the master branch with the merge patch mentioned below. So all the patches in "feature-ipc" branch had been merge into master too. You can find the related IPC patch in the log history of master branch. The IPC can works rightly in GCC and ARMCLANG on master branch. Thanks, Edison -----Original Message----- From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Tuesday, March 19, 2019 4:10 PM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Thanks Adison, Yes, we are using the master branch. When are you planning to merge the mentioned fix to the mainline? Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Tuesday, March 19, 2019 9:00 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] IPC and clang Hi Andrej, I think you mention the "Merge remote-tracking branch 'feature-ipc' into 'master" patch: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…p;reserved=0. This is a merge patch to fix the merge conflicts. The original patch to support to change the linker file is here: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…p;reserved=0. You can see both the linker files for GCC and ARMCLANG are changed. IPC had been developed and tested on both the GCC and ARMLANG already. Thanks for your question. Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, March 19, 2019 3:35 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] IPC and clang Hello, I have noticed, that with adding the IPC feature to master branch, it were updated GCC linker files (#ifdef TFM_PSA_API sections), but ARMCLANG linker files are without any change. Does it mean that IPC was developed and tested only using GCC? Is there a plan to updated the armclang linker files? Thanks, Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 7 months

1
0
0 0

Feature 'Custom code generating scripts with Jinja2' has been merged

by Ken Liu (Arm Technology China)

Hi, The patch for applying Jinja2 to generate custom code has been merged into branch 'master'. With these two patches, scatter loader template are also supported. IMPORTANT: Please install Jinja2 before using this feature. You can check ' docs/user_guides/tfm_sw_requirement.md' for installation. Thanks. -Ken > -----Original Message----- > From: Ken Liu (Arm Technology China) > Sent: Tuesday, March 19, 2019 7:09 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: RE: Replace custom code generating scripts with Jinja2 > > Hi, > I saw there is no concern raised about applying Jinja2 into TF-M project, and > some code review is done on these patches. > Plan to merge it at end of Mar 19th, if you have something please just shout 😉 > > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/507/ > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/509/ > > Thanks > > -Ken > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > > Liu (Arm Technology China) via TF-M > > Sent: Wednesday, January 23, 2019 2:18 PM > > To: tf-m(a)lists.trustedfirmware.org > > Cc: nd <nd(a)arm.com> > > Subject: Re: [Tf-m] Replace custom code generating scripts with Jinja2 > > > > Hi Mate, > > I have checked your change and the document, it looks quite easy to > > support conditional including. > > I am OK for this tool. > > > > Thanks. > > > > -Ken > > > > From: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > > Sent: Monday, January 21, 2019 9:35 PM > > To: tf-m(a)lists.trustedfirmware.org > > Cc: nd <nd(a)arm.com> > > Subject: Re: Replace custom code generating scripts with Jinja2 > > > > > > Hi Mate, > > > > Thanks for the proposal. It looks nice. > > > > I have read the "Improvements over the current solution" part and I > > think the "More advanced functionality" is the point I am interested > > in. There are some necessary jobs to be done in the code generating > > scripts for IPC; hope using this tool could help on that. One thing we are > investigating is: > > > > * We need to put PSA RoT and APP RoT into different groups in linker script; > > current tool just put all partitions together and ignores partition type. > > > > > > > > Can you help to check if the new tool could make this change easier? > > > > > > > > Thanks. > > > > > > -Ken > > > > ________________________________ > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m- > > bounces(a)lists.trustedfirmware.org>> on behalf of Mate Toth-Pal via > > TF-M <tf- > > m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> > > Sent: Monday, January 21, 2019 8:37:58 PM > > To: > > tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> > > Cc: nd > > Subject: [Tf-m] Replace custom code generating scripts with Jinja2 > > > > Hi All, > > > > Based on the design proposal published here: > > https://developer.trustedfirmware.org/w/tf_m/design/code_generation_wi > > th_j inja2/ I am planning to replace the code generation tool > > currently used in the TF- M with the Jinja2 template engine. > > > > I already prepared the change that implements this. It is available > > for review and testing in this gerrit review: > > https://review.trustedfirmware.org/#/c/trusted- > > firmware-m/+/507/ > > > > Please note, that this introduces a new tool dependency: jinja2 v2.10 > > python library have to be installed to generate code from the > > partition manifests. Earlier than 2.10 versions won't work, as one of > > the templates relies on the namespace feature introduced in this version. > > > > Based on this change I also would like to make the secure sct files > > automatically generated (just like the secure ld files). The gerrit review for this > change is here: > > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/509/ > > > > Should you have any questions, suggestions, objections, please do not > > hesitate to contact! > > > > Thanks, > > Mate > > -- > > 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

6 years, 7 months

1
0
0 0

Re: [TF-M] IPC and clang

by Edison Ai (Arm Technology China)

Hi Andrej, We tested the IPC works on Musca A but not try it on Musca B yet. The current IPC related patches are used to enable IPC mechanism, but services such as crypto, protect storage and attestation are yet to make use of IPC. Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, March 19, 2019 6:06 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] IPC and clang Hi Edison, OK. So, according to https://review.trustedfirmware.org/c/trusted-firmware-m/+/463/ the armclang IPC was added only to one platform (target/mps2/an521/armclang/mps2_an521_s.sct). What about Musca A and Musca B? Thanks, Andrej -----Original Message----- From: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Sent: Tuesday, March 19, 2019 9:52 AM To: Andrej Butok <andrey.butok(a)nxp.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Hi Andrej, You can see the log history of master branch: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust…p;reserved=0. All the IPC patches had been existed in master branch. You can use the master branch now, all the IPC functions had been ready for GCC and ARMCLANG. Thanks, Edison -----Original Message----- From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Tuesday, March 19, 2019 4:43 PM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Hi Edison, https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust… master head the latest commit is still 4-day old (4 days Core: Retrieve extra parameter from correct positionHEADmaster Summer Qin). Should I wait some time till it will be propagated to the public git? Thanks, Andrej -----Original Message----- From: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Sent: Tuesday, March 19, 2019 9:26 AM To: Andrej Butok <andrey.butok(a)nxp.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Hi Andrej, You are welcome. Now, the "feature-ipc" branch had been merge into the master branch with the merge patch mentioned below. So all the patches in "feature-ipc" branch had been merge into master too. You can find the related IPC patch in the log history of master branch. The IPC can works rightly in GCC and ARMCLANG on master branch. Thanks, Edison -----Original Message----- From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Tuesday, March 19, 2019 4:10 PM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Thanks Adison, Yes, we are using the master branch. When are you planning to merge the mentioned fix to the mainline? Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Tuesday, March 19, 2019 9:00 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] IPC and clang Hi Andrej, I think you mention the "Merge remote-tracking branch 'feature-ipc' into 'master" patch: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…p;reserved=0. This is a merge patch to fix the merge conflicts. The original patch to support to change the linker file is here: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…p;reserved=0. You can see both the linker files for GCC and ARMCLANG are changed. IPC had been developed and tested on both the GCC and ARMLANG already. Thanks for your question. Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, March 19, 2019 3:35 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] IPC and clang Hello, I have noticed, that with adding the IPC feature to master branch, it were updated GCC linker files (#ifdef TFM_PSA_API sections), but ARMCLANG linker files are without any change. Does it mean that IPC was developed and tested only using GCC? Is there a plan to updated the armclang linker files? Thanks, Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 7 months

1
0
0 0

Re: [TF-M] Replace custom code generating scripts with Jinja2

by Ken Liu (Arm Technology China)

Hi, I saw there is no concern raised about applying Jinja2 into TF-M project, and some code review is done on these patches. Plan to merge it at end of Mar 19th, if you have something please just shout 😉 https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/507/ https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/509/ Thanks -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu > (Arm Technology China) via TF-M > Sent: Wednesday, January 23, 2019 2:18 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [Tf-m] Replace custom code generating scripts with Jinja2 > > Hi Mate, > I have checked your change and the document, it looks quite easy to support > conditional including. > I am OK for this tool. > > Thanks. > > -Ken > > From: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > Sent: Monday, January 21, 2019 9:35 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: Replace custom code generating scripts with Jinja2 > > > Hi Mate, > > Thanks for the proposal. It looks nice. > > I have read the "Improvements over the current solution" part and I think the > "More advanced functionality" is the point I am interested in. There are some > necessary jobs to be done in the code generating scripts for IPC; hope using this > tool could help on that. One thing we are investigating is: > > * We need to put PSA RoT and APP RoT into different groups in linker script; > current tool just put all partitions together and ignores partition type. > > > > Can you help to check if the new tool could make this change easier? > > > > Thanks. > > > -Ken > > ________________________________ > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m- > bounces(a)lists.trustedfirmware.org>> on behalf of Mate Toth-Pal via TF-M <tf- > m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> > Sent: Monday, January 21, 2019 8:37:58 PM > To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> > Cc: nd > Subject: [Tf-m] Replace custom code generating scripts with Jinja2 > > Hi All, > > Based on the design proposal published here: > https://developer.trustedfirmware.org/w/tf_m/design/code_generation_with_j > inja2/ I am planning to replace the code generation tool currently used in the TF- > M with the Jinja2 template engine. > > I already prepared the change that implements this. It is available for review and > testing in this gerrit review: https://review.trustedfirmware.org/#/c/trusted- > firmware-m/+/507/ > > Please note, that this introduces a new tool dependency: jinja2 v2.10 python > library have to be installed to generate code from the partition manifests. Earlier > than 2.10 versions won't work, as one of the templates relies on the namespace > feature introduced in this version. > > Based on this change I also would like to make the secure sct files automatically > generated (just like the secure ld files). The gerrit review for this change is here: > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/509/ > > Should you have any questions, suggestions, objections, please do not hesitate > to contact! > > Thanks, > Mate > -- > 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

6 years, 7 months

1
0
0 0

Re: [TF-M] IPC and clang

by Andrej Butok

Hi Edison, OK. So, according to https://review.trustedfirmware.org/c/trusted-firmware-m/+/463/ the armclang IPC was added only to one platform (target/mps2/an521/armclang/mps2_an521_s.sct). What about Musca A and Musca B? Thanks, Andrej -----Original Message----- From: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Sent: Tuesday, March 19, 2019 9:52 AM To: Andrej Butok <andrey.butok(a)nxp.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Hi Andrej, You can see the log history of master branch: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust…p;reserved=0. All the IPC patches had been existed in master branch. You can use the master branch now, all the IPC functions had been ready for GCC and ARMCLANG. Thanks, Edison -----Original Message----- From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Tuesday, March 19, 2019 4:43 PM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Hi Edison, https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust… master head the latest commit is still 4-day old (4 days Core: Retrieve extra parameter from correct positionHEADmaster Summer Qin). Should I wait some time till it will be propagated to the public git? Thanks, Andrej -----Original Message----- From: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Sent: Tuesday, March 19, 2019 9:26 AM To: Andrej Butok <andrey.butok(a)nxp.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Hi Andrej, You are welcome. Now, the "feature-ipc" branch had been merge into the master branch with the merge patch mentioned below. So all the patches in "feature-ipc" branch had been merge into master too. You can find the related IPC patch in the log history of master branch. The IPC can works rightly in GCC and ARMCLANG on master branch. Thanks, Edison -----Original Message----- From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Tuesday, March 19, 2019 4:10 PM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Thanks Adison, Yes, we are using the master branch. When are you planning to merge the mentioned fix to the mainline? Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Tuesday, March 19, 2019 9:00 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] IPC and clang Hi Andrej, I think you mention the "Merge remote-tracking branch 'feature-ipc' into 'master" patch: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…p;reserved=0. This is a merge patch to fix the merge conflicts. The original patch to support to change the linker file is here: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…p;reserved=0. You can see both the linker files for GCC and ARMCLANG are changed. IPC had been developed and tested on both the GCC and ARMLANG already. Thanks for your question. Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, March 19, 2019 3:35 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] IPC and clang Hello, I have noticed, that with adding the IPC feature to master branch, it were updated GCC linker files (#ifdef TFM_PSA_API sections), but ARMCLANG linker files are without any change. Does it mean that IPC was developed and tested only using GCC? Is there a plan to updated the armclang linker files? Thanks, Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 7 months

1
0
0 0

Re: [TF-M] IPC and clang

by Edison Ai (Arm Technology China)

Hi Andrej, I think you mention the "Merge remote-tracking branch 'feature-ipc' into 'master" patch: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/677/-1..2. This is a merge patch to fix the merge conflicts. The original patch to support to change the linker file is here: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/463/. You can see both the linker files for GCC and ARMCLANG are changed. IPC had been developed and tested on both the GCC and ARMLANG already. Thanks for your question. Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, March 19, 2019 3:35 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] IPC and clang Hello, I have noticed, that with adding the IPC feature to master branch, it were updated GCC linker files (#ifdef TFM_PSA_API sections), but ARMCLANG linker files are without any change. Does it mean that IPC was developed and tested only using GCC? Is there a plan to updated the armclang linker files? Thanks, Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 7 months

1
0
0 0

IPC and clang

by Andrej Butok

Hello, I have noticed, that with adding the IPC feature to master branch, it were updated GCC linker files (#ifdef TFM_PSA_API sections), but ARMCLANG linker files are without any change. Does it mean that IPC was developed and tested only using GCC? Is there a plan to updated the armclang linker files? Thanks, Andrej Butok

6 years, 7 months

1
0
0 0

[RFC] IPC scheduler on AN519

by Ken Liu (Arm Technology China)

Hi, A patch is submitted to support IPC scheduler on AN519; which makes IPC work for baseline: https://review.trustedfirmware.org/c/trusted-firmware-m/+/715 Please help to take a review on it. Thanks ; ) -Ken

6 years, 7 months

1
0
0 0

Re: [TF-M] [RFC] twin cpu bootloader design document

by David Brown

On Thu, Mar 14, 2019 at 06:51:04PM +0000, Christopher Brand via TF-M wrote: >I've posted a design document for bootloader changes to support twin >cpu at >https://developer.trustedfirmware.org/w/tf_m/design/twin-cpu/bootloader/ There are efforts underway to get the TF-M changes to the bootloader contributed back to the upstream MCUboot project. We should be trying to make sure that we continue this effort, as well as to make sure that any efforts to extend the bootloader are done upstream, and not in the TF-M-specific branch. Are you expecting to be running the non-secure CPU before the secure CPU has finished verifying the images? David

6 years, 7 months

2
3
0 0

Fix for issue T276 has been merged

by Ken Liu (Arm Technology China)

Hi, Fix for the issue 'stacking issue in psa_call when FP was enabled' has been merged: https://review.trustedfirmware.org/c/trusted-firmware-m/+/713/ And the issue: https://developer.trustedfirmware.org/T276 This commit fixes the problem while hardware FP is enabled, 5th parameter fetching problem for psa_call(). Please check the latest master branch to get the fix. Thanks. -Ken

6 years, 7 months

1
0
0 0

[RFC] twin cpu bootloader design document

by Christopher Brand

Hi, I've posted a design document for bootloader changes to support twin cpu at https://developer.trustedfirmware.org/w/tf_m/design/twin-cpu/bootloader/ Comments appreciated! Thanks, Chris 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.

6 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M