- TF-M - lists.trustedfirmware.org

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, 10 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, 10 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, 10 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, 10 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, 10 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, 10 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, 10 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, 10 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, 10 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, 10 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, 10 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, 10 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, 10 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, 10 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, 10 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, 10 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, 10 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M