Hi,
I don’t believe this is the right approach.
TF-M currently includes a non-secure side application (integration test) which is built together with the secure side. This is also reflected in “flash_layout.h” and “region_defs.h” which mixes defines for the secure and non-secure side.
While this might be convenient within TF-M current build setup for the platforms that are supported, it causes issues in real applications and when trying to make this scalable across a large number of platforms. We have seen those issues already while working on providing TF-M as a CMSIS-Pack.
There should be a clean separation of files between the secure and non-secure side.
The mentioned header files should not be imposed to the non-secure side.
Typically non-secure software will have a device specific linker script which will only need to know limited information from the memory layout (non-secure code and data location). Also the secure side might be prebuilt and the non-secure side developed and built separately.
One possible solution is to use a CMSIS-Zone to partition the memory layout on a global level and then splitting it to sub-systems for secure and non-secure and exporting only relevant information for each side. This approach will be used also with TF-M CMSIS-Pack which should be available soon.
Best regards,
Robert
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Devaraj Ranganna via TF-M
Sent: Friday 31 January 2020 17:09
To: TF-M(a)lists.trustedfirmware.org
Subject: [TF-M] Exporting flash_layout.h and region_defs.h
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.
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.
Hi,
Why the title is ‘linker issue’ since it is discussing about the printf things?
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Devaraj Ranganna via TF-M
Sent: Friday, January 31, 2020 9:57 PM
To: TF-M(a)lists.trustedfirmware.org
Subject: [TF-M] TF-M NS regression tests - linker issue
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.
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.
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.
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.
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.
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
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>
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.
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.
