- TF-M - lists.trustedfirmware.org

by Vikas Katariya

Hi all, Thanks for the e-mail. I would like to highlight a few issues with the current API implementation. * It isn't good for OS which relies on manual memory management, the current API doesn't give an opportunity to free any resources which were in use. * The os-wrapper handle must be different from the actual underlying OS handle on a manually-memory-managed system in order to allow the resources to be freed which are not managed by the OS. So a change in the API implementation is required to address the above issues. * Use `os_wrapper_current_thread_suspend()` and `os_wrapper_thread_terminate(handle)` API, ensuring we suspend and terminate safely, enabling it to free allocated resources. * Remove `os_wrapper_get_handle()` to make sure we differentiate between OS wrapper handle and OS handle. The os-wrapper knows more about the resources being managed than the OS itself. It is supposed to return an OS Wrapper handle than OS handle because implementations can't always create an OS-wrapper handle from an OS handle. Comments towards the arguments: * If we go with `os_wrapper_thread_exit()` to exit a child, then OS can allocate that resource to another purpose instantly and if we were to pass that handle to `os_wrapper_thread_delete(handle)`, we still risk corruption. * If we go with `os_wrapper_thread_exit()` suspending the thread Or `os_wrapper_thread_delete(handle)` performing a NOP, it changes the semantics of what API intends to do and is not a natural way of moving forward. Also, it may confuse developers by making exit suspend instead of exit, or delete not delete anything. * If we go with `os_wrapper_thread_exit()` performing a NOP and `os_wrapper_thread_delete(handle)` performing a termination of the thread, there are few things to consider here: * It changes the semantics again for exit, but on some OS if the thread has finished its operations it will either exit or suspend itself as there is nothing to execute further. * If the thread exits then os_wrapper_thread_delete(handle) will result in error. * If we add a wrapper variable that captures info on if the thread has been exited to check deletion is safe or not, there few things to consider here: * Adds an additional maintainability burden. * Tracking if a thread has been exited or not adds a cost in RAM that would not be needed if the API had a good shape. Seeing as we all develop for embedded devices here, we should be very careful with RAM use. * It can't figure out its identification because the OS-wrapper handle is not passed in `os_wrapper_thread_exit()`. Differentiating between the right handle is required to ensure we track the right thread information. Depreciating the old API will ensure the following: * Future applications are portable to any OS that needs manual memory management. * It forces out-of-tree applications using the wrappers to know they need to make a change in order to be portable to operating systems that require manual memory management. * The in-tree applications will be refactored as part of this API change. Further, if there is a matter of handling deprecation of API, then I would like to know how that can be achieved in TF-M? Thanks & Best Regards, Vikas Katariya From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Thursday, February 6, 2020 12:16 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Changes to OS wrapper Hello, Agree with Jamie seeing not enough arguments for extension of existing API. Looks like the required functionality can be hidden inside a specific os_wrapper, which is a main purpose of it. @Vikas, could you explain a bit differently why you are blocked with the current API? Cheers, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: 06 February 2020 09:10 To: Vikas Katariya <Vikas.Katariya(a)arm.com<mailto:Vikas.Katariya@arm.com>>; Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Changes to OS wrapper Hi, >From the architecture point of view, when an "owner" (sw entity) defines an API, the best is to do that based on it's own needs. This gives the most flexibility and makes the API best withstand future challenges. Sometimes this is not possible. An example for this is the TRIM functionality of SSD storage, where the file-system must give extra information to the storage. In this case the extension of the API is driven by the implementation and thus implementation details. This is risky as different implementations may have conflicting needs, and sometimes the API cannot fulfill both. If your case, a possible solution is to implement the os_theread_delete() and an empty function. If that is not possible, then a wrapper can be added where a variable captures info on if the thread has been exited, and thus if deletion is safe or not. If it is, then os_thread_delete() can exit without doing anything. The call sequence of suspend and the delete is specific to the OS you are using or to the way you use it. Do you think does here a strong reason exist to go for an API extension driven by the implementation? I don't have all details, but as far as I understand the specific cases you described I don't see an imminent need for the API change. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vikas Katariya via TF-M Sent: 06 February 2020 08:47 To: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Changes to OS wrapper Hi Jamie, Thanks for getting back. It's because of os_wrapper_thread_exit() is used to exit the child thread in the SST test, which means the handle is no longer valid for os_wrapper_thread_delete() to operate on, resulting in an error. The ideal way to do this properly is to use os_wrapper_thread_suspend() and then os_wrapper_thread_delete() from the parent thread. Thanks & Best Regards, Vikas Katariya From: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>> Sent: Wednesday, February 5, 2020 17:16 To: Vikas Katariya <Vikas.Katariya(a)arm.com<mailto:Vikas.Katariya@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: Changes to OS wrapper Hi Vikas, I still do not really understand the rationale for these changes. If dynamic memory allocation inside the os_wrapper shim is really what you want to do, then what is stopping you from implementing the following? os_wrapper_thread_new() { malloc(external_to_os_resource) /* create thread */ } os_wrapper_thread_delete() { free(external_to_os_resource) } Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vikas Katariya via TF-M Sent: 05 February 2020 10:20 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Changes to OS wrapper Hi all, The patch set has been updated with further changes: * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3294 OS wrapper layers help to create Mutex, Semaphores, and Thread on an OS. The wrapper was designed to be implemented on platforms that dynamically allocate memory or objects from a predefined OS memory pool. The current shape of the OS wrapper is not a good fit for work with operating systems that require manual memory management. For example, if the child thread created in ns_test_helpers.c does a simple os_wrapper_thread_exit(), this does not give any opportunity for manually-managed thread resources to be freed; this leads to a memory leak. Therefore os_wrapper_current_thread_suspend() and os_wrapper_thread_delete() are introduced to aid scenarios where manual memory management is required. The removal of os_wrapper_thread_exit() is warranted as it encourages applications to avoid memory leak scenarios by requiring applications to remember to call os_wrapper_thread_terminate(). If we were to keep os_wrapper_thread_exit() around, this would impose undue cognitive overhead on wrapper users by making os_wrapper_thread_exit() do something other than exit the current thread (on platforms requiring manual memory management); an os_wrapper_thread_exit() implementation could not actually exit a thread on a manual memory managed OS, as the thread must remain valid until clean up time, and exiting the thread would invalidate the OS's thread resource. * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3299 These changes reflect to avoid memory leaks on operating systems that use manually managed dynamic memory allocation but not from static memory/objects pools, allowing them to free after usage. Remove "get_handle" because it's not possible to implement it efficiently on systems that require manual memory management. The os-wrapper handle must be different from the actual underlying OS handle on a manually-memory-managed system in order to allow the resources be freed which are not managed by the OS. For example: struct { os_handle; external_to_os_resource; }; The os-wrapper knows more about the resources being managed than the OS itself. It is supposed to return an OS Wrapper handle than OS handle, because implementations can't always create an os-wrapper handle from an OS handle. In this case the os-wrapper handle could be a pointer to this struct, but could not be just the os_handle directly. Further os_wrapper_current_thread_get_priority() is used to avoid confusion between the top and bottom layer handles, because the older implementation can refer to different object types when operating across multiple layers. * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3347 - Improves test efficiency. Please review and share your thoughts. Thanks & Best Regards, Vikas Katariya From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vikas Katariya via TF-M Sent: Monday, January 27, 2020 15:52 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] App: Changes to OS wrapper 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. 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.

6 years, 1 month

2
1
0 0

Linking issues with SFN section

by Thomas Törnblom

I would like to discuss the use of the SFN section for the secure image. During my port of tf-m to the IAR toolchain I ran into issues related to the SFN section. There are quite a few functions that are placed in the SFN section, which is then linked into the TFM_UNPRIV_CODE block. I don't know how armclang or gcc handles this, but the IAR compiler may generate .rodata initializers, which does not end up in the SFN section, predominantly the in_vec and out_vec structs with debug builds. I've had to manually add the .rodata sections from these object files (tfm_*_secure_api.o) to the TFM_UNPRIV_CODE in the tfm_common linker script in order to work around MemManage_Handler traps. I would like to suggest that the relevant files are added to the relevant block in the tfm_common.* linker script instead of using the SFN section. That way one can specify that both the .text (ro code) and .rodata (const) goes into the same block. Comments? 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>

6 years, 1 month

1
0
0 0

Re: [TF-M] PsoC64 build broken

by Christopher Brand

So the patch does the wrong thing anyway - it effectively changes the watermark assertion so that it won't trigger if the TFM_RAM_CODE area goes beyond the end of RAM. That's just broken, because TFM_RAM_CODE is, obviously, supposed to be in RAM. There may well be a problem here, but this is not the correct fix for it. Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: Thursday, February 6, 2020 3:58 PM To: Jamie Fox <Jamie.Fox(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: Gabor Abonyi <Gabor.Abonyi(a)arm.com>; nd <nd(a)arm.com> Subject: Re: [TF-M] PsoC64 build broken CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. I did an armclang build of the head of master and with this patch reverted, and there is a small difference between them - the TFM_RAM_CODE and SRAM_WATERMARK sections are swapped. That feels wrong, because the TFM_RAM_CODE is inside SRAM, so I'd expect the "end of SRAM watermark" to be after it, not before it. I'm not sure exactly how the watermark section is used, though. On the plus side, TFM_RAM_CODE does indeed still end up at the correct address, in SRAM. I'm not sure exactly which sections you want me to try changing to set the LMA. The line numbers don't seem to match up... Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Christopher Brand via TF-M Sent: Thursday, February 6, 2020 3:43 PM To: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: Gabor Abonyi <Gabor.Abonyi(a)arm.com<mailto:Gabor.Abonyi@arm.com>>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] PsoC64 build broken CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. I'd really prefer to see the patch reverted first, and then we can figure out exactly what's going on and push a revised patch that achieves the objectives without breaking anything. It does seem to have some side-effects on the PSoC64 armclang build, too. It's pretty standard open source process to revert a patch that breaks something like this... Chris From: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>> Sent: Thursday, February 6, 2020 3:15 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>> Cc: Gabor Abonyi <Gabor.Abonyi(a)arm.com<mailto:Gabor.Abonyi@arm.com>>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: PsoC64 build broken Hi Chris, Sorry about that. It shouldn't have changed the address of the region though because it's explicitly set to S_RAM_CODE_START. I think this could be down to an "interesting" behaviour in GCC linker scripts where if the LMA is explicitly set with for a region with "AT>", then it won't revert back to being equal to the VMA for the next region in some cases. So before we revert the change, please can you try setting the LMA explicitly for the following region(s)? That is, try "> FLASH AT> FLASH" instead of just "> FLASH" on lines 527 and 563. Best wishes, Jamie ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: 06 February 2020 20:11 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: Gabor Abonyi <Gabor.Abonyi(a)arm.com<mailto:Gabor.Abonyi@arm.com>> Subject: [TF-M] PsoC64 build broken Hi, Commit 52182bc5e006752a4d28c3ccd909f93dafee0cf5 ("Build: Fix SRAM sanity check in common scatter file") seems to break the PSoc64 build. This is from https://review.trustedfirmware.org/c/trusted-firmware-m/+/3333 Building with gcc, I get: /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/build_gcc_psoc64/secure_fw/tfm_s.ld.i:352 cannot move location counter backwards (from 000000000802f578 to 0000000008000000) collect2: error: ld returned 1 exit status secure_fw/CMakeFiles/tfm_s.dir/build.make:210: recipe for target 'unit_test/tfm_s.axf' failed I'm quite surprised that the comments on the review note that "I noticed that this define is currently only used for PSOC6 platform which I don't possess" and yet apparently a Musca B1-only build was considered sufficient to merge it. I haven't dug into the details, but superficially it seems to move the .ramfunc code to before S_DATA_START, which means that it will no longer be in secure RAM. Can we please revert this patch for now? 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. 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. 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. This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

6 years, 1 month

3
2
0 0

Re: [TF-M] PsoC64 build broken

by Christopher Brand

I did an armclang build of the head of master and with this patch reverted, and there is a small difference between them - the TFM_RAM_CODE and SRAM_WATERMARK sections are swapped. That feels wrong, because the TFM_RAM_CODE is inside SRAM, so I'd expect the "end of SRAM watermark" to be after it, not before it. I'm not sure exactly how the watermark section is used, though. On the plus side, TFM_RAM_CODE does indeed still end up at the correct address, in SRAM. I'm not sure exactly which sections you want me to try changing to set the LMA. The line numbers don't seem to match up... Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: Thursday, February 6, 2020 3:43 PM To: Jamie Fox <Jamie.Fox(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: Gabor Abonyi <Gabor.Abonyi(a)arm.com>; nd <nd(a)arm.com> Subject: Re: [TF-M] PsoC64 build broken CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. I'd really prefer to see the patch reverted first, and then we can figure out exactly what's going on and push a revised patch that achieves the objectives without breaking anything. It does seem to have some side-effects on the PSoC64 armclang build, too. It's pretty standard open source process to revert a patch that breaks something like this... Chris From: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>> Sent: Thursday, February 6, 2020 3:15 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>> Cc: Gabor Abonyi <Gabor.Abonyi(a)arm.com<mailto:Gabor.Abonyi@arm.com>>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: PsoC64 build broken Hi Chris, Sorry about that. It shouldn't have changed the address of the region though because it's explicitly set to S_RAM_CODE_START. I think this could be down to an "interesting" behaviour in GCC linker scripts where if the LMA is explicitly set with for a region with "AT>", then it won't revert back to being equal to the VMA for the next region in some cases. So before we revert the change, please can you try setting the LMA explicitly for the following region(s)? That is, try "> FLASH AT> FLASH" instead of just "> FLASH" on lines 527 and 563. Best wishes, Jamie ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: 06 February 2020 20:11 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: Gabor Abonyi <Gabor.Abonyi(a)arm.com<mailto:Gabor.Abonyi@arm.com>> Subject: [TF-M] PsoC64 build broken Hi, Commit 52182bc5e006752a4d28c3ccd909f93dafee0cf5 ("Build: Fix SRAM sanity check in common scatter file") seems to break the PSoc64 build. This is from https://review.trustedfirmware.org/c/trusted-firmware-m/+/3333 Building with gcc, I get: /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/build_gcc_psoc64/secure_fw/tfm_s.ld.i:352 cannot move location counter backwards (from 000000000802f578 to 0000000008000000) collect2: error: ld returned 1 exit status secure_fw/CMakeFiles/tfm_s.dir/build.make:210: recipe for target 'unit_test/tfm_s.axf' failed I'm quite surprised that the comments on the review note that "I noticed that this define is currently only used for PSOC6 platform which I don't possess" and yet apparently a Musca B1-only build was considered sufficient to merge it. I haven't dug into the details, but superficially it seems to move the .ramfunc code to before S_DATA_START, which means that it will no longer be in secure RAM. Can we please revert this patch for now? 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. 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. This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

6 years, 1 month

1
0
0 0

Re: [TF-M] PsoC64 build broken

by Jamie Fox

Hi Chris, Sorry about that. It shouldn't have changed the address of the region though because it's explicitly set to S_RAM_CODE_START. I think this could be down to an "interesting" behaviour in GCC linker scripts where if the LMA is explicitly set with for a region with "AT>", then it won't revert back to being equal to the VMA for the next region in some cases. So before we revert the change, please can you try setting the LMA explicitly for the following region(s)? That is, try "> FLASH AT> FLASH" instead of just "> FLASH" on lines 527 and 563. Best wishes, Jamie ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 06 February 2020 20:11 To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: Gabor Abonyi <Gabor.Abonyi(a)arm.com> Subject: [TF-M] PsoC64 build broken Hi, Commit 52182bc5e006752a4d28c3ccd909f93dafee0cf5 (“Build: Fix SRAM sanity check in common scatter file”) seems to break the PSoc64 build. This is from https://review.trustedfirmware.org/c/trusted-firmware-m/+/3333 Building with gcc, I get: /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/build_gcc_psoc64/secure_fw/tfm_s.ld.i:352 cannot move location counter backwards (from 000000000802f578 to 0000000008000000) collect2: error: ld returned 1 exit status secure_fw/CMakeFiles/tfm_s.dir/build.make:210: recipe for target 'unit_test/tfm_s.axf' failed I’m quite surprised that the comments on the review note that “I noticed that this define is currently only used for PSOC6 platform which I don't possess” and yet apparently a Musca B1-only build was considered sufficient to merge it. I haven’t dug into the details, but superficially it seems to move the .ramfunc code to before S_DATA_START, which means that it will no longer be in secure RAM. Can we please revert this patch for now? Chris This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

6 years, 1 month

2
1
0 0

PsoC64 build broken

by Christopher Brand

Hi, Commit 52182bc5e006752a4d28c3ccd909f93dafee0cf5 ("Build: Fix SRAM sanity check in common scatter file") seems to break the PSoc64 build. This is from https://review.trustedfirmware.org/c/trusted-firmware-m/+/3333 Building with gcc, I get: /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/build_gcc_psoc64/secure_fw/tfm_s.ld.i:352 cannot move location counter backwards (from 000000000802f578 to 0000000008000000) collect2: error: ld returned 1 exit status secure_fw/CMakeFiles/tfm_s.dir/build.make:210: recipe for target 'unit_test/tfm_s.axf' failed I'm quite surprised that the comments on the review note that "I noticed that this define is currently only used for PSOC6 platform which I don't possess" and yet apparently a Musca B1-only build was considered sufficient to merge it. I haven't dug into the details, but superficially it seems to move the .ramfunc code to before S_DATA_START, which means that it will no longer be in secure RAM. Can we please revert this patch for now? Chris This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

6 years, 1 month

1
0
0 0

Re: [TF-M] TF-M NS regression tests - linker issue

by Devaraj Ranganna

Hi Ken, I’d prefer that TF-M keep exporting the pre-compiled archive for regression tests. The rational behind that is less files to be added/maintained by NS RTOS. Considering this, I think quick and easy way to solve this is for NS RTOS to implement ` tfm_log_printf ` using the print method available. This way no changes are needed in TF-M. I thought about platform-specific shim layer, like adding a new print function “ns_log_printf” to the OS wrapper (app/os_wrapper_cmsis_rtos_v2.c) and use that for NS regression tests. I believe it’s not worth the effort and also it will add another layer of indirection. To summarise, we’ll implement `tfm_log_printf ` in Mbed OS which should resolve the linker issue. Thanks, Dev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Ken Liu via TF-M <tf-m(a)lists.trustedfirmware.org> Reply to: Ken Liu <Ken.Liu(a)arm.com> Date: Wednesday, 5 February 2020 at 04:50 To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M NS regression tests - linker issue Hi Devaraj, Thanks for the clarification. Looks like this issue is caused by the way the building system integrates the test package with NS RTOS - if source-level integration is applied then the modification is not a problem and this should be the better way - even if we recover the 'printf' implementation, for those RTOS who has no printf, it would be another issue. I think the possible solutions can be: * If we keep using the pre-compiled archive, then some platform-specific shim layer needs to be available to provide platform-specific functions. * If we changed to source-level integration then things would be easier. * A quick way is as you requested, recover back to 'printf'. For the 3rd point, there are some pre-actions to be done: * Make sure the compiler optimization function is limited for easier the implementation of these stdio functions. There is a leading patch for this: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3217 * Define the HAL functions for output so that the printf implementation is not CMSIS specific. May I ask how you fix this issue? /Ken ________________________________ From: Devaraj Ranganna <Devaraj.Ranganna(a)arm.com> Sent: Tuesday, February 4, 2020 11:16 PM To: Ken Liu <Ken.Liu(a)arm.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M NS regression tests - linker issue Hi Ken, Currently, TF-M build process creates an pre-compiled archive of NS tests and exports it. But the implementation of `tfm_log_printf` is not exported. This causes a linker issue when NS tests archive is linked with NS RTOS, which is the reason why subject of this mail contains `linker issue`. Having said that, exporting `tfm_log_printf` won’t solve the problem because `tfm_log_printf` assumes availability of CMSIS driver framework. Also the latest suggestion on the ticket https://developer.trustedfirmware.org/T664 `And I think if you forward the TEST_LOG to your OS printf implementation then everything would be fine?` won’t help because of pre-compiled archive. It looks like only possible solution for NS RTOS is to implement ` tfm_log_printf `. Please do recommend if you have any other ideas. Thanks, Dev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Ken Liu via TF-M <tf-m(a)lists.trustedfirmware.org> Reply to: Ken Liu <Ken.Liu(a)arm.com> Date: Saturday, 1 February 2020 at 04:46 To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M NS regression tests - linker issue 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.

6 years, 1 month

2
1
0 0

Re: [TF-M] PSA Test Suite - Attestation test

by Andrej Butok

Hi Tamas > Could you tell what was the values of these compile time switches in your test? For the previous TFM, we have used INCLUDE_TEST_CODE_AND_KEY_ID. For the current TFM it was renamed to INCLUDE_TEST_CODE. Other parameters are new, so I have tried different combinations of these parameters, but the PSA Test-Suite Attestation is still failed. > Further do you implemented the boot data sharing between bootloader and runtime firmware? It's used the TFM template code without change from tfm\platform\ext\common\template > Do you sign SPE and NPSE images together or they are signed separately? We do not use the secondary bootloader so far, so image is not signed. As the Attestation Regression tests are passed. It's good to know what combination of parameters have to be used to generate the same token as it was generated by the older TFM and accepted by the PSA Test Suite (last commit on master branch). Or the PSA Test Suite is obsolete. Thank you, Andrej From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M Sent: Wednesday, February 5, 2020 1:13 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] PSA Test Suite - Attestation test Hi Andrej, Could you tell what was the values of these compile time switches in your test? I assume you did the test on NXP board. Further do you implemented the boot data sharing between bootloader and runtime firmware? Do you sign SPE and NPSE images together or they are signed separately? Tamas 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: 04 February 2020 17:33 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] PSA Test Suite - Attestation test Hello, After upgrade to the latest version of TFM, the Attestation test from the PSA Test Suite is failed (but the TFM Attestation regression tests are passed). What combination of configuration parameters must be used (INCLUDE_OPTIONAL_CLAIMS, INCLUDE_TEST_CODE, INCLUDE_COSE_KEY_ID, BOOT_DATA_AVAILABLE) to follow PSA Test Suite expectations? What commit of the PSA Test-suite must be used for the latest TFM? We are still on the 2019-07-25 (c80681ed7c7f3e2cbf02ded1ef2464ba2ca7ccd5) commit, which was OK with 2-month old TFM. Is the PSA Test Suite Attestation test valid for the latest TFM? Thank you, Andrej Butok 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, 1 month

2
1
0 0

Re: [TF-M] Changes to OS wrapper

by Anton Komlev

Hello, Agree with Jamie seeing not enough arguments for extension of existing API. Looks like the required functionality can be hidden inside a specific os_wrapper, which is a main purpose of it. @Vikas, could you explain a bit differently why you are blocked with the current API? Cheers, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: 06 February 2020 09:10 To: Vikas Katariya <Vikas.Katariya(a)arm.com>; Jamie Fox <Jamie.Fox(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Changes to OS wrapper Hi, >From the architecture point of view, when an "owner" (sw entity) defines an API, the best is to do that based on it's own needs. This gives the most flexibility and makes the API best withstand future challenges. Sometimes this is not possible. An example for this is the TRIM functionality of SSD storage, where the file-system must give extra information to the storage. In this case the extension of the API is driven by the implementation and thus implementation details. This is risky as different implementations may have conflicting needs, and sometimes the API cannot fulfill both. If your case, a possible solution is to implement the os_theread_delete() and an empty function. If that is not possible, then a wrapper can be added where a variable captures info on if the thread has been exited, and thus if deletion is safe or not. If it is, then os_thread_delete() can exit without doing anything. The call sequence of suspend and the delete is specific to the OS you are using or to the way you use it. Do you think does here a strong reason exist to go for an API extension driven by the implementation? I don't have all details, but as far as I understand the specific cases you described I don't see an imminent need for the API change. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vikas Katariya via TF-M Sent: 06 February 2020 08:47 To: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Changes to OS wrapper Hi Jamie, Thanks for getting back. It's because of os_wrapper_thread_exit() is used to exit the child thread in the SST test, which means the handle is no longer valid for os_wrapper_thread_delete() to operate on, resulting in an error. The ideal way to do this properly is to use os_wrapper_thread_suspend() and then os_wrapper_thread_delete() from the parent thread. Thanks & Best Regards, Vikas Katariya From: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>> Sent: Wednesday, February 5, 2020 17:16 To: Vikas Katariya <Vikas.Katariya(a)arm.com<mailto:Vikas.Katariya@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: Changes to OS wrapper Hi Vikas, I still do not really understand the rationale for these changes. If dynamic memory allocation inside the os_wrapper shim is really what you want to do, then what is stopping you from implementing the following? os_wrapper_thread_new() { malloc(external_to_os_resource) /* create thread */ } os_wrapper_thread_delete() { free(external_to_os_resource) } Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vikas Katariya via TF-M Sent: 05 February 2020 10:20 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Changes to OS wrapper Hi all, The patch set has been updated with further changes: * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3294 OS wrapper layers help to create Mutex, Semaphores, and Thread on an OS. The wrapper was designed to be implemented on platforms that dynamically allocate memory or objects from a predefined OS memory pool. The current shape of the OS wrapper is not a good fit for work with operating systems that require manual memory management. For example, if the child thread created in ns_test_helpers.c does a simple os_wrapper_thread_exit(), this does not give any opportunity for manually-managed thread resources to be freed; this leads to a memory leak. Therefore os_wrapper_current_thread_suspend() and os_wrapper_thread_delete() are introduced to aid scenarios where manual memory management is required. The removal of os_wrapper_thread_exit() is warranted as it encourages applications to avoid memory leak scenarios by requiring applications to remember to call os_wrapper_thread_terminate(). If we were to keep os_wrapper_thread_exit() around, this would impose undue cognitive overhead on wrapper users by making os_wrapper_thread_exit() do something other than exit the current thread (on platforms requiring manual memory management); an os_wrapper_thread_exit() implementation could not actually exit a thread on a manual memory managed OS, as the thread must remain valid until clean up time, and exiting the thread would invalidate the OS's thread resource. * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3299 These changes reflect to avoid memory leaks on operating systems that use manually managed dynamic memory allocation but not from static memory/objects pools, allowing them to free after usage. Remove "get_handle" because it's not possible to implement it efficiently on systems that require manual memory management. The os-wrapper handle must be different from the actual underlying OS handle on a manually-memory-managed system in order to allow the resources be freed which are not managed by the OS. For example: struct { os_handle; external_to_os_resource; }; The os-wrapper knows more about the resources being managed than the OS itself. It is supposed to return an OS Wrapper handle than OS handle, because implementations can't always create an os-wrapper handle from an OS handle. In this case the os-wrapper handle could be a pointer to this struct, but could not be just the os_handle directly. Further os_wrapper_current_thread_get_priority() is used to avoid confusion between the top and bottom layer handles, because the older implementation can refer to different object types when operating across multiple layers. * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3347 - Improves test efficiency. Please review and share your thoughts. Thanks & Best Regards, Vikas Katariya From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vikas Katariya via TF-M Sent: Monday, January 27, 2020 15:52 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] App: Changes to OS wrapper 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. 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.

6 years, 1 month

1
0
0 0

Re: [TF-M] Persistent keys in the Crypto service

by Kevin Townsend

Hi Jamie, This aligns well with a key requirement we identified thinking about late binding devices that make use of TF-M, such as with cloud services or providers which tend to use X.509 certificate chains which will need to be signed, and a private key generated and held in secure storage as part of the binding and certification signing process. Some initial thoughts are visible here in interim if it's useful to see a use case for this work: https://github.com/microbuilder/certificate_chains/blob/master/rfc_tfm.md Best regards, Kevin On Tue, 4 Feb 2020 at 14:32, Jamie Fox via TF-M < tf-m(a)lists.trustedfirmware.org> wrote: > Hi all, > > > > I have pushed for review patches to enable persistent keys in the TF-M > Crypto service. With these changes, persistent keys will be stored by Mbed > Crypto using the ITS APIs exposed by TF-M. > > > > The reviews are here: > > https://review.trustedfirmware.org/c/trusted-firmware-m/+/3252 > (implementation) > > https://review.trustedfirmware.org/c/trusted-firmware-m/+/3253 (tests) > > > > Currently, merging of these patches is blocked as they depend on Mbed > Crypto 2.0 (or greater), which adds support for the latest ITS 1.0.0 APIs > exposed by TF-M. Integrating Mbed Crypto 2.0 with TF-M is a work in > progress. > > > > If anyone wants to test these patches in the meantime, it is possible to > cherry pick the patch in the Mbed Crypto repo that adds support for ITS > 1.0.0. With the Mbed Crypto repo checked-out at the “mbedcrypto-1.1.0” tag, > do a “git cherry-pick bda5a2111” to cherry pick the relevant patch. > > > > Kind regards, > > Jamie > > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m >

6 years, 1 month

1
0
0 0

Re: [TF-M] Possible race condition in IRQ_TEST_SCENARIO_4?

by Mate Toth-Pal

Hi Thomas, A brief description of this test scenario is in docs\user_guides\services\core_test_services_integration_guide.rst: <quote> - S code waits for an interrupt (calling ``psa_wait()``), the handler is in the service that is waiting, ``psa_eoi()`` is called after ``psa_wait()`` returns (``IRQ_TEST_SCENARIO_4``) <end quote> ConfigRegression.cmake is using the library model, so that implementation needs to be considered. In this scenario only a secure interrupt is involved. The sequence is the following (only relevant code parts are mentioned): 1. spm_irq_test_1_prepare_test_scenario_internal() starts the secure timer. 2. spm_irq_test_1_execute_test_scenario() enters a while loop, waiting the signal for the timer to be set call psa_wait(SPM_CORE_IRQ_TEST_1_SIGNAL_TIMER_0_IRQ, PSA_BLOCK); 3. at some point the interrupt is triggered, and the signal is set for the interrupt. The interrupt handler is run, and it sets a flag timer0_triggered. SPM_CORE_IRQ_TEST_1_SIGNAL_TIMER_0_IRQ_isr() is the interrupt handler function in this case, and this function executes an explicit "DSB" instruction to be sure that the write to the flag is committed. (The flag is declared as volatile) 4. When the function spm_irq_test_1_execute_test_scenario() exits the loop, it calls pas_eoi(), and returns. At the moment I don't see a flaw in this scenario, which of course gives no guarantee that there isn't a flaw in it somewhere. We often test TF-M in FVP, and found that from time to time the FVP runs slower (seems to be executing less cycles per minute) than usual. In this cases IRQ testcases appeared to be hanging, although if we waited for the necessary number of cycles to be executed by the FVP, these tests always passed. Did you have a chance to have a look at it with a debugger? If so, where exactly is the execution stucked? Have the interrupt been triggered as expected? Regards, Mate From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Thursday, February 6, 2020 9:56 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Possible race condition in IRQ_TEST_SCENARIO_4? How is the IRQ_TEST_SCENARIO_4 supposed to work? I suspect that there might be a lurking race condition somewhere in that test. Some, not all, of the (M33/M23) targets gets stuck in that test when the ConfigRegression.cmake config is built with IAR in Debug mode. If I build it with RelWithDebInfo then the test runs OK for all applicable targets. No problems with Debug builds for the other configurations. Occasionally the test will run successfully also for a normally problematic target if I run it in the debugger and stop execution at breakpoints, but it is very random, which is why I suspect there might be a race problem. 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>

6 years, 1 month

1
0
0 0

Re: [TF-M] Changes to OS wrapper

by Gyorgy Szing

Hi, >From the architecture point of view, when an "owner" (sw entity) defines an API, the best is to do that based on it's own needs. This gives the most flexibility and makes the API best withstand future challenges. Sometimes this is not possible. An example for this is the TRIM functionality of SSD storage, where the file-system must give extra information to the storage. In this case the extension of the API is driven by the implementation and thus implementation details. This is risky as different implementations may have conflicting needs, and sometimes the API cannot fulfill both. If your case, a possible solution is to implement the os_theread_delete() and an empty function. If that is not possible, then a wrapper can be added where a variable captures info on if the thread has been exited, and thus if deletion is safe or not. If it is, then os_thread_delete() can exit without doing anything. The call sequence of suspend and the delete is specific to the OS you are using or to the way you use it. Do you think does here a strong reason exist to go for an API extension driven by the implementation? I don't have all details, but as far as I understand the specific cases you described I don't see an imminent need for the API change. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Vikas Katariya via TF-M Sent: 06 February 2020 08:47 To: Jamie Fox <Jamie.Fox(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Changes to OS wrapper Hi Jamie, Thanks for getting back. It's because of os_wrapper_thread_exit() is used to exit the child thread in the SST test, which means the handle is no longer valid for os_wrapper_thread_delete() to operate on, resulting in an error. The ideal way to do this properly is to use os_wrapper_thread_suspend() and then os_wrapper_thread_delete() from the parent thread. Thanks & Best Regards, Vikas Katariya From: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>> Sent: Wednesday, February 5, 2020 17:16 To: Vikas Katariya <Vikas.Katariya(a)arm.com<mailto:Vikas.Katariya@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: Changes to OS wrapper Hi Vikas, I still do not really understand the rationale for these changes. If dynamic memory allocation inside the os_wrapper shim is really what you want to do, then what is stopping you from implementing the following? os_wrapper_thread_new() { malloc(external_to_os_resource) /* create thread */ } os_wrapper_thread_delete() { free(external_to_os_resource) } Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vikas Katariya via TF-M Sent: 05 February 2020 10:20 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Changes to OS wrapper Hi all, The patch set has been updated with further changes: * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3294 OS wrapper layers help to create Mutex, Semaphores, and Thread on an OS. The wrapper was designed to be implemented on platforms that dynamically allocate memory or objects from a predefined OS memory pool. The current shape of the OS wrapper is not a good fit for work with operating systems that require manual memory management. For example, if the child thread created in ns_test_helpers.c does a simple os_wrapper_thread_exit(), this does not give any opportunity for manually-managed thread resources to be freed; this leads to a memory leak. Therefore os_wrapper_current_thread_suspend() and os_wrapper_thread_delete() are introduced to aid scenarios where manual memory management is required. The removal of os_wrapper_thread_exit() is warranted as it encourages applications to avoid memory leak scenarios by requiring applications to remember to call os_wrapper_thread_terminate(). If we were to keep os_wrapper_thread_exit() around, this would impose undue cognitive overhead on wrapper users by making os_wrapper_thread_exit() do something other than exit the current thread (on platforms requiring manual memory management); an os_wrapper_thread_exit() implementation could not actually exit a thread on a manual memory managed OS, as the thread must remain valid until clean up time, and exiting the thread would invalidate the OS's thread resource. * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3299 These changes reflect to avoid memory leaks on operating systems that use manually managed dynamic memory allocation but not from static memory/objects pools, allowing them to free after usage. Remove "get_handle" because it's not possible to implement it efficiently on systems that require manual memory management. The os-wrapper handle must be different from the actual underlying OS handle on a manually-memory-managed system in order to allow the resources be freed which are not managed by the OS. For example: struct { os_handle; external_to_os_resource; }; The os-wrapper knows more about the resources being managed than the OS itself. It is supposed to return an OS Wrapper handle than OS handle, because implementations can't always create an os-wrapper handle from an OS handle. In this case the os-wrapper handle could be a pointer to this struct, but could not be just the os_handle directly. Further os_wrapper_current_thread_get_priority() is used to avoid confusion between the top and bottom layer handles, because the older implementation can refer to different object types when operating across multiple layers. * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3347 - Improves test efficiency. Please review and share your thoughts. Thanks & Best Regards, Vikas Katariya From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vikas Katariya via TF-M Sent: Monday, January 27, 2020 15:52 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] App: Changes to OS wrapper 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. 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.

6 years, 1 month

1
0
0 0

Possible race condition in IRQ_TEST_SCENARIO_4?

by Thomas Törnblom

How is the IRQ_TEST_SCENARIO_4 supposed to work? I suspect that there might be a lurking race condition somewhere in that test. Some, not all, of the (M33/M23) targets gets stuck in that test when the ConfigRegression.cmake config is built with IAR in Debug mode. If I build it with RelWithDebInfo then the test runs OK for all applicable targets. No problems with Debug builds for the other configurations. Occasionally the test will run successfully also for a normally problematic target if I run it in the debugger and stop execution at breakpoints, but it is very random, which is why I suspect there might be a race problem. 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>

6 years, 1 month

1
0
0 0

Re: [TF-M] Changes to OS wrapper

by Jamie Fox

Hi Vikas, I still do not really understand the rationale for these changes. If dynamic memory allocation inside the os_wrapper shim is really what you want to do, then what is stopping you from implementing the following? os_wrapper_thread_new() { malloc(external_to_os_resource) /* create thread */ } os_wrapper_thread_delete() { free(external_to_os_resource) } Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Vikas Katariya via TF-M Sent: 05 February 2020 10:20 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Changes to OS wrapper Hi all, The patch set has been updated with further changes: * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3294 OS wrapper layers help to create Mutex, Semaphores, and Thread on an OS. The wrapper was designed to be implemented on platforms that dynamically allocate memory or objects from a predefined OS memory pool. The current shape of the OS wrapper is not a good fit for work with operating systems that require manual memory management. For example, if the child thread created in ns_test_helpers.c does a simple os_wrapper_thread_exit(), this does not give any opportunity for manually-managed thread resources to be freed; this leads to a memory leak. Therefore os_wrapper_current_thread_suspend() and os_wrapper_thread_delete() are introduced to aid scenarios where manual memory management is required. The removal of os_wrapper_thread_exit() is warranted as it encourages applications to avoid memory leak scenarios by requiring applications to remember to call os_wrapper_thread_terminate(). If we were to keep os_wrapper_thread_exit() around, this would impose undue cognitive overhead on wrapper users by making os_wrapper_thread_exit() do something other than exit the current thread (on platforms requiring manual memory management); an os_wrapper_thread_exit() implementation could not actually exit a thread on a manual memory managed OS, as the thread must remain valid until clean up time, and exiting the thread would invalidate the OS's thread resource. * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3299 These changes reflect to avoid memory leaks on operating systems that use manually managed dynamic memory allocation but not from static memory/objects pools, allowing them to free after usage. Remove "get_handle" because it's not possible to implement it efficiently on systems that require manual memory management. The os-wrapper handle must be different from the actual underlying OS handle on a manually-memory-managed system in order to allow the resources be freed which are not managed by the OS. For example: struct { os_handle; external_to_os_resource; }; The os-wrapper knows more about the resources being managed than the OS itself. It is supposed to return an OS Wrapper handle than OS handle, because implementations can't always create an os-wrapper handle from an OS handle. In this case the os-wrapper handle could be a pointer to this struct, but could not be just the os_handle directly. Further os_wrapper_current_thread_get_priority() is used to avoid confusion between the top and bottom layer handles, because the older implementation can refer to different object types when operating across multiple layers. * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3347 - Improves test efficiency. Please review and share your thoughts. Thanks & Best Regards, Vikas Katariya From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vikas Katariya via TF-M Sent: Monday, January 27, 2020 15:52 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] App: Changes to OS wrapper 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. 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, 1 month

2
1
0 0

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

by Ken Liu

I have created the patch for this issue: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3359 The non-secure entry thread re-uses the same context and stack of initial booting thread, while initial booting thread would update the context in stack while SVC to SPM initialization. The context needs to be reset after SPM initialized all threads, and the EXC_RETURN is missed during the reset process. If initial thread is executed with FP active, the EXC_RETURN generated by SVC would be 0xFFFFFFED, and cause extra 0x48 bytes to be popped while exiting from exception which causes the error. This patch resets the EXC_RETURN to 0xFFFFFFFD. Please help to comment, thanks. /Ken ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Ken Liu via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Wednesday, January 22, 2020 10:29 AM To: tf-m(a)lists.trustedfirmware.org <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 double checked in my platforms and looks fine, so you are porting them to your board, right? I have created a task for detailed description, let’s discuss the details there: https://developer.trustedfirmware.org/T652 Thanks. /Ken From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Tuesday, January 21, 2020 11:19 PM To: Ken Liu <Ken.Liu(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: RE: Stuck in tfm_nspm_thread_entry() after "Initialize IPC SPM in handler mode" 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<mailto:tf-m-bounces@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<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@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

6 years, 1 month

1
0
0 0

Re: [TF-M] Topic proposal for upcoming Open Tech Forum: CMSIS-Zone

by Anton Komlev

Hi Jonatan, All, Thanks for proposing the topic inline with the thread on flash_layout.h and region_defs.h configuration header. Let's discuss it tomorrow. All the best, Anton Komlev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Jonatan Antoni via TF-M Sent: 05 February 2020 14:11 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Topic proposal for upcoming Open Tech Forum: CMSIS-Zone Hi all, I'd like to propose to give you a short live presentation (10-15 minutes) of CMSIS-Zone [1]. In Arm DSG we are developing and using CMSIS-Zone to gather required memory partitioning data and generate consistent config file (such as partition headers, SAU/MPC/PPC configs, MPU configs, scatter files, etc). Robi made good progress aligning TF-M with Arm's tool ecosystem, such as componentization for shipping CMSIS-Packs. He used CMSIS-Zone to generate the required config files for TF-M. In my presentation I'd like to focus on configuring TF-M for NXP's LPC55 using CMSIS-Zone. Cheers, Jonatan Antoni Senior Engineering Manager - CMSIS [Germany on Google Android 8.0] [United Kingdom on Google Android 8.0] [1] https://arm-software.github.io/CMSIS_5/Zone/html/index.html Arm Germany GmbH Phone: +49 (0)89 262 029 618 | Fax: +49 (0)89 456 040-19 Email: jonatan.antoni(a)arm.com<mailto:jonatan.antoni@arm.com> | Visit: www.keil.com<http://www.keil.com > | Address: Bretonischer Ring 16, 85630 Grasbrunn, Germany Sitz der Gesellschaft: Grasbrunn | Handelsregister: München (HRB 175362) | USt-IdNr.: DE 187925309 Geschäftsführer: Joachim Krech, Reinhard Keil 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, 1 month

1
0
0 0

Topic proposal for upcoming Open Tech Forum: CMSIS-Zone

by Jonatan Antoni

Hi all, I'd like to propose to give you a short live presentation (10-15 minutes) of CMSIS-Zone [1]. In Arm DSG we are developing and using CMSIS-Zone to gather required memory partitioning data and generate consistent config file (such as partition headers, SAU/MPC/PPC configs, MPU configs, scatter files, etc). Robi made good progress aligning TF-M with Arm's tool ecosystem, such as componentization for shipping CMSIS-Packs. He used CMSIS-Zone to generate the required config files for TF-M. In my presentation I'd like to focus on configuring TF-M for NXP's LPC55 using CMSIS-Zone. Cheers, Jonatan Antoni Senior Engineering Manager - CMSIS [Germany on Google Android 8.0] [United Kingdom on Google Android 8.0] [1] https://arm-software.github.io/CMSIS_5/Zone/html/index.html Arm Germany GmbH Phone: +49 (0)89 262 029 618 | Fax: +49 (0)89 456 040-19 Email: jonatan.antoni(a)arm.com<mailto:jonatan.antoni@arm.com> | Visit: www.keil.com<http://www.keil.com > | Address: Bretonischer Ring 16, 85630 Grasbrunn, Germany Sitz der Gesellschaft: Grasbrunn | Handelsregister: München (HRB 175362) | USt-IdNr.: DE 187925309 Geschäftsführer: Joachim Krech, Reinhard Keil 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, 1 month

1
0
0 0

Re: [TF-M] PSA Test Suite - Attestation test

by Tamas Ban

Hi Andrej, Could you tell what was the values of these compile time switches in your test? I assume you did the test on NXP board. Further do you implemented the boot data sharing between bootloader and runtime firmware? Do you sign SPE and NPSE images together or they are signed separately? Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 04 February 2020 17:33 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] PSA Test Suite - Attestation test Hello, After upgrade to the latest version of TFM, the Attestation test from the PSA Test Suite is failed (but the TFM Attestation regression tests are passed). What combination of configuration parameters must be used (INCLUDE_OPTIONAL_CLAIMS, INCLUDE_TEST_CODE, INCLUDE_COSE_KEY_ID, BOOT_DATA_AVAILABLE) to follow PSA Test Suite expectations? What commit of the PSA Test-suite must be used for the latest TFM? We are still on the 2019-07-25 (c80681ed7c7f3e2cbf02ded1ef2464ba2ca7ccd5) commit, which was OK with 2-month old TFM. Is the PSA Test Suite Attestation test valid for the latest TFM? Thank you, Andrej Butok 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, 1 month

1
0
0 0

Invitation: TF-M Tech Forum @ Thu 6 Feb 2020 17:00 - 18:00 (GMT) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. Title: TF-M Tech Forum This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Feel free to forward it to colleagues.Details of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/──… Fletcher is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/5810428000Meeting ID: 581 042 8000One tap mobile+16465588656,,5810428000# US (New York)+16699009128,,5810428000# US (San Jose)Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-freeMeeting ID: 581 042 8000Find your local number: https://zoom.us/u/aerUYXPhSL────────── When: Thu 6 Feb 2020 17:00 – 18:00 United Kingdom Time Where: https://zoom.us/j/5810428000 Calendar: tf-m(a)lists.trustedfirmware.org Who: * Bill Fletcher- organiser * tf-m(a)lists.trustedfirmware.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=MGxvN2syYWc0ZWV1NXFia… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-m(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

6 years, 1 month

1
0
0 0

Re: [TF-M] Changes to OS wrapper

by Vikas Katariya

Hi all, The patch set has been updated with further changes: * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3294 OS wrapper layers help to create Mutex, Semaphores, and Thread on an OS. The wrapper was designed to be implemented on platforms that dynamically allocate memory or objects from a predefined OS memory pool. The current shape of the OS wrapper is not a good fit for work with operating systems that require manual memory management. For example, if the child thread created in ns_test_helpers.c does a simple os_wrapper_thread_exit(), this does not give any opportunity for manually-managed thread resources to be freed; this leads to a memory leak. Therefore os_wrapper_current_thread_suspend() and os_wrapper_thread_delete() are introduced to aid scenarios where manual memory management is required. The removal of os_wrapper_thread_exit() is warranted as it encourages applications to avoid memory leak scenarios by requiring applications to remember to call os_wrapper_thread_terminate(). If we were to keep os_wrapper_thread_exit() around, this would impose undue cognitive overhead on wrapper users by making os_wrapper_thread_exit() do something other than exit the current thread (on platforms requiring manual memory management); an os_wrapper_thread_exit() implementation could not actually exit a thread on a manual memory managed OS, as the thread must remain valid until clean up time, and exiting the thread would invalidate the OS's thread resource. * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3299 These changes reflect to avoid memory leaks on operating systems that use manually managed dynamic memory allocation but not from static memory/objects pools, allowing them to free after usage. Remove "get_handle" because it's not possible to implement it efficiently on systems that require manual memory management. The os-wrapper handle must be different from the actual underlying OS handle on a manually-memory-managed system in order to allow the resources be freed which are not managed by the OS. For example: struct { os_handle; external_to_os_resource; }; The os-wrapper knows more about the resources being managed than the OS itself. It is supposed to return an OS Wrapper handle than OS handle, because implementations can't always create an os-wrapper handle from an OS handle. In this case the os-wrapper handle could be a pointer to this struct, but could not be just the os_handle directly. Further os_wrapper_current_thread_get_priority() is used to avoid confusion between the top and bottom layer handles, because the older implementation can refer to different object types when operating across multiple layers. * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3347 - Improves test efficiency. Please review and share your thoughts. Thanks & Best Regards, Vikas Katariya From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Vikas Katariya via TF-M Sent: Monday, January 27, 2020 15:52 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] App: Changes to OS wrapper 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. 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, 1 month

1
0
0 0

MPS3/AN524 assistance requested

by Thomas Törnblom

To finish off the IAR port of TF-M I've added the MPS2 and MPS3 targets. The MPS2 targets works fine, but I need some assistance with getting the MPS3/AN524 port to run. I've followed the tfm_user_guide.rst, but I can't get it running with ARMCLANG or gcc either, so I suspect there is something I've missed. The board runs the an524 selftest successfully, and it shows an image on the display as well as produces output on one of the USB serial ports when I configure the board for this. I added the REMAP options described in the user guide to /MB/HBI<BoardNumberBoardrevision>/AN524/an524_v2.txt (the doc mentions v1) I updated the image.txt file with the suggested lines, except for the IMAGE0UPDATE/IMAGE1UPDATE: AUTO lines, which caused a boot error. I tried AUTOQSPI, but settled on NONE. The LOG.TXT file shows no errors What am I missing? 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>

6 years, 1 month

1
1
0 0

Re: [TF-M] TF-M NS regression tests - linker issue

by Devaraj Ranganna

Hi Ken, Currently, TF-M build process creates an pre-compiled archive of NS tests and exports it. But the implementation of `tfm_log_printf` is not exported. This causes a linker issue when NS tests archive is linked with NS RTOS, which is the reason why subject of this mail contains `linker issue`. Having said that, exporting `tfm_log_printf` won’t solve the problem because `tfm_log_printf` assumes availability of CMSIS driver framework. Also the latest suggestion on the ticket https://developer.trustedfirmware.org/T664 `And I think if you forward the TEST_LOG to your OS printf implementation then everything would be fine?` won’t help because of pre-compiled archive. It looks like only possible solution for NS RTOS is to implement ` tfm_log_printf `. Please do recommend if you have any other ideas. Thanks, Dev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Ken Liu via TF-M <tf-m(a)lists.trustedfirmware.org> Reply to: Ken Liu <Ken.Liu(a)arm.com> Date: Saturday, 1 February 2020 at 04:46 To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M NS regression tests - linker issue 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.

6 years, 1 month

2
1
0 0

PSA Test Suite - Attestation test

by Andrej Butok

Hello, After upgrade to the latest version of TFM, the Attestation test from the PSA Test Suite is failed (but the TFM Attestation regression tests are passed). What combination of configuration parameters must be used (INCLUDE_OPTIONAL_CLAIMS, INCLUDE_TEST_CODE, INCLUDE_COSE_KEY_ID, BOOT_DATA_AVAILABLE) to follow PSA Test Suite expectations? What commit of the PSA Test-suite must be used for the latest TFM? We are still on the 2019-07-25 (c80681ed7c7f3e2cbf02ded1ef2464ba2ca7ccd5) commit, which was OK with 2-month old TFM. Is the PSA Test Suite Attestation test valid for the latest TFM? Thank you, Andrej Butok

6 years, 1 month

1
0
0 0

Test: Update test framework API

by Devaraj Ranganna

Hi, Currently the test framework which executes test suites doesn't return anything. Therefore it is not possible for application layer to know the status of test cases. The patchset https://review.trustedfirmware.org/c/trusted-firmware-m/+/3172 is intended to export the test case pass/fail status to application layer and beyond (if any test framework is used by Non-secure side). If there are no objections then can the patchset be merged? 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.

6 years, 1 month

1
0
0 0

Re: [TF-M] Exporting flash_layout.h and region_defs.h

by Devaraj Ranganna

Hi, Can we agree on exporting both `flash_layout.h and region_defs.h` till a decision is made on tooling to be used/developed for device config and export in TF-M? Exporting these files doesn’t mean that NS RTOS is obligated to use these rather just a choice. If NS RTOS decides to write/generate their own then these files will just be in the TF-M export folder. Thanks, Dev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Anton Komlev via TF-M <TF-M(a)lists.trustedfirmware.org> Reply to: Anton Komlev <Anton.Komlev(a)arm.com> Date: Monday, 3 February 2020 at 17:00 To: "TF-M(a)lists.trustedfirmware.org" <TF-M(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Exporting flash_layout.h and region_defs.h Hi Robert, I see two topics mixing together in this discussion: 1. Project configuration methods/strategy 2. Tooling for that The CMSIS-Zone addresses both of the items somehow. Believe it would be beneficial if you could summaries the thoughts and bring this important topic for discussion on the upcoming Open Technical forum on Feb 6. This would be a good opportunity to present CMSIS-Zone and get a feedback from the community. The best, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: 03 February 2020 09:50 To: Robert Rostohar <Robert.Rostohar(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Exporting flash_layout.h and region_defs.h Hi Robert, “It is a standalone utility that can be used also from command-line. “ The homepage says this is the command to run it “headless”: eclipsec.exe -noSplash -consoleLog –launcher.suppressErrors -application com.arm.cmsis.zone.ui.headlessgen -azone FILENME.azone -ftl FTL_DIR -ftl_gen FTL_GEN_DIR For me this means you still need Eclipse to be installed on your PC to run it and thus this is still and IDE extension just it has support being run headless. There might be ways to run it without Eclipse, but this does not seem to be officially supported. This means there is expected to be sparse information on how-to-do this, no, or limited support. There is a risk in using this tool to generate extra work (need to work out what environment it needs, need to document it, need to test it to ensure proper operation, need to support issues with the environment, etc…). This is not really helping us for now, hopefully this changes in the future. /George From: Robert Rostohar <Robert.Rostohar(a)arm.com<mailto:Robert.Rostohar@arm.com>> Sent: 03 February 2020 09:27 To: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: Exporting flash_layout.h and region_defs.h Hi Gyorgy, Yes, the memory map needs to be communicated to non-secure world and the existing headers are not the best way. CMSIS-Zone is one possible tool that could help here and make it user friendly. It provides memory partitioning and also assignment of peripherals to secure or non-secure world. It is a standalone utility that can be used also from command-line. Best regards, Robert From: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>> Sent: Monday 3 February 2020 09:05 To: Robert Rostohar <Robert.Rostohar(a)arm.com<mailto:Robert.Rostohar@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: Exporting flash_layout.h and region_defs.h Hi, Looking at the big picture, the secure side is owning the memory map, so it seems to be inevitable to communicate this information to the non-secure world. There are many ways to do this, ranging from capturing the info in documentation to providing configuration to high-level memory layout definition tools. The build system could support multiple options, but the first implementation shall focus on portability. Having a set of header files, which (as the tf-m build system already shows) make the needed information available for both the C program, the linker and the build system, seems to be a good fit to me. It might not be the most user friendly, but is highly accessible. What those header files actually do contain is a different question. Sor security reasons it may be a good idea to remove all information not needed by the NS world. Luckily CMake has the needed features to solve this issue. And when we are at the topic, we need to provide a solution for defining available peripherals to as the secure vs non-secure peripheral availability is also controlled by the secure-side. There seems to be room for a tool independent of tf-m to help standardizing the format this information can be captured in, to help portability of this information and to enhance user-experience. Unfortunately CMSIS-Zone (as per this page https://arm-software.github.io/CMSIS_5/Zone/html/zTInstall.html ) is an IDE extension and thus it is hardly applicable in a command-line focused build environment. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Robert Rostohar via TF-M Sent: 03 February 2020 08:15 To: TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> Subject: Re: [TF-M] Exporting flash_layout.h and region_defs.h 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<mailto:tf-m-bounces@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<mailto:TF-M@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.

6 years, 1 month

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M