January 2020 - TF-M - lists.trustedfirmware.org

Re: [TF-M] Stuck in tfm_nspm_thread_entry() after "Initialize IPC SPM in handler mode"

by Andrej Butok

Hi Ken, Yes, we are using L2. I have just switched to the latest commit which includes the suggested fix. But tfm_nspm_thread_entry() still goes to the MemManage_Handler() fault a bit later on "push {r0, r1} \n" Thanks, Andrej From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Tuesday, January 21, 2020 6:05 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Stuck in tfm_nspm_thread_entry() after "Initialize IPC SPM in handler mode" Hi Andrej, I guess you are using the level2 configuration. This fault was caused by tfm_nspm_thread_entry is trying to call a function in the privileged area. This commit 'cba90782908626f955fe361f803558181a85c6fc' fixes this problem. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, January 21, 2020 12:14 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Stuck in tfm_nspm_thread_entry() after "Initialize IPC SPM in handler mode" Hello, Just want to check if this is a known issue. During synchronization to the latest TFM, TFM applications are stuck in the exception handler tfm_nspm_thread_entry ()=>MemManage_Handler(). This issue has been caused by commits (3.1.2020): 1. Revision: 5248af2d7b86775364a0e131eb80ac0330bc81fb Message: Core: Use naked function for ns jumping 1. Revision: 490281df3736b11b62e25bc98d3e2c6e4e10478c Message: Core: Initialize IPC SPM in handler mode The previous commit is fully OK (committed 2.1.2020): Revision: 93dabfd3a35faf9ed88285e09997491e93cefa5c Message: Core: Trigger a system reset for programmer error The commits do not have any changes in the linker files and no changes in target files, only the common and ARMv8 code. It's good to know if this is something known or met before. Thank you, Andrej

4 years, 2 months

2
2
0 0

Re: [TF-M] Compilation failure

by Jamie Fox

Hi Chris, Approved and merged, based on the two +1 reviews. Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: 31 January 2020 17:11 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Compilation failure https://review.trustedfirmware.org/c/trusted-firmware-m/+/3243 fixes a compilation error for the armclang build of the PSoc64 platform. The error was introduced by commit e3c75a4955e665e78d55b22f07db73d31a6bf101 (https://review.trustedfirmware.org/c/trusted-firmware-m/+/3031/10 ) which was merged 21st January. It would be really nice to have this breakage last less than two weeks, so is there somebody around who can approve it? 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.

4 years, 2 months

2
1
0 0

Compilation failure

by Christopher Brand

https://review.trustedfirmware.org/c/trusted-firmware-m/+/3243 fixes a compilation error for the armclang build of the PSoc64 platform. The error was introduced by commit e3c75a4955e665e78d55b22f07db73d31a6bf101 (https://review.trustedfirmware.org/c/trusted-firmware-m/+/3031/10 ) which was merged 21st January. It would be really nice to have this breakage last less than two weeks, so is there somebody around who can approve it? 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.

4 years, 2 months

1
0
0 0

Exporting flash_layout.h and region_defs.h

by Devaraj Ranganna

Hi, The headers `flash_layout.h` and `region_defs.h` as the name suggests defines layout of flash and how different regions are organised in flash and ram respectively. These headers define the location of Bootloader if any, secure and non-secure firmware in flash and these defines are used in the linker scripts. As far as I can tell, these headers will be used by NS RTOS without any modifications, I can confirm that, this is the case in Mbed OS. Since these headers are usually imported into NS RTOS without any modifications, I propose that we export these headers as part of the build. Thanks, Dev 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.

4 years, 2 months

1
0
0 0

TF-M NS regression tests - linker issue

by Devaraj Ranganna

Hi, The TF-M NS regression tests were portable enough to run in a rich OS environment. After replacing printf with tfm_log_printf, the TF-M regression tests are now no longer portable enough to run in an OS environment. Many OSes already have a way to print, usually via a printf function, and the TF-M regression tests probably should use this. It's important that TF-M regression tests remain portable and capable of running in an OS environment so that system integrators can be confident that TF-M is working as intended post-integration. I’ve already created a ticket for this https://developer.trustedfirmware.org/T664 Response from Ken in the ticket: Hi Jamie, The background for this changing is, the ARMCLANG printf involves \_\_stdout' into the image and this conflicts with some CMSIS functionalities. (CMSIS team reported that __stdout would affect the mutex init in ARMCLANG). That is the reason why I skipped the default printf. I think for an RTOS, the toolchain provided printf sometimes come with unknown symbols and causes unexpected behaviour, as the discussion in list/channel, most people are trying to avoid toolchain printf and use some lightweight output. And for the test, it should use wrapped TEST_LOG(), instead of calling printf itself, since some RTOS do not provide a std 'printf' function. Is there any discussion thread about this issue? Thanks Thanks, Dev 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.

4 years, 2 months

1
0
0 0

TF-M Technical Forum call - February 6

by Anton Komlev

Dear All, The next Technical Forum is planned on Thursday, February 6 at 7:00-8:00 UTC. Please reply on this email with your proposals for agenda topics. Any questions, proposals, concerns are all valid points for our open discussion so do not hesitate to share it. A big or complicated topics are worth to preliminary discussion over the mailing list. Best regards, Anton Komlev

4 years, 2 months

1
1
0 0

AN521 debugging

by Thomas Törnblom

As the IAR ports for Musca A and psoc64 are more or less complete, I've started looking at the MPS2/MPS3 targets. After some initial issues I can now connect our debugger via USB using CMSIS-DAP. However I'm not getting and serial ports configured on my Win10 laptop when connecting to an MPS2+ board running the AN521 (M33) image. Shouldn't that show up automatically like it does with the MPS3? Or do I need to use the physical serial port on the board? I would appreciate reviews of the IAR port as well, see https://review.trustedfirmware.org/c/trusted-firmware-m/+/3295 Thanks, Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

4 years, 2 months

1
1
0 0

Re: [TF-M] [Request For Comments] Expose the NV counters under platform service.

by Jamie Fox

It would simplify things now we have the ITS APIs implemented. The downside is that platforms without the ITS APIs (i.e. those with some on-chip OTP but no on-chip MTP flash) would need to roll their own solution for storing the monotonic counter values in OTP. Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Adrian Shaw via TF-M Sent: 24 January 2020 10:07 To: Tamas Ban <Tamas.Ban(a)arm.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] [Request For Comments] Expose the NV counters under platform service. Yes. Wouldn’t that simplify things? Adrian On 24 Jan 2020, at 09:08, Tamas Ban via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: Do you mean to use the ITS API to read/write a monotonous counter in trusted flash? Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Adrian Shaw via TF-M Sent: 23 January 2020 13:10 To: Raef Coles <Raef.Coles(a)arm.com<mailto:Raef.Coles@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; Adrian Shaw via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: Re: [TF-M] [Request For Comments] Expose the NV counters under platform service. Do you mean the transfer of the Protected Storage service? If that is the case, then you don’t need an NV counter API because you can use the ITS API. Adrian On 23 Jan 2020, at 08:19, Raef Coles via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: I believe the reason this is being proposed is the transferal of secure storage (as opposed to protected storage) to an application root of trust partition. Such a partition would still require access to the NV counters, at least as far as I know. We ran into this issue while creating the patch to do the transferal, and Jamie suggested this was the most sensible fix. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Adrian Shaw via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: 22 January 2020 18:38 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Minos Galanakis Cc: nd Subject: Re: [TF-M] [Request For Comments] Expose the NV counters under platform service. Hi Minos, What are the use cases for Application Root of Trust services that need NV counters? The NV counters are used by the PSA Root of Trust for rollback protection of images and secure storage. There are usually very few available. Hence the question above. Adrian ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Minos Galanakis via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: 22 January 2020 17:28 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] [Request For Comments] Expose the NV counters under platform service. Hi, The Non-Volatile (NV) counters are a part of the PSA Root of Trust. In order to enable Applications residing in the Root of Trust partition to use the counters, an appropriate interface is needed. This proposal is to enhance the existing platform service, in order to expose a generic API aimed at providing access to Non-Volatile counters to applications residing in the Application Root of Trust. This implementation will not modify or affect the existing tfm_plat_nv_counters API or its’ platform specific implementation and will instead introduce a shim layer between a psa_call and the existing logic. All input, question or comments are greatly appreciated. Minos 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. 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<mailto:TF-M@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. 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<mailto:TF-M@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.

4 years, 2 months

2
1
0 0

App: Changes to OS wrapper

by Vikas Katariya

Hi all, I am proposing new changes to OS wrapper layer to help other RTOS use dynamic memory allocation. OS wrapper layers help to create Mutex, Semaphores, and Thread on RTOS. The wrapper is designed to use static allocation of memory/objects from predefined OS memory pool, which is not fully featured enough to allow dynamic memory allocation and freeing them after completion, if an RTOS requires that kind of implementation. For example, the child thread created in ns_test_helpers.c does a simple exit without passing a handle if the memory was dynamically allocated, which is a memory leak scenario. Therefore os_wrapper_thread_suspend() and os_wrapper_thread_delete() are introduced to aid scenarios where dynamic memory allocation and freeing is required. In the current patch we just suspend the child thread and terminate it from parent thread. The patch is open for review here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3294 Thanks & Best Regards, Vikas Katariya 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.

4 years, 2 months

1
0
0 0

Disabling SHA-1 in TF-M Crypto

by Jamie Fox

Hi all, I am proposing we disable SHA-1 by default in the TF-M Crypto service, by turning off the option in the default Mbed Crypto config in platform/ext/common/tfm_mbedcrypto_config.h. SHA-1 is not considered a strong message digest, so we should not encourage its use. Disabling it also has the benefit of reducing the code size of a default TF-M build by 4.5KB. It would still be possible to re-enable SHA-1 by providing a platform-specific Mbed Crypto config, but we would no longer test it or recommend it be enabled. The patch is open for review here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3289 Kind regards, Jamie

4 years, 2 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

TF-M January 2020