- 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

Re: [TF-M] QCBOR, IEEE-754, RFC 7049 and Arm Run-time ABI issues

by Thomas Törnblom

Hi Tamas, The failed tests are: --- DoubleAsSmallestTest FAILED (returned -3 ) HalfPrecisionAgainstRFCCodeTest FAILED (returned -3 ) --- Cheers, Thomas Den 2020-02-04 kl. 14:49, skrev Tamas Ban via TF-M: > > Hi Thomas, > > An extra logging can be enabled for QCBOR test cases: > https://git.trustedfirmware.org/trusted-firmware-m.git/tree/test/suites/qcb… > > Could you repeat the test with enabled logs, just to know exactly > which test cases are failing? > > The QCBOR library is used for attest token creation, but only a small > part of the library which is actually used. The IEEE 754 part of QCBOR > is unused in TF-M. So it is not affecting TF-M code, we can > temporarily disable those test cases. It is not a blocking issue for > IAR support. > > I put Laurence on cc he is the maintainer of QCBOR library, I think he > will be interested in the issue. > > Tamas > > *From:*TF-M <tf-m-bounces(a)lists.trustedfirmware.org> *On Behalf Of > *Thomas Törnblom via TF-M > *Sent:* 04 February 2020 14:01 > *To:* tf-m(a)lists.trustedfirmware.org > *Subject:* [TF-M] QCBOR, IEEE-754, RFC 7049 and Arm Run-time ABI issues > > The IAR port of TF-M is mostly done and all regression tests runs OK, > with the exception of some of the QCBOR tests. > > I've analyzed the issue to be the NaN tests to not follow the Arm > run-time ABI. > > The issue is with doubles where some of the tested NaN:s only have set > bits in the lower 32 bits of the mantissa. > > From > https://developer.arm.com/docs/ihi0043/e/run-time-abi-for-the-arm-architect… > --- > > If NaNs are supported, it is only required to recognize, process, and > convert those values with at least one bit set in the 20 most > significant bits of the mantissa. Remaining bits should be zero and > can be ignored. When a quiet NaN of one precision is converted to a > quiet of the other precision, the most significant 20 bits of the > mantissa must be preserved. Consequently: > > * A NaN can be recognized by processing the most significant or only > word of the representation. The least significant word of a double > can be ignored (it should be zero). > * Each ABI-complying value has a single-precision representation, > and a corresponding double-precision representation in which the > least significant word is zero. > * Each ABI-complying NaN value is converted between single- and > double-precision in the same way that Arm VFP VCVT instructions > convert the values. > > --- > > The IAR toolchain only checks the upper 32 bits for NaN / INF and the > double precision NaN tests misinterprets some of the hand crafted > NaN:s as INF. > > How should TF-M handle this? > > 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> > > 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. > -- *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] QCBOR, IEEE-754, RFC 7049 and Arm Run-time ABI issues

by Tamas Ban

Hi Thomas, An extra logging can be enabled for QCBOR test cases: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/test/suites/qcb… Could you repeat the test with enabled logs, just to know exactly which test cases are failing? The QCBOR library is used for attest token creation, but only a small part of the library which is actually used. The IEEE 754 part of QCBOR is unused in TF-M. So it is not affecting TF-M code, we can temporarily disable those test cases. It is not a blocking issue for IAR support. I put Laurence on cc he is the maintainer of QCBOR library, I think he will be interested in the issue. Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 04 February 2020 14:01 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] QCBOR, IEEE-754, RFC 7049 and Arm Run-time ABI issues The IAR port of TF-M is mostly done and all regression tests runs OK, with the exception of some of the QCBOR tests. I've analyzed the issue to be the NaN tests to not follow the Arm run-time ABI. The issue is with doubles where some of the tested NaN:s only have set bits in the lower 32 bits of the mantissa. >From https://developer.arm.com/docs/ihi0043/e/run-time-abi-for-the-arm-architect… --- If NaNs are supported, it is only required to recognize, process, and convert those values with at least one bit set in the 20 most significant bits of the mantissa. Remaining bits should be zero and can be ignored. When a quiet NaN of one precision is converted to a quiet of the other precision, the most significant 20 bits of the mantissa must be preserved. Consequently: * A NaN can be recognized by processing the most significant or only word of the representation. The least significant word of a double can be ignored (it should be zero). * Each ABI-complying value has a single-precision representation, and a corresponding double-precision representation in which the least significant word is zero. * Each ABI-complying NaN value is converted between single- and double-precision in the same way that Arm VFP VCVT instructions convert the values. --- The IAR toolchain only checks the upper 32 bits for NaN / INF and the double precision NaN tests misinterprets some of the hand crafted NaN:s as INF. How should TF-M handle this? 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> 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

Persistent keys in the Crypto service

by Jamie Fox

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

6 years, 1 month

1
0
0 0

HMAC authenticated staic attestation token

by Tamas Ban

Hi, TF-M Profile 1 initiative addressing TF-M footprint reduction to make TF-M usable on more constrained MCUs. As part of this activity attestation service is planned to be refactored as follows: * Static token creation: Not use QCBOR and T_COSE libraries to token creation * HMAC based token authentication: Rely only on symmetric crypto algorithms These changes are optional, the current functionality (dynamic token creation + ECDSA based authentication) remains available and default setting in higher profiles (3). A design proposal was created, feel free to review & comment: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3344 BR, Tamas

6 years, 1 month

1
0
0 0

QCBOR, IEEE-754, RFC 7049 and Arm Run-time ABI issues

by Thomas Törnblom

The IAR port of TF-M is mostly done and all regression tests runs OK, with the exception of some of the QCBOR tests. I've analyzed the issue to be the NaN tests to not follow the Arm run-time ABI. The issue is with doubles where some of the tested NaN:s only have set bits in the lower 32 bits of the mantissa. >From https://developer.arm.com/docs/ihi0043/e/run-time-abi-for-the-arm-architect… --- If NaNs are supported, it is only required to recognize, process, and convert those values with at least one bit set in the 20 most significant bits of the mantissa. Remaining bits should be zero and can be ignored. When a quiet NaN of one precision is converted to a quiet of the other precision, the most significant 20 bits of the mantissa must be preserved. Consequently: * A NaN can be recognized by processing the most significant or only word of the representation. The least significant word of a double can be ignored (it should be zero). * Each ABI-complying value has a single-precision representation, and a corresponding double-precision representation in which the least significant word is zero. * Each ABI-complying NaN value is converted between single- and double-precision in the same way that Arm VFP VCVT instructions convert the values. --- The IAR toolchain only checks the upper 32 bits for NaN / INF and the double precision NaN tests misinterprets some of the hand crafted NaN:s as INF. How should TF-M handle this? 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

TF-M NS regression tests - linker issue

by Reinhard Keil

In CMSIS we are using a Test Framework that offers the flexibility to: 1. output to classic printf, but redirecting is on just a single place. 2. Record test output to memory (for devices that have not printf facility) 3. Output the test results in XML for nice formatting using browsers (we use this for filing test reports). We have used this framework on various projects, across 4 different compilers, on many different targets (simulation, FPGA without UART, etc.). The framework is for example here https://github.com/ARM-software/CMSIS-Driver_Validation/tree/master/Source. But we used it also for various other projects. If there is interest, we could do some work to explain it better and make it scalable to TF-M.

6 years, 1 month

1
0
0 0

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

by Anton Komlev

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

Exporting flash_layout.h and region_defs.h

by Reinhard Keil

Hi George The headless mode is functional identical to a command-line mode. I agree that the command line is not self-explaining in the moment, but this can be improved over time. CMSIS-Zone is a tool that is specifically designed for Cortex-M security and MPU configuration. It is fully supported by Arm and part of our CMSIS open source activities. CMSIS-Zone * Supports all Cortex-M23/M33 devices that are on the market public today and extending this support is easy to achieve with an *.rzone file * The *.rzone approach will be part of our IP configuration activities that is under Socrates. * The template engine gives you flexibility for generating many different files, source, header, linker scripts etc. * The tool has both GUI interface and command line mode * All XML files are fully documented and explained * It generates static setup which reduces the run-time overhead and the memory footprint. Both is critical for TF-M * While it requires Eclipse framework, this is not different form other tools (i.e. Phyton requires Phyton framework). So, I somewhat cannot understand your argument. Thanks Reinhard

6 years, 1 month

1
0
0 0

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

by Gyorgy Szing

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> On Behalf Of Robert Rostohar via TF-M Sent: 03 February 2020 08:15 To: TF-M(a)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

2
2
0 0

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

by Robert Rostohar

Hi, I don’t believe this is the right approach. TF-M currently includes a non-secure side application (integration test) which is built together with the secure side. This is also reflected in “flash_layout.h” and “region_defs.h” which mixes defines for the secure and non-secure side. While this might be convenient within TF-M current build setup for the platforms that are supported, it causes issues in real applications and when trying to make this scalable across a large number of platforms. We have seen those issues already while working on providing TF-M as a CMSIS-Pack. There should be a clean separation of files between the secure and non-secure side. The mentioned header files should not be imposed to the non-secure side. Typically non-secure software will have a device specific linker script which will only need to know limited information from the memory layout (non-secure code and data location). Also the secure side might be prebuilt and the non-secure side developed and built separately. One possible solution is to use a CMSIS-Zone to partition the memory layout on a global level and then splitting it to sub-systems for secure and non-secure and exporting only relevant information for each side. This approach will be used also with TF-M CMSIS-Pack which should be available soon. Best regards, Robert From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Devaraj Ranganna via TF-M Sent: Friday 31 January 2020 17:09 To: TF-M(a)lists.trustedfirmware.org Subject: [TF-M] Exporting flash_layout.h and region_defs.h Hi, The headers `flash_layout.h` and `region_defs.h` as the name suggests defines layout of flash and how different regions are organised in flash and ram respectively. These headers define the location of Bootloader if any, secure and non-secure firmware in flash and these defines are used in the linker scripts. As far as I can tell, these headers will be used by NS RTOS without any modifications, I can confirm that, this is the case in Mbed OS. Since these headers are usually imported into NS RTOS without any modifications, I propose that we export these headers as part of the build. Thanks, Dev IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 1 month

1
0
0 0

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

by Ken Liu

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

1
0
0 0

Re: [TF-M] Compilation failure

by Jamie Fox

Hi Chris, Approved and merged, based on the two +1 reviews. Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: 31 January 2020 17:11 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Compilation failure https://review.trustedfirmware.org/c/trusted-firmware-m/+/3243 fixes a compilation error for the armclang build of the PSoc64 platform. The error was introduced by commit e3c75a4955e665e78d55b22f07db73d31a6bf101 (https://review.trustedfirmware.org/c/trusted-firmware-m/+/3031/10 ) which was merged 21st January. It would be really nice to have this breakage last less than two weeks, so is there somebody around who can approve it? Thanks, Chris This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

6 years, 1 month

2
1
0 0

Compilation failure

by Christopher Brand

https://review.trustedfirmware.org/c/trusted-firmware-m/+/3243 fixes a compilation error for the armclang build of the PSoc64 platform. The error was introduced by commit e3c75a4955e665e78d55b22f07db73d31a6bf101 (https://review.trustedfirmware.org/c/trusted-firmware-m/+/3031/10 ) which was merged 21st January. It would be really nice to have this breakage last less than two weeks, so is there somebody around who can approve it? Thanks, Chris This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

6 years, 1 month

1
0
0 0

Exporting flash_layout.h and region_defs.h

by Devaraj Ranganna

Hi, The headers `flash_layout.h` and `region_defs.h` as the name suggests defines layout of flash and how different regions are organised in flash and ram respectively. These headers define the location of Bootloader if any, secure and non-secure firmware in flash and these defines are used in the linker scripts. As far as I can tell, these headers will be used by NS RTOS without any modifications, I can confirm that, this is the case in Mbed OS. Since these headers are usually imported into NS RTOS without any modifications, I propose that we export these headers as part of the build. Thanks, Dev IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 1 month

1
0
0 0

TF-M NS regression tests - linker issue

by Devaraj Ranganna

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

6 years, 1 month

1
0
0 0

TF-M Technical Forum call - February 6

by Anton Komlev

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

6 years, 1 month

1
1
0 0

AN521 debugging

by Thomas Törnblom

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

6 years, 1 month

1
1
0 0

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

by Jamie Fox

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

6 years, 1 month

2
1
0 0

App: Changes to OS wrapper

by Vikas Katariya

Hi all, I am proposing new changes to OS wrapper layer to help other RTOS use dynamic memory allocation. OS wrapper layers help to create Mutex, Semaphores, and Thread on RTOS. The wrapper is designed to use static allocation of memory/objects from predefined OS memory pool, which is not fully featured enough to allow dynamic memory allocation and freeing them after completion, if an RTOS requires that kind of implementation. For example, the child thread created in ns_test_helpers.c does a simple exit without passing a handle if the memory was dynamically allocated, which is a memory leak scenario. Therefore os_wrapper_thread_suspend() and os_wrapper_thread_delete() are introduced to aid scenarios where dynamic memory allocation and freeing is required. In the current patch we just suspend the child thread and terminate it from parent thread. The patch is open for review here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3294 Thanks & Best Regards, Vikas Katariya IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 1 month

1
0
0 0

Disabling SHA-1 in TF-M Crypto

by Jamie Fox

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

6 years, 1 month

1
0
0 0

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

by Adrian Shaw

Yes. Wouldn’t that simplify things? Adrian On 24 Jan 2020, at 09:08, Tamas Ban via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: Do you mean to use the ITS API to read/write a monotonous counter in trusted flash? Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Adrian Shaw via TF-M Sent: 23 January 2020 13:10 To: Raef Coles <Raef.Coles(a)arm.com<mailto:Raef.Coles@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; Adrian Shaw via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: Re: [TF-M] [Request For Comments] Expose the NV counters under platform service. Do you mean the transfer of the Protected Storage service? If that is the case, then you don’t need an NV counter API because you can use the ITS API. Adrian On 23 Jan 2020, at 08:19, Raef Coles via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: I believe the reason this is being proposed is the transferal of secure storage (as opposed to protected storage) to an application root of trust partition. Such a partition would still require access to the NV counters, at least as far as I know. We ran into this issue while creating the patch to do the transferal, and Jamie suggested this was the most sensible fix. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Adrian Shaw via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: 22 January 2020 18:38 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Minos Galanakis Cc: nd Subject: Re: [TF-M] [Request For Comments] Expose the NV counters under platform service. Hi Minos, What are the use cases for Application Root of Trust services that need NV counters? The NV counters are used by the PSA Root of Trust for rollback protection of images and secure storage. There are usually very few available. Hence the question above. Adrian ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Minos Galanakis via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: 22 January 2020 17:28 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] [Request For Comments] Expose the NV counters under platform service. Hi, The Non-Volatile (NV) counters are a part of the PSA Root of Trust. In order to enable Applications residing in the Root of Trust partition to use the counters, an appropriate interface is needed. This proposal is to enhance the existing platform service, in order to expose a generic API aimed at providing access to Non-Volatile counters to applications residing in the Application Root of Trust. This implementation will not modify or affect the existing tfm_plat_nv_counters API or its’ platform specific implementation and will instead introduce a shim layer between a psa_call and the existing logic. All input, question or comments are greatly appreciated. Minos IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 1 month

1
0
0 0

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

by Tamas Ban

Do you mean to use the ITS API to read/write a monotonous counter in trusted flash? Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Adrian Shaw via TF-M Sent: 23 January 2020 13:10 To: Raef Coles <Raef.Coles(a)arm.com> Cc: nd <nd(a)arm.com>; Adrian Shaw via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] [Request For Comments] Expose the NV counters under platform service. Do you mean the transfer of the Protected Storage service? If that is the case, then you don’t need an NV counter API because you can use the ITS API. Adrian On 23 Jan 2020, at 08:19, Raef Coles via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: I believe the reason this is being proposed is the transferal of secure storage (as opposed to protected storage) to an application root of trust partition. Such a partition would still require access to the NV counters, at least as far as I know. We ran into this issue while creating the patch to do the transferal, and Jamie suggested this was the most sensible fix. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Adrian Shaw via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: 22 January 2020 18:38 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Minos Galanakis Cc: nd Subject: Re: [TF-M] [Request For Comments] Expose the NV counters under platform service. Hi Minos, What are the use cases for Application Root of Trust services that need NV counters? The NV counters are used by the PSA Root of Trust for rollback protection of images and secure storage. There are usually very few available. Hence the question above. Adrian ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Minos Galanakis via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: 22 January 2020 17:28 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] [Request For Comments] Expose the NV counters under platform service. Hi, The Non-Volatile (NV) counters are a part of the PSA Root of Trust. In order to enable Applications residing in the Root of Trust partition to use the counters, an appropriate interface is needed. This proposal is to enhance the existing platform service, in order to expose a generic API aimed at providing access to Non-Volatile counters to applications residing in the Application Root of Trust. This implementation will not modify or affect the existing tfm_plat_nv_counters API or its’ platform specific implementation and will instead introduce a shim layer between a psa_call and the existing logic. All input, question or comments are greatly appreciated. Minos IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 1 month

1
0
0 0

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

by Adrian Shaw

Do you mean the transfer of the Protected Storage service? If that is the case, then you don’t need an NV counter API because you can use the ITS API. Adrian On 23 Jan 2020, at 08:19, Raef Coles via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: I believe the reason this is being proposed is the transferal of secure storage (as opposed to protected storage) to an application root of trust partition. Such a partition would still require access to the NV counters, at least as far as I know. We ran into this issue while creating the patch to do the transferal, and Jamie suggested this was the most sensible fix. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Adrian Shaw via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: 22 January 2020 18:38 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Minos Galanakis Cc: nd Subject: Re: [TF-M] [Request For Comments] Expose the NV counters under platform service. Hi Minos, What are the use cases for Application Root of Trust services that need NV counters? The NV counters are used by the PSA Root of Trust for rollback protection of images and secure storage. There are usually very few available. Hence the question above. Adrian ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Minos Galanakis via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: 22 January 2020 17:28 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] [Request For Comments] Expose the NV counters under platform service. Hi, The Non-Volatile (NV) counters are a part of the PSA Root of Trust. In order to enable Applications residing in the Root of Trust partition to use the counters, an appropriate interface is needed. This proposal is to enhance the existing platform service, in order to expose a generic API aimed at providing access to Non-Volatile counters to applications residing in the Application Root of Trust. This implementation will not modify or affect the existing tfm_plat_nv_counters API or its’ platform specific implementation and will instead introduce a shim layer between a psa_call and the existing logic. All input, question or comments are greatly appreciated. Minos IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 1 month

1
0
0 0

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

by Raef Coles

I believe the reason this is being proposed is the transferal of secure storage (as opposed to protected storage) to an application root of trust partition. Such a partition would still require access to the NV counters, at least as far as I know. We ran into this issue while creating the patch to do the transferal, and Jamie suggested this was the most sensible fix. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Adrian Shaw via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 22 January 2020 18:38 To: tf-m(a)lists.trustedfirmware.org; Minos Galanakis Cc: nd Subject: Re: [TF-M] [Request For Comments] Expose the NV counters under platform service. Hi Minos, What are the use cases for Application Root of Trust services that need NV counters? The NV counters are used by the PSA Root of Trust for rollback protection of images and secure storage. There are usually very few available. Hence the question above. Adrian ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Minos Galanakis via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 22 January 2020 17:28 To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] [Request For Comments] Expose the NV counters under platform service. Hi, The Non-Volatile (NV) counters are a part of the PSA Root of Trust. In order to enable Applications residing in the Root of Trust partition to use the counters, an appropriate interface is needed. This proposal is to enhance the existing platform service, in order to expose a generic API aimed at providing access to Non-Volatile counters to applications residing in the Application Root of Trust. This implementation will not modify or affect the existing tfm_plat_nv_counters API or its’ platform specific implementation and will instead introduce a shim layer between a psa_call and the existing logic. All input, question or comments are greatly appreciated. Minos IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 1 month

1
0
0 0

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

by Adrian Shaw

Hi Minos, What are the use cases for Application Root of Trust services that need NV counters? The NV counters are used by the PSA Root of Trust for rollback protection of images and secure storage. There are usually very few available. Hence the question above. Adrian ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Minos Galanakis via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 22 January 2020 17:28 To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] [Request For Comments] Expose the NV counters under platform service. Hi, The Non-Volatile (NV) counters are a part of the PSA Root of Trust. In order to enable Applications residing in the Root of Trust partition to use the counters, an appropriate interface is needed. This proposal is to enhance the existing platform service, in order to expose a generic API aimed at providing access to Non-Volatile counters to applications residing in the Application Root of Trust. This implementation will not modify or affect the existing tfm_plat_nv_counters API or its’ platform specific implementation and will instead introduce a shim layer between a psa_call and the existing logic. All input, question or comments are greatly appreciated. Minos IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 1 month

1
0
0 0

[Request For Comments] Expose the NV counters under platform service.

by Minos Galanakis

Hi, The Non-Volatile (NV) counters are a part of the PSA Root of Trust. In order to enable Applications residing in the Root of Trust partition to use the counters, an appropriate interface is needed. This proposal is to enhance the existing platform service, in order to expose a generic API aimed at providing access to Non-Volatile counters to applications residing in the Application Root of Trust. This implementation will not modify or affect the existing tfm_plat_nv_counters API or its’ platform specific implementation and will instead introduce a shim layer between a psa_call and the existing logic. All input, question or comments are greatly appreciated. Minos

6 years, 1 month

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - January 23

by Jamie Fox

Hi Anton, I would like to share some details about secure storage in TF-M. I can give an overview of what we have, how to use it and recent/in progress changes, and take questions on more in-depth topics. Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 13 January 2020 11:02 To: TF-M(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M Technical Forum call - January 23 Hello, Just noted (thanks to David) that January 23 is a day ahead of Lunar New Year so we may expect less interest to the forum from Asia. This is an opportunity to make the forum time US friendly on the next session. Preliminary suggest to have it Thursday, January 23rd at 17:00-18:00 UTC. Which a morning time in US. Again, please send your topics in respond to this mail. Experts and developers could be invited to answer specific questions asked in advance. Best regards, Anton Komlev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: 09 January 2020 11:22 To: TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] TF-M Technical Forum call - January 23 Dear All, The next session of the Technical Forum is planned in 2 weeks, Thursday, January 23rd at 7:00-8:00 UTC. Please treat this email and an early invitation for agenda topic collection. Any questions, proposals, concerns are all valid points for our open discussion so do not hesitate to share it. A big or complicated topics are worth to preliminary discussed over a mailing list. Best regards, Anton Komlev

6 years, 1 month

1
0
0 0

Re: [TF-M] [Request For Comments] apply "-fno-builtin" as default compiler flags

by Ken Liu

Hi, As mentioned, we have created the patch here to apply "-fno-builtin": https://review.trustedfirmware.org/c/trusted-firmware-m/+/3217 Will keep it there for a while for validation purpose. Please help to test this patch if you are run on non-default platforms (those not listed in the platform folder). Any comment can reply or put comments under the issue: https://developer.trustedfirmware.org/T653 Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M Sent: Thursday, January 9, 2020 4:42 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] [Request For Comments] apply "-fno-builtin" as default compiler flags Hi Thomas, Just for my understanding: * Does IAR provide a C std. lib as part of IAR toolchain package? * How the std C lib linked to the image? Does user provide an explicit flag which std. C lib to linked to the image? Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Thomas Törnblom via TF-M Sent: 08 January 2020 12:45 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] [Request For Comments] apply "-fno-builtin" as default compiler flags The IAR toolchain does not produce any special "builtin" calls and thus does not have any flag similar to "-fno-builtin". /Thomas Den 2020-01-08 kl. 03:53, skrev Ken Liu via TF-M: Hi, ï¿½ As TF-M needs runtime APIs so we are creating the Secure Partition runtime library, code is ready but we have not forwarded all necessary runtime APIs to the version TF-M implemented, this was caused by the toolchain optimization for built-in APIs, such as: ï¿½ - Forward printf(%s) to puts if there is only one string parameter. - ARMCLANG would forward memxxx API into an optimized variant. ï¿½ With the '-fno-builtin' flags set in the toolchain, this optimization would be disabled so that user just implement the same name built-in to replace the toolchain version. ï¿½ Please help to check these point before applying '-fno-builtin' and provide your feedback: ï¿½ - Could toolchains out of ARMCLANG and GNUARM have a similar flag? - Would it affect your project setting and how does it affect? ï¿½ Please help to feedback. I will keep this thread open for ~1 week and let's get a conclusion after this. ï¿½ Thanks! ï¿½ /Ken -- 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> 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] Code Protection between secure services

by Andrew Thoelke

> I was referring to the Code Protection between "PSA Root of Trust" and the "Secure Services". "Secure Services" is not a defined concept in the PSA-FF description of isolation. A "RoT Service" might run in the Application RoT or in the PSA RoT. In the response below I guess that you are referring to a Service that is running in a Secure Partition in the Application RoT? > From my understanding, in isolation level 2 code of the PSA Root of Trust should be not accessible by Secure Services. > This creates the practical problem that library code cannot be shared. > > Table 5 in PSA-FF describes "Optional Isolation Rules". Is my understanding correct that PSA-FF does not require code execution protection between "PSA Root of Trust" and the "Secure Services". At level 2 "Application Root of Trust _needs protection from_ PSA Root of Trust" (section 3.1.3) However, your reading of 3.14 and 3.1.5 is correct: - Protection of code is not mandatory in an implementation. - The only mandatory rule when implementing "needs protect from" is in table 4, which in this case requires that PSA RoT "private data" is not accessible to firmware executing in the Application RoT. So an implementation is permitted to share code (and its RO data) between PSA RoT, Application RoT and even NSPE; or to prevent sharing of code across one or more of those boundaries. - Andrew 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

Code Protection between secure services

by Reinhard Keil

Sorry Andrew I was not precise enough. Maybe you can clarify again. I was referring to the Code Protection between "PSA Root of Trust" and the "Secure Services". >From my understanding, in isolation level 2 code of the PSA Root of Trust should be not accessible by Secure Services. This creates the practical problem that library code cannot be shared. Table 5 in PSA-FF describes "Optional Isolation Rules". Is my understanding correct that PSA-FF does not require code execution protection between "PSA Root of Trust" and the "Secure Services". Reinhard

6 years, 1 month

1
0
0 0

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

by Ken Liu

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> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, January 21, 2020 12:14 AM To: tf-m(a)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, 2 months

1
0
0 0

Re: [TF-M] Move dual-cpu design document into code repo

by David Hu

Hi all, All the dual-cpu design documents are merged. Any further enhancement and simplification of the design is welcome! Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Thursday, January 16, 2020 10:10 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Move dual-cpu design document into code repo Hi all, We are moving dual-cpu design documents from trustedfirmware.org wiki pages into TF-M code repo. We convert the documents to rst format, fix some typos, update them to align with latest implementation. The patches have been reviewed for several rounds in https://review.trustedfirmware.org/q/topic:%22dualcpu-docs%22+(status:open%…. The documents patches will be merged soon by this week. Please comment on the patches if there is any serious issue in the design. Any suggestion or improvement is still welcome after the patches are merged! Best regards, Hu Ziji

6 years, 2 months

1
0
0 0

Stuck in tfm_nspm_thread_entry() after "Initialize IPC SPM in handler mode"

by Andrej Butok

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, 2 months

1
0
0 0

RC4 tag

by DeMars, Alan

Is there a target date for an RC4 tag on master? RC3 is getting stale. Alan

6 years, 2 months

1
0
0 0

Re: [TF-M] Last call for reviewing TIMER IRQ patches

by David Hu

Hi Alamy, In my very own opinion, it may require more time to discuss about patch 2706, since we are not clear why IRQ test was not able to run in Level 2. Other patches look fine to me. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Alamy Liu via TF-M Sent: Friday, January 17, 2020 5:00 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Last call for reviewing TIMER IRQ patches Dear all, This is the last call to review the following patches, or it would be merged soon. 2706<https://review.trustedfirmware.org/c/trusted-firmware-m/+/2706> Build: S-IRQ: remove restriction to build Core Positive test suite 3034<https://review.trustedfirmware.org/c/trusted-firmware-m/+/3034> Platform: PSoC64: S-IRQ: enable Core Test (CORE_TEST) 3033<https://review.trustedfirmware.org/c/trusted-firmware-m/+/3033> Platform: PSoC64: S-IRQ: enable Clocks for TCPWM0 Counters 3104<https://review.trustedfirmware.org/c/trusted-firmware-m/+/3104> Platform: PSoC64: S-IRQ: Initialize Interrupt for TFM_TIMER0_IRQ 3032<https://review.trustedfirmware.org/c/trusted-firmware-m/+/3032> Platform: PSoC64: S-IRQ: porting tfm_spm_hal_xxx_irq() 3031<https://review.trustedfirmware.org/c/trusted-firmware-m/+/3031> Platform: PSoC64: S-IRQ: timer interrupt handlers 3030<https://review.trustedfirmware.org/c/trusted-firmware-m/+/3030> Platform: PSoC64: S-IRQ: Add plat_test.c 3029<https://review.trustedfirmware.org/c/trusted-firmware-m/+/3029> Platform: PSoC64: S-IRQ: Add platform_irq.h 3028<https://review.trustedfirmware.org/c/trusted-firmware-m/+/3028> Platform: PSoC64: S-IRQ: Define CY_TCPWM0_TIMERx 3027<https://review.trustedfirmware.org/c/trusted-firmware-m/+/3027> Platform: PSoC64: S-IRQ: define TFM_PERIPHERAL_TIMER0 3026<https://review.trustedfirmware.org/c/trusted-firmware-m/+/3026> Platform: PSoC64: S-IRQ: compile TCPWM Counter driver 2687<https://review.trustedfirmware.org/c/trusted-firmware-m/+/2687> Test: IRQ: use defined name from platform Best Regards, Alamy

6 years, 2 months

1
0
0 0

Last call for reviewing TIMER IRQ patches

by Alamy Liu

Dear all, This is the last call to review the following patches, or it would be merged soon. 2706 <https://review.trustedfirmware.org/c/trusted-firmware-m/+/2706> Build: S-IRQ: remove restriction to build Core Positive test suite 3034 <https://review.trustedfirmware.org/c/trusted-firmware-m/+/3034> Platform: PSoC64: S-IRQ: enable Core Test (CORE_TEST) 3033 <https://review.trustedfirmware.org/c/trusted-firmware-m/+/3033> Platform: PSoC64: S-IRQ: enable Clocks for TCPWM0 Counters 3104 <https://review.trustedfirmware.org/c/trusted-firmware-m/+/3104> Platform: PSoC64: S-IRQ: Initialize Interrupt for TFM_TIMER0_IRQ 3032 <https://review.trustedfirmware.org/c/trusted-firmware-m/+/3032> Platform: PSoC64: S-IRQ: porting tfm_spm_hal_xxx_irq() 3031 <https://review.trustedfirmware.org/c/trusted-firmware-m/+/3031> Platform: PSoC64: S-IRQ: timer interrupt handlers 3030 <https://review.trustedfirmware.org/c/trusted-firmware-m/+/3030> Platform: PSoC64: S-IRQ: Add plat_test.c 3029 <https://review.trustedfirmware.org/c/trusted-firmware-m/+/3029> Platform: PSoC64: S-IRQ: Add platform_irq.h 3028 <https://review.trustedfirmware.org/c/trusted-firmware-m/+/3028> Platform: PSoC64: S-IRQ: Define CY_TCPWM0_TIMERx 3027 <https://review.trustedfirmware.org/c/trusted-firmware-m/+/3027> Platform: PSoC64: S-IRQ: define TFM_PERIPHERAL_TIMER0 3026 <https://review.trustedfirmware.org/c/trusted-firmware-m/+/3026> Platform: PSoC64: S-IRQ: compile TCPWM Counter driver 2687 <https://review.trustedfirmware.org/c/trusted-firmware-m/+/2687> Test: IRQ: use defined name from platform Best Regards, Alamy

6 years, 2 months

1
0
0 0

Re: [TF-M] [EXTERNAL] Re: out of tree build

by Kevin Peng

Hi, I'm planning to settle down the first three patches for tools change of this topic, before Christmas. Because personally think they are very mature and close to merge. (And I've still working on the reset patches). So if there are no more new review comments, I'll go with the current reviews and try to merge it. Best Regards, Kevin -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Peng (Arm Technology China) via TF-M Sent: Friday, December 6, 2019 2:41 PM To: DeMars, Alan <ademars(a)ti.com>; 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [EXTERNAL] Re: out of tree build I've created some patches for supporting this out of tree build: https://review.trustedfirmware.org/q/topic:%22out_of_tree_build%22+(status:… I firstly modified the tools/tfm_parse_manifest_list.py so that it can take customized secure partition manifest and list of files to generate and output the files to a specified directory. You can even "append" your manifests or files to generate to the default lists under tools. The format of the yamls are the same. The tfm_parse_manifest_list.py script will also create a CMakeLists.inc which contains all the paths of generated header. And the paths are added to include search path. Other CMake projects can include this file to find generated headers. And then the generated files are moved to a dedicated folder to solve the issue mentioned below (generated headers cannot be included). Finally, the build system is able to call the parse tool to generate files in build time(can be disabled) and use the new generated files to build. You can set the optional arguments for the parse tool by setting CMake arguments: cmake -DTFM_MANIFEST(_APPEND)=some_manifest -DTFM_GEN_LIST(_APPEND)=some_generated_file -DTFM_GEN_DIR=... -G'Unix Makefiles' -DTARGET_PLATFORM=AN521 -D COMPILER=ARMCLANG -DPROJ_CONFIG=`readlink -f ConfigXXX.cmake` TFM_ROOT cmake –build Or you can pre-generate the files, disable build time generation and tell cmake the output directory only. Comments and discussions are welcome. Best Regards, Kevin -----Original Message----- From: DeMars, Alan <ademars(a)ti.com> Sent: Saturday, November 23, 2019 12:33 AM To: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com> Cc: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: RE: [TF-M] [EXTERNAL] Re: out of tree build In our use case, we added complete paths to the build area's corresponding directory to the embedded include paths and removed the default generated content from our git repo. Consequently only the newly generated content is found, wherever it happens to be placed. Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Kevin Peng (Arm Technology China) via TF-M Sent: Friday, November 22, 2019 2:15 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: Re: [TF-M] [EXTERNAL] Re: out of tree build Hi all, I'm having issues on supporting the out of tree build. So I'd like to propose some additional changes. What does the out of tree build currently support is that: The user uses the tfm_parse_manifest_list.py with the custom manifests to generate the customized files to a directory out of TF-M. And the TF-M build system uses the customized files rather than the pre-generated ones in the TF-M for building. The problem is that some of the source files include the generated headers using the relative path to where the source itself is. And the directory of the source file is always searched first. This makes it impossible to use the generated files outside TF-M even the custom output directory is added to searching list. So I suggest to put the generated files to a dedicated directory in TF-M. Then for the default build, add the directory and its subdirectories to the search list for headers. For out of tree build, use the specified directory and its subdirectories instead. Then there would only one header file with the same name in all the directories for searching headers. Any concerns, thoughts or suggestions? Best Regards, Kevin -----Original Message----- From: Kevin Peng (Arm Technology China) Sent: Friday, November 22, 2019 3:45 PM To: DeMars, Alan <ademars(a)ti.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: [EXTERNAL] Re: [TF-M] out of tree build Hi Alan, I've created a patch for the tfm_parse_manifest_list.py as the first step for the out of tree build support: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2606 The changes for build system is ongoing. The functionality changes for the tfm_parse_manifest_list.py is the same as your version. Please have a review and help verify it if possible. Comments from anyone else are also welcome. Best Regards, Kevin -----Original Message----- From: Kevin Peng (Arm Technology China) Sent: Thursday, November 14, 2019 3:31 PM To: DeMars, Alan <ademars(a)ti.com> Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> Subject: RE: [EXTERNAL] Re: [TF-M] out of tree build OK. It's much clearer for me now. Thanks. Best Regards, Kevin -----Original Message----- From: DeMars, Alan <ademars(a)ti.com> Sent: Thursday, November 14, 2019 10:34 AM To: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> Subject: Re: [EXTERNAL] Re: [TF-M] out of tree build 1) I verified the tfm_parse_manifest.py script changes using the master branch’s version of the tfm_manifest_list.yaml and tfm_generated_file_list.yaml files. 2) Yes, I’m building using the unmodified master branch’s cmake build system. 3) Just as all other build artifacts are placed in the user’s build directory and NOT in the source tree, the generated files should also. Otherwise, the user is required to update the source tree’s tfm_manifest_list.yaml and tfm_generated_file_list.yaml files to build a custom SPE, with the generated files also ending up in the source tree. The files necessary to create a custom SPE should not be kept in the source tree. Nor should the generated content be inserted in the source tree. This creates headaches for maintaining the original source tree. Alan > On Nov 13, 2019, at 1:57 AM, Kevin Peng (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Alan, > > I checked your modified tfm_parse_manifest_list.py. > It basically uses the input tfm_manifest_list.yaml and tfm_generated_file_list.yaml to generate the TF-M auto generated files to the third input. > > I'm sorry I was not in the workshop. So I have some questions. > 1. Do you have your own tfm_manifest_list.yaml and tfm_generated_file_list.yaml that is not upstreamed in TF-M? > 2. Are you using the TF-M provided CMake build system? > 3. Do you only need the files generated by tfm_parse_manifest_list.py to be out of the TF-M source directory? > > Could you provide some details about your requirements. Thanks. > > Best Regards, > Kevin > > -----Original Message----- > From: Kevin Peng (Arm Technology China) > Sent: Wednesday, November 13, 2019 10:27 AM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: RE: out of tree build > > Hi Alan, > > I'm following on this and will get you updated on any progress. > > Best Regards, > Kevin > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M > Sent: Thursday, November 7, 2019 12:42 PM > To: Abhishek Pandit <Abhishek.Pandit(a)arm.com> > Cc: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> > Subject: Re: [TF-M] out of tree build > > Trying again after renaming tfm_parse_manifest_list.py to tfm_parse_manifest_list.txt so it wouldn't get deleted. > --- > > With the attached modified secure_fw/CMakeLists.txt and tools/tfm_parse_manifest_list.py files, I am able to redirect the generated files using the following command line: > > python3 <full_path_to_your>/tfm_parse_manifest_list.py <full_path_to_your>/tfm_manifest_list.yaml <full_path_to_your>/tfm_generated_file_list.yaml <full_path_to_your>/<build_dir> > > And then build the ConfigCoreIPC artifacts within <your_build_dir> using the following cmake line: > > cmake -G"Unix Makefiles" -DPROJ_CONFIG=`readlink -f ../configs/ConfigCoreIPC.cmake` -DREMOTE_GEN_DIR=<full_path_to_your><build_dir> -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM ../ > > The changes to tfm_parse_manifest_list.py are backward compatible with the standard usage. > > Alan > > > -----Original Message----- > From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M > Sent: Monday, November 4, 2019 4:36 PM > To: Abhishek Pandit; tf-m(a)lists.trustedfirmware.org > Subject: [EXTERNAL] Re: [TF-M] out of tree build > > Abishek, > > Yes, we have modified tfm_gen.py and tfm_parse_manifest_list.py to support redirecting the destination of the generated template files into a command line provided destination build directory. > A corresponding change to our platform's platform/ext/xyz.cmake file was also required to add the path to the root of the build directory to the embedded_include_directories() list as well as the paths to the generated linker command files. > > I was not planning to provide these changes as a patch for review as I am very unsure of the applicability of this to other platforms. Also, I was fairly certain that given my very poor understanding of the CMake build system, my approach to the problem was not utilizing features present in CMake that would make the job simpler and more extensible. > > Since the topic came up at the conference and you already seemed willing to address the out-of-tree build problem that the templates lead to, I assumed you folks would find a simple and elegant solution that would save me the embarrassment of exposing my lack of CMake expertise. > > Alan > > -----Original Message----- > From: Abhishek Pandit [mailto:Abhishek.Pandit@arm.com] > Sent: Monday, November 4, 2019 3:08 PM > To: DeMars, Alan; tf-m(a)lists.trustedfirmware.org > Subject: [EXTERNAL] RE: out of tree build > > Hi Alan, > Not sure if I remember the exact detail from the workshop last week, but did you mention that you have a prototype for this? If so, are you planning to push a patch for review? > Thanks, > Abhishek > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M > Sent: 01 November 2019 16:29 > To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> > Subject: [TF-M] out of tree build > > Please modify the template generators to support out of tree build, and modify the CMake files to add the necessary include paths so that the files that include the template-generated files can find them. > > Alan > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 2 months

1
1
0 0

Move dual-cpu design document into code repo

by David Hu

Hi all, We are moving dual-cpu design documents from trustedfirmware.org wiki pages into TF-M code repo. We convert the documents to rst format, fix some typos, update them to align with latest implementation. The patches have been reviewed for several rounds in https://review.trustedfirmware.org/q/topic:%22dualcpu-docs%22+(status:open%…. The documents patches will be merged soon by this week. Please comment on the patches if there is any serious issue in the design. Any suggestion or improvement is still welcome after the patches are merged! Best regards, Hu Ziji

6 years, 2 months

1
0
0 0

Re: [TF-M] [Call for cygwin volunteers] Remove the mbed-crypto building workaround

by Ken Liu

From the feedbacks till now, no fault case is reported, let merge this patch. If someone met problem while building please reply in the mailing list. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Thursday, January 9, 2020 9:32 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [Call for cygwin volunteers] Remove the mbed-crypto building workaround Got 3 feedbacks till now all reports no problem. I am going to merge this one before end of today. /Ken 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: Monday, January 6, 2020 1:56 PM 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] [Call for cygwin volunteers] Remove the mbed-crypto building workaround Thanks for the feedback, let me take a note. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Qixiang Xu via TF-M Sent: Monday, January 6, 2020 1:49 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] [Call for cygwin volunteers] Remove the mbed-crypto building workaround Ken, I have cherry picked the patch and tested it on Cygwin: $ cmake --version cmake version 3.11.1 CMake suite maintained and supported by Kitware (kitware.com/cmake). The patch works and no issue found. Best Regards, Qixiang Xu 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: Monday, January 6, 2020 11:00 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: [TF-M] [Call for cygwin volunteers] Remove the mbed-crypto building workaround Hi, I create a patch for removing the workaround for mbed-crypto building: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3022 We tried on cmake 3.7 and 3.10 with cygwin and it works; can some Cygwin/mingw user pick this patch and test if it could work in your side? Thanks for your contribution 😊 /Ken 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, 2 months

1
0
0 0

Invitation: TF-M Tech Forum @ Thu 23 Jan 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. ────────── Bill Fletcher is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/5810428000 Meeting ID: 581 042 8000 One 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-free Meeting ID: 581 042 8000 Find your local number: https://zoom.us/u/aerUYXPhSL ────────── When: Thu 23 Jan 2020 17:00 – 18:00 United Kingdom Time Where: https://zoom.us/j/5810428000 Calendar: tf-m(a)lists.trustedfirmware.org Who: (Guest list has been hidden at organiser's request) Event details: https://www.google.com/calendar/event?action=VIEW&eid=MzB0czdyMXVlMXBpaGY5M… 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, 2 months

1
0
0 0

Re: [TF-M] T398: Update to IAR support

by Karl Zhang

Hi Thomas Thanks for the update, I go through your new patches initially and give some first review comments. Besides, I am trying to have a build by IAR myself, and do a more detail review later. Please be aware, the concept for review now is to make sure the new compiler can work on specified platform and won't block the current TFM process. Since the new year holiday coming soon in China, my response may slow before 1st Feb. Sorry about that. Thanks Karl From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas T?rnblom via TF-M Sent: Tuesday, January 14, 2020 16:38 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] T398: Update to IAR support I have just pushed the latest commits for the source cleanup and IAR integration. https://review.trustedfirmware.org/c/trusted-firmware-m/+/3127/1 Please review. Thanks, Thomas -- Thomas Tï¿½rnblom, Product Engineer IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>

6 years, 2 months

1
0
0 0

Jan 23rd call details

by Mohammed Billoo

Hello, May I get the invite for the call next week? Thank you -- Mohammed A Billoo Founder MAB Labs, LLC www.mab-labs.com 201-201-8088

6 years, 2 months

1
0
0 0

T398: Update to IAR support

by Thomas Törnblom

I have just pushed the latest commits for the source cleanup and IAR integration. https://review.trustedfirmware.org/c/trusted-firmware-m/+/3127/1 Please review. Thanks, Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

6 years, 2 months

1
0
0 0

Re: [TF-M] Code Protection between secure services

by Andrew Thoelke

PSA-FF does not require isolation of code. Section 3.1 describes the isolation architecture (pages 21-25) and has three mandatory rules: 1. Only "code" is executable 2. Only "private data" is writable 3. "private data" is protected from untrusted "protection domains". (E.g. secure side "private data" cannot be accessed by non-secure) [quoted items are defined terms in that section of the document] Protecting "code" and "constant data" from other "protection domains" is provided in optional isolation rules 4, 5 and 6 with increasing levels of isolation (and system cost). The security rationale for isolating code is (a) confidentiality of the code and associated read-only data and (b) reduction of the number of ROP/JOP gadgets available to an attacker. The level of isolation and implementation of the optional rules is intended to be a framework and/or product decision in order to match the product security requirements. Regards, Andrew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 09 January 2020 09:01 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Code Protection between secure services Hi, I assume the main purpose of isolation would be protect the code been seen by the AppRoT. Let's check with the FF author for detailed answers. The building instructions now is just create separate libraries and finally combine them together - since vendors can create Secure Partitions, these modularized building can't be avoided. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Reinhard Keil via TF-M Sent: Thursday, January 9, 2020 4:00 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Code Protection between secure services I suggest we review the requirement of code isolation on the secure side. R/W data and R/O data should definitely be isolated, but code isolation has implications: * Code cannot be share between services (i.e. no linker optimization to reduce memory footprint) * Sharing library code * Overall the build instructions of the system are more complicated * Adding device specific driver code (i.e. to crypto) can become tricky Reinhard 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, 2 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - January 23

by Anton Komlev

Hello, Just noted (thanks to David) that January 23 is a day ahead of Lunar New Year so we may expect less interest to the forum from Asia. This is an opportunity to make the forum time US friendly on the next session. Preliminary suggest to have it Thursday, January 23rd at 17:00-18:00 UTC. Which a morning time in US. Again, please send your topics in respond to this mail. Experts and developers could be invited to answer specific questions asked in advance. Best regards, Anton Komlev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 09 January 2020 11:22 To: TF-M(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - January 23 Dear All, The next session of the Technical Forum is planned in 2 weeks, Thursday, January 23rd at 7:00-8:00 UTC. Please treat this email and an early invitation for agenda topic collection. Any questions, proposals, concerns are all valid points for our open discussion so do not hesitate to share it. A big or complicated topics are worth to preliminary discussed over a mailing list. Best regards, Anton Komlev

6 years, 2 months

1
0
0 0

Re: [TF-M] Create another branch for feature development

by Edison Ai

Thanks Minos for comment. I agree that there is still a small window as you describe in the 2nd case. Maybe this only can be solved by a super maintain who can merged patches to the master branch. I am not sure if Gerrit can be enhanced to do this: it can trigger CI to do the test when it detects one merged patch are not on the TOP when two dev branches are merged at the same time. So that, we still can catch the problem soon even patches are merged to the master branch. I also agree your most of the assumptions except this: "There is no mitigation for scenarios of having individually tested patches merged in a small window, introducing a bug when combined, or having a patch-chain merged, and some of the intermediate patches breaking master but the final patch passing tests." It is why we are discussing if we need to import the development or integration branch to TF-M to help to solve these problems partly. I agree the newly added branch cannot confirm the master branch is stable 100%. But it is significant if it can help improve stability. There are many things we can and maybe we need to do to help to increase the quality of merged patches and help the users to use the master branch more convenient, such as policy, CI, code review, self-test, etc. The new branch is just only one part. Thanks, Edison From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Minos Galanakis via TF-M Sent: Friday, January 10, 2020 6:18 PM To: Edison Ai via TF-M <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Create another branch for feature development Hi. I am a bit confused on how would the following be addressed by a having a dedicated development branch. Would it be possible to elaborate please? There is another way maybe help to solve this problem, we can define a merge policy like this: The patches cannot be merged to master branch if the patch is not based on the TOP HEAD. 1. If you have dev branches A and B, with common ancestry the HEAD_M , they both have been tested, and are merged with 2 minutes difference, then branch B will be based on A and will not have tested in that way, but will be present in master and assumed stable. 2. If you have dev branches A and B , and we decide as policy that B needs to constantly be based on A ( i.e the newest patch should be based on the last patch under review ). There will always be a still a small window that you can make a change in A, merge it, and B is not updated. Not to account for the significant overhead this will have to development. 3. If we adopt a generic dev branch and merge it to master overnight then this problem does not exist to begin with but the overall development flow will be delayed. The TF-M Merge strategy has the following components: * Master as the common development branch. * Release Tags for stable releases, based on master * Feature branches for development of big changes without affecting the flow of master To my understanding the following assumptions apply: * RC tags are always stable and extensively tested. * Feature branches usually are based on RC tags, and re-based on top of master right before merging them. * Master should be stable, but is not guaranteed to to. * There is no mitigation for scenarios of having individually tested patches merged in a small window, introducing a bug when combined, or having a patch-chain merged, and some of the intermediate patches breaking master but the final patch passing tests. * It is impossible to test everything all the time, while keeping the merge bandwidth at maximum. The CI will have to test a significant amount of platforms, but relies on the developer on having a look on weather his change may affect anything outside of this scope. Since with the current process flow, there is no roll-back strategy, or a merge windows, there is a significant time gain in the time that each patch is held back when in review. Then the assumption is that if it breaks something which has not been tested, the developer will have to commit some extra time to address it. If that trade-off is unacceptable it can easily be addressed with a policy change. In community projects the most commonly accepted solution that seems to mitigate a scenario of patches A, B being merged in a small time delta, is using "merge windows". But before we adopt any new policy we should be evaluating our needs. To that end would it be possible to go back to start and decide on the requirements? What are we trying to achieve? What are we trying to address? What would the acceptable cost in development time be? Regards, Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Edison Ai via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: 10 January 2020 07:40 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Create another branch for feature development Hi, Let's continue to discuss this topic. I agree with this, the CI is just a tool, we should not only rely on it. Thanks Gyorgy to point out the quality policy, we need to think about them when we discuss the version control. In the current status, there is only one master branch for most of the development work in TF-M. Of course, we can add a warning to say that the master is constantly changing, there may be some problems in building or test running, and let the user use the release tag. But it is not convenience and impossible if they are upstreaming patches. And even to TF-M developers, we had met several times of the master branch is broken. There is another way maybe help to solve this problem, we can define a merge policy like this: The patches cannot be merged to master branch if the patch is not based on the TOP HEAD. But this is very difficult to follow because there may be several maintainers could and need to merged patches at the same time. They need to align with each other to confirm their patches are on the TOP. But now, we often meet this case, while one patch rebases to TOP and waiting for the CI result, another patch is merged into master. The patch needs to rebase again. I do not want to give more examples here. Of course, it is a big change to involve a new branch, there must be many documents that need to be updated, and some policies need to be changed. And even this needs someone to maintain the alignment with 2 branches. But I think it is more useful and helpful for all users. Thanks, Edison -----Original Message----- 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: Friday, December 13, 2019 10:01 PM To: Minos Galanakis <Minos.Galanakis(a)arm.com<mailto:Minos.Galanakis@arm.com>>; Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@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] Create another branch for feature development Hi, Hi, I agree, the CI shall not dictate how we use the version control system. It shall adapt. Regarding your suggestions, I think the main problem is we are mixing stuff, this time quality with version control. Before we make decisions we shall understand where we are. The current quality policy is that we only make releases for communication purposes. To give a clean interface for tf-m users and to allow planning their work. Releases allow them to execute their tf-m integration process less frequently. Only for each release or specific releases and not for each commit. The current quality policy identifies a single quality level only, and says any patch we publish is "golden quality", it matches the highest quality standard we can achieve (with sane constraints). Also to make our life easy we decided to use the master branch to hold these patches. At the same time we use the master branch for development. Any change we make is made against master. This means each pull request and thus each review targets master. For review purposes the best is to have a chain of small modifications, otherwise the review content becomes too large to follow. The TF-A "branching strategy" tries to address this issue by introducing an integration branch used for development. This allows master to be more release specific. I suggest to take the following approach (details to be discussed): - introduce more quality levels i.e.: - none: content of a topic branch, or content pushed to review. - bronze: content passed code review and patch specific testing. - silver: content passed a more though daily testing. - gold: a release. A pack of source-code, feature state document (release notes), reviewed documentation (user manual, reference manual), test evidence, documentation of test efforts to allow repeatability. The version control system can be used to store content, and to provide identification info (i.e. tagging), but most likely the release will need other kind of storage to be used (i.e. documentation). - platina: reaching extra quality level trough passing PSA or some FUSA qualification. Or we may simply use extra release for this. Naming the quality levels allows us to have a cleaner definition of what can be expected at a specific level (set of quality measures, i.e. static analysis, code review, test configuration). It would also allow us cleaner communication and to find how we use the version system for quality purposes. I also expect this discussion to help defining how the version system is used for development purposes. The current state works ok, but is a sort of naturally grown. We might have reached the point when more pragmatic approach may be needed. /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Minos Galanakis via TF-M Sent: 13 December 2019 12:23 To: Edison Ai (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>; Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Create another branch for feature development Hi all. My personal comments on this. I would like to point out that the CI is a tool, not the core project. I do not believe we should be changing our development strategy based on what the tool is doing. We should instead adjust the tool to fit our requirements. * No patches should be/ are merged to master when CI fails. If master breaks it should most commonly be because of something we are not testing for. Using an integration branch would not change that. * As a developer I find it more convoluted to work with projects who use different integration strategies. The most common assumption in open source projects is that you have a master branch which is the bleeding edge, but can contain untested bugs, and the release immutable git tags for versioning. Using branch merges as versioning is a design for the pull request model which is not quite compatible with Gerrit. * Most of the CI downtime has nothing to do with the merge strategy, they are more of a chicken and the egg philosophical problem. If your patch or branch introduced a change which affects the tests outputs, how will you test it if the CI expects the old output? An integration branch would not solve the merge freeze periods, would just affect a different branch from master. * I believe feature branches are quite useful, since changes to master do not disrupt the development flow of a big change, and even though they will require some maintenance to re-sync before the final patch , it will be handled by an engineer who knows the feature, and full understands the regression vectors. If I were to suggest some changes for stability purposes, I would start smaller: * Update documentation to instruct users to check out from release tags, warning then that master is constantly changing. * Adjust the CI to detect an Allow-CI flag from every branch. That way developers can test any patch from any feature branch. The logic for that is already present in the code, but requires Gerrit to be configured accordingly. * Add an undo process. This would be the only case for an integration branch. All patches are merged to a temporary branch, after confirming they have passed testing individually. On the once per day nightly test, the group of different patches, will be tested against an extensive job, in models and hardware, and only if successful it will fast forward master to that state. Regards Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Edison Ai (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: 13 December 2019 08:55 To: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>>; 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Create another branch for feature development Hi Soby, Thanks for your detail description. > Integration is a temporary merge branch to merge several patches and run the CI against. Usually once CI passes, the master will be fast forwarded to integration within a day. > This helps us to test integration of patches and detect any failure before master is updated. This means the master will pass CI at any given merge point. I think it's a good method like this so that we can double confirm the "master" branch is stable. And this also can fix one case even the CI can work normally: one patch is ready to merge, and it is not based on the latest HEAD, but there is no conflict. We can merge the patch directly and let gerrit do rebase by itself. But we cannot confirm the CI test can pass. Any comment for this from others? For multiple feature branches, I think we can stop to discuss about it now until we have some strong demands for it. It is indeed a big change for us now. Thanks, Edison -----Original Message----- From: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> Sent: Friday, December 13, 2019 5:14 AM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com<mailto:Edison.Ai@arm.com>>; 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Create another branch for feature development On 11/12/2019 09:05, Edison Ai (Arm Technology China) via TF-M wrote: > Hi Gyorgy, > > Thanks to point it out. I agree with you that it will be better if we can align these two projects in this. I had a quick check the branches from TF-A: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/. > There are three branches in TF-A: > - "integration" branch, should be used for new features. > - "master" branch, which is behind of "integration" branch. But I am nor sure what is the strategy to update it. Hi Edison, Integration is a temporary merge branch to merge several patches and run the CI against. Usually once CI passes, the master will be fast forwarded to integration within a day. This helps us to test integration of patches and detect any failure before master is updated. This means the master will pass CI at any given merge point. > - "topics/epic_beta0_spmd", I thinks it should like a feature branch for big feature. > @Soby Mathew Could you help to share more information about it? Thanks very much. We usually do not have feature branches in TF-A. The topics/epic_beta0_spmd is a prototyping branch where we wanted to share code with collaborators outside TF-A. The patches on this branch are not visible in gerrit review and no patches in gerrit review will be merged to this branch. Once the prototyping is complete, then patches on this branch will be reworked and pushed to gerrit review and finally get merged to integration and this branch will be deleted. Our experience have been, long running development branches are generally a maintenance overhead. Merging these development branches before a release may also be risky as some of the changes may have unknown interactions and may become difficult to resolve. The "topic" in gerrit review is effectively a branch. For example, this review: https://review.trustedfirmware.org/#/q/topic:od/debugfs+(status:open+OR+sta… is a set of patches on topic "od/debugfs" and can be treated as development branch. This branch is alive as long as patches are not merged. We need to understand the motivations for the change. Broken CI is an argument but development branches will only exacerbate that problem since we don't know the stability of each of those branches. Also merge conflict will not reduce due to development branches. Its just delaying the merge conflict to a later point. There may be other reasons, but generally it is better to merge sensible patches (+2ed) within a feature even before the feature is complete as it will reduce merge conflicts (we have to ensure testing/build coverage for the patch). These are my thoughts on this. Best Regards Soby Mathew -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 2 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - January 9

by Bill Fletcher

The meeting video recording and slides are now posted at https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Regards Bill On Wed, 8 Jan 2020 at 11:00, Anton Komlev via TF-M < tf-m(a)lists.trustedfirmware.org> wrote: > Hi All, > > > > Thanks, Ken and Edison for offering the topics for tomorrow’s Tech forum. > > The agenda (always open) starts from: > > 1. Secure Partition Runtime Library > 2. PSA FF 1.0.0 alignment > > > > Best regards, > > Anton > > > > *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org> * On Behalf Of *Edison > Ai via TF-M > *Sent:* 07 January 2020 08:19 > *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 Technical Forum call - January 9 > > > > Hi Anton, > > > > I will share something about the PSA FF 1.0.0 alignment. About 10 – 15 > minutes. > > > > Thanks, > > Edison > > > > *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org> *On Behalf Of *Ken > Liu via TF-M > *Sent:* Tuesday, January 7, 2020 3:33 PM > *To:* tf-m(a)lists.trustedfirmware.org > *Cc:* nd <nd(a)arm.com> > *Subject:* Re: [TF-M] TF-M Technical Forum call - January 9 > > > > Hi Anton, > > I can share the status of Secure Partition Runtime Library in the tech > forum. > > > > /Ken > > > > *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org> *On Behalf Of *Anton > Komlev via TF-M > *Sent:* Tuesday, January 7, 2020 1:56 AM > *To:* TF-M(a)lists.trustedfirmware.org > *Cc:* nd <nd(a)arm.com> > *Subject:* [TF-M] TF-M Technical Forum call - January 9 > > > > Hello, > > > > Hope that the new year is truly happy for everybody. > > The next session of the Technical Forum is planned on the coming *Thursday, > January 9th*. > > Regarding the time, I think that the last session was a good compromise to > suit majority of the participants so propose to keep the time slot *at > 7:00-8:00 UTC*. > > This time suits members in Europe and Asia, although participants from US > (specially from the East coast) might have inconveniences. > > Reminding that the recorded sessions and materials are available on the > web site: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ > > > > Please reply to this email to post your topics for the agenda. Any > questions, proposals, concerns are all valid points for our open discussion > so do not hesitate to share it. > > > > Best regards, > > Anton Komlev > > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

6 years, 2 months

1
0
0 0

Re: [TF-M] Create another branch for feature development

by Minos Galanakis

Hi. I am a bit confused on how would the following be addressed by a having a dedicated development branch. Would it be possible to elaborate please? There is another way maybe help to solve this problem, we can define a merge policy like this: The patches cannot be merged to master branch if the patch is not based on the TOP HEAD. 1. If you have dev branches A and B, with common ancestry the HEAD_M , they both have been tested, and are merged with 2 minutes difference, then branch B will be based on A and will not have tested in that way, but will be present in master and assumed stable. 2. If you have dev branches A and B , and we decide as policy that B needs to constantly be based on A ( i.e the newest patch should be based on the last patch under review ). There will always be a still a small window that you can make a change in A, merge it, and B is not updated. Not to account for the significant overhead this will have to development. 3. If we adopt a generic dev branch and merge it to master overnight then this problem does not exist to begin with but the overall development flow will be delayed. The TF-M Merge strategy has the following components: * Master as the common development branch. * Release Tags for stable releases, based on master * Feature branches for development of big changes without affecting the flow of master To my understanding the following assumptions apply: * RC tags are always stable and extensively tested. * Feature branches usually are based on RC tags, and re-based on top of master right before merging them. * Master should be stable, but is not guaranteed to to. * There is no mitigation for scenarios of having individually tested patches merged in a small window, introducing a bug when combined, or having a patch-chain merged, and some of the intermediate patches breaking master but the final patch passing tests. * It is impossible to test everything all the time, while keeping the merge bandwidth at maximum. The CI will have to test a significant amount of platforms, but relies on the developer on having a look on weather his change may affect anything outside of this scope. Since with the current process flow, there is no roll-back strategy, or a merge windows, there is a significant time gain in the time that each patch is held back when in review. Then the assumption is that if it breaks something which has not been tested, the developer will have to commit some extra time to address it. If that trade-off is unacceptable it can easily be addressed with a policy change. In community projects the most commonly accepted solution that seems to mitigate a scenario of patches A, B being merged in a small time delta, is using "merge windows". But before we adopt any new policy we should be evaluating our needs. To that end would it be possible to go back to start and decide on the requirements? What are we trying to achieve? What are we trying to address? What would the acceptable cost in development time be? Regards, Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Edison Ai via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 10 January 2020 07:40 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Create another branch for feature development Hi, Let's continue to discuss this topic. I agree with this, the CI is just a tool, we should not only rely on it. Thanks Gyorgy to point out the quality policy, we need to think about them when we discuss the version control. In the current status, there is only one master branch for most of the development work in TF-M. Of course, we can add a warning to say that the master is constantly changing, there may be some problems in building or test running, and let the user use the release tag. But it is not convenience and impossible if they are upstreaming patches. And even to TF-M developers, we had met several times of the master branch is broken. There is another way maybe help to solve this problem, we can define a merge policy like this: The patches cannot be merged to master branch if the patch is not based on the TOP HEAD. But this is very difficult to follow because there may be several maintainers could and need to merged patches at the same time. They need to align with each other to confirm their patches are on the TOP. But now, we often meet this case, while one patch rebases to TOP and waiting for the CI result, another patch is merged into master. The patch needs to rebase again. I do not want to give more examples here. Of course, it is a big change to involve a new branch, there must be many documents that need to be updated, and some policies need to be changed. And even this needs someone to maintain the alignment with 2 branches. But I think it is more useful and helpful for all users. Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: Friday, December 13, 2019 10:01 PM To: Minos Galanakis <Minos.Galanakis(a)arm.com>; Soby Mathew <Soby.Mathew(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Create another branch for feature development Hi, Hi, I agree, the CI shall not dictate how we use the version control system. It shall adapt. Regarding your suggestions, I think the main problem is we are mixing stuff, this time quality with version control. Before we make decisions we shall understand where we are. The current quality policy is that we only make releases for communication purposes. To give a clean interface for tf-m users and to allow planning their work. Releases allow them to execute their tf-m integration process less frequently. Only for each release or specific releases and not for each commit. The current quality policy identifies a single quality level only, and says any patch we publish is "golden quality", it matches the highest quality standard we can achieve (with sane constraints). Also to make our life easy we decided to use the master branch to hold these patches. At the same time we use the master branch for development. Any change we make is made against master. This means each pull request and thus each review targets master. For review purposes the best is to have a chain of small modifications, otherwise the review content becomes too large to follow. The TF-A "branching strategy" tries to address this issue by introducing an integration branch used for development. This allows master to be more release specific. I suggest to take the following approach (details to be discussed): - introduce more quality levels i.e.: - none: content of a topic branch, or content pushed to review. - bronze: content passed code review and patch specific testing. - silver: content passed a more though daily testing. - gold: a release. A pack of source-code, feature state document (release notes), reviewed documentation (user manual, reference manual), test evidence, documentation of test efforts to allow repeatability. The version control system can be used to store content, and to provide identification info (i.e. tagging), but most likely the release will need other kind of storage to be used (i.e. documentation). - platina: reaching extra quality level trough passing PSA or some FUSA qualification. Or we may simply use extra release for this. Naming the quality levels allows us to have a cleaner definition of what can be expected at a specific level (set of quality measures, i.e. static analysis, code review, test configuration). It would also allow us cleaner communication and to find how we use the version system for quality purposes. I also expect this discussion to help defining how the version system is used for development purposes. The current state works ok, but is a sort of naturally grown. We might have reached the point when more pragmatic approach may be needed. /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Minos Galanakis via TF-M Sent: 13 December 2019 12:23 To: Edison Ai (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org>; Soby Mathew <Soby.Mathew(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Create another branch for feature development Hi all. My personal comments on this. I would like to point out that the CI is a tool, not the core project. I do not believe we should be changing our development strategy based on what the tool is doing. We should instead adjust the tool to fit our requirements. * No patches should be/ are merged to master when CI fails. If master breaks it should most commonly be because of something we are not testing for. Using an integration branch would not change that. * As a developer I find it more convoluted to work with projects who use different integration strategies. The most common assumption in open source projects is that you have a master branch which is the bleeding edge, but can contain untested bugs, and the release immutable git tags for versioning. Using branch merges as versioning is a design for the pull request model which is not quite compatible with Gerrit. * Most of the CI downtime has nothing to do with the merge strategy, they are more of a chicken and the egg philosophical problem. If your patch or branch introduced a change which affects the tests outputs, how will you test it if the CI expects the old output? An integration branch would not solve the merge freeze periods, would just affect a different branch from master. * I believe feature branches are quite useful, since changes to master do not disrupt the development flow of a big change, and even though they will require some maintenance to re-sync before the final patch , it will be handled by an engineer who knows the feature, and full understands the regression vectors. If I were to suggest some changes for stability purposes, I would start smaller: * Update documentation to instruct users to check out from release tags, warning then that master is constantly changing. * Adjust the CI to detect an Allow-CI flag from every branch. That way developers can test any patch from any feature branch. The logic for that is already present in the code, but requires Gerrit to be configured accordingly. * Add an undo process. This would be the only case for an integration branch. All patches are merged to a temporary branch, after confirming they have passed testing individually. On the once per day nightly test, the group of different patches, will be tested against an extensive job, in models and hardware, and only if successful it will fast forward master to that state. Regards Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Edison Ai (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 13 December 2019 08:55 To: Soby Mathew <Soby.Mathew(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] Create another branch for feature development Hi Soby, Thanks for your detail description. > Integration is a temporary merge branch to merge several patches and run the CI against. Usually once CI passes, the master will be fast forwarded to integration within a day. > This helps us to test integration of patches and detect any failure before master is updated. This means the master will pass CI at any given merge point. I think it's a good method like this so that we can double confirm the "master" branch is stable. And this also can fix one case even the CI can work normally: one patch is ready to merge, and it is not based on the latest HEAD, but there is no conflict. We can merge the patch directly and let gerrit do rebase by itself. But we cannot confirm the CI test can pass. Any comment for this from others? For multiple feature branches, I think we can stop to discuss about it now until we have some strong demands for it. It is indeed a big change for us now. Thanks, Edison -----Original Message----- From: Soby Mathew <Soby.Mathew(a)arm.com> Sent: Friday, December 13, 2019 5:14 AM To: Edison Ai (Arm Technology China) <Edison.Ai(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] Create another branch for feature development On 11/12/2019 09:05, Edison Ai (Arm Technology China) via TF-M wrote: > Hi Gyorgy, > > Thanks to point it out. I agree with you that it will be better if we can align these two projects in this. I had a quick check the branches from TF-A: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/. > There are three branches in TF-A: > - "integration" branch, should be used for new features. > - "master" branch, which is behind of "integration" branch. But I am nor sure what is the strategy to update it. Hi Edison, Integration is a temporary merge branch to merge several patches and run the CI against. Usually once CI passes, the master will be fast forwarded to integration within a day. This helps us to test integration of patches and detect any failure before master is updated. This means the master will pass CI at any given merge point. > - "topics/epic_beta0_spmd", I thinks it should like a feature branch for big feature. > @Soby Mathew Could you help to share more information about it? Thanks very much. We usually do not have feature branches in TF-A. The topics/epic_beta0_spmd is a prototyping branch where we wanted to share code with collaborators outside TF-A. The patches on this branch are not visible in gerrit review and no patches in gerrit review will be merged to this branch. Once the prototyping is complete, then patches on this branch will be reworked and pushed to gerrit review and finally get merged to integration and this branch will be deleted. Our experience have been, long running development branches are generally a maintenance overhead. Merging these development branches before a release may also be risky as some of the changes may have unknown interactions and may become difficult to resolve. The "topic" in gerrit review is effectively a branch. For example, this review: https://review.trustedfirmware.org/#/q/topic:od/debugfs+(status:open+OR+sta… is a set of patches on topic "od/debugfs" and can be treated as development branch. This branch is alive as long as patches are not merged. We need to understand the motivations for the change. Broken CI is an argument but development branches will only exacerbate that problem since we don't know the stability of each of those branches. Also merge conflict will not reduce due to development branches. Its just delaying the merge conflict to a later point. There may be other reasons, but generally it is better to merge sensible patches (+2ed) within a feature even before the feature is complete as it will reduce merge conflicts (we have to ensure testing/build coverage for the patch). These are my thoughts on this. Best Regards Soby Mathew -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 2 months

1
0
0 0

PSA_Panic () - proposal to implement as macro

by Reinhard Keil

I propose to implement PSA_Panic () as a macro (like the classic C assert feature) and not as a plain C function. The benefit is that the macro allows you to insert also information like __FILE__ and __LINE__ which helps during the development phase of projects (i.e. when TF-M is incorrectly used by the non-secure side. __FILE__ and __LINE__ is useful also when no source code is available (at the debug stage) as it allows support to provide hints for the root cause of the issue. You may have different variants of the PSA_Panic macro, i.e. a debug and release version. Reinhard 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, 2 months

1
0
0 0

The logging mechanism change in TF-M

by Reinhard Keil

Ken, Today there are multiple different implementation of event logging used in the industry, but in a nutshell all use a similar concept. You may start reading http://www.keil.com/pack/doc/compiler/EventRecorder/html/er_overview.html which is the implementation used currently in MDK. It uses a buffer that is read by the debugger. The buffer size is configurable and a faster debugger requires typically smaller buffer sizes. Also it introduces an XML file that describes the messages - and this description is used also by other tools like Percepio. You may remap the annotation hooks also to classic printf. So overall the concept gives you more flexibility and introducing it at a later stage into a project usually creates legacy effects. For example we had in MDK middleware initially printf type annotations and introduced later events. As users are reluctant to change technology during the project lifecycle we end up to maintain both the old printf and the new event recorder annotations. This could have been avoided by using the right (flexible) concept from the beginning. Reinhard 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, 2 months

1
0
0 0

Re: [TF-M] Create another branch for feature development

by Edison Ai

Hi, Let's continue to discuss this topic. I agree with this, the CI is just a tool, we should not only rely on it. Thanks Gyorgy to point out the quality policy, we need to think about them when we discuss the version control. In the current status, there is only one master branch for most of the development work in TF-M. Of course, we can add a warning to say that the master is constantly changing, there may be some problems in building or test running, and let the user use the release tag. But it is not convenience and impossible if they are upstreaming patches. And even to TF-M developers, we had met several times of the master branch is broken. There is another way maybe help to solve this problem, we can define a merge policy like this: The patches cannot be merged to master branch if the patch is not based on the TOP HEAD. But this is very difficult to follow because there may be several maintainers could and need to merged patches at the same time. They need to align with each other to confirm their patches are on the TOP. But now, we often meet this case, while one patch rebases to TOP and waiting for the CI result, another patch is merged into master. The patch needs to rebase again. I do not want to give more examples here. Of course, it is a big change to involve a new branch, there must be many documents that need to be updated, and some policies need to be changed. And even this needs someone to maintain the alignment with 2 branches. But I think it is more useful and helpful for all users. Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: Friday, December 13, 2019 10:01 PM To: Minos Galanakis <Minos.Galanakis(a)arm.com>; Soby Mathew <Soby.Mathew(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Create another branch for feature development Hi, Hi, I agree, the CI shall not dictate how we use the version control system. It shall adapt. Regarding your suggestions, I think the main problem is we are mixing stuff, this time quality with version control. Before we make decisions we shall understand where we are. The current quality policy is that we only make releases for communication purposes. To give a clean interface for tf-m users and to allow planning their work. Releases allow them to execute their tf-m integration process less frequently. Only for each release or specific releases and not for each commit. The current quality policy identifies a single quality level only, and says any patch we publish is "golden quality", it matches the highest quality standard we can achieve (with sane constraints). Also to make our life easy we decided to use the master branch to hold these patches. At the same time we use the master branch for development. Any change we make is made against master. This means each pull request and thus each review targets master. For review purposes the best is to have a chain of small modifications, otherwise the review content becomes too large to follow. The TF-A "branching strategy" tries to address this issue by introducing an integration branch used for development. This allows master to be more release specific. I suggest to take the following approach (details to be discussed): - introduce more quality levels i.e.: - none: content of a topic branch, or content pushed to review. - bronze: content passed code review and patch specific testing. - silver: content passed a more though daily testing. - gold: a release. A pack of source-code, feature state document (release notes), reviewed documentation (user manual, reference manual), test evidence, documentation of test efforts to allow repeatability. The version control system can be used to store content, and to provide identification info (i.e. tagging), but most likely the release will need other kind of storage to be used (i.e. documentation). - platina: reaching extra quality level trough passing PSA or some FUSA qualification. Or we may simply use extra release for this. Naming the quality levels allows us to have a cleaner definition of what can be expected at a specific level (set of quality measures, i.e. static analysis, code review, test configuration). It would also allow us cleaner communication and to find how we use the version system for quality purposes. I also expect this discussion to help defining how the version system is used for development purposes. The current state works ok, but is a sort of naturally grown. We might have reached the point when more pragmatic approach may be needed. /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Minos Galanakis via TF-M Sent: 13 December 2019 12:23 To: Edison Ai (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org>; Soby Mathew <Soby.Mathew(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Create another branch for feature development Hi all. My personal comments on this. I would like to point out that the CI is a tool, not the core project. I do not believe we should be changing our development strategy based on what the tool is doing. We should instead adjust the tool to fit our requirements. * No patches should be/ are merged to master when CI fails. If master breaks it should most commonly be because of something we are not testing for. Using an integration branch would not change that. * As a developer I find it more convoluted to work with projects who use different integration strategies. The most common assumption in open source projects is that you have a master branch which is the bleeding edge, but can contain untested bugs, and the release immutable git tags for versioning. Using branch merges as versioning is a design for the pull request model which is not quite compatible with Gerrit. * Most of the CI downtime has nothing to do with the merge strategy, they are more of a chicken and the egg philosophical problem. If your patch or branch introduced a change which affects the tests outputs, how will you test it if the CI expects the old output? An integration branch would not solve the merge freeze periods, would just affect a different branch from master. * I believe feature branches are quite useful, since changes to master do not disrupt the development flow of a big change, and even though they will require some maintenance to re-sync before the final patch , it will be handled by an engineer who knows the feature, and full understands the regression vectors. If I were to suggest some changes for stability purposes, I would start smaller: * Update documentation to instruct users to check out from release tags, warning then that master is constantly changing. * Adjust the CI to detect an Allow-CI flag from every branch. That way developers can test any patch from any feature branch. The logic for that is already present in the code, but requires Gerrit to be configured accordingly. * Add an undo process. This would be the only case for an integration branch. All patches are merged to a temporary branch, after confirming they have passed testing individually. On the once per day nightly test, the group of different patches, will be tested against an extensive job, in models and hardware, and only if successful it will fast forward master to that state. Regards Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Edison Ai (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 13 December 2019 08:55 To: Soby Mathew <Soby.Mathew(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] Create another branch for feature development Hi Soby, Thanks for your detail description. > Integration is a temporary merge branch to merge several patches and run the CI against. Usually once CI passes, the master will be fast forwarded to integration within a day. > This helps us to test integration of patches and detect any failure before master is updated. This means the master will pass CI at any given merge point. I think it's a good method like this so that we can double confirm the "master" branch is stable. And this also can fix one case even the CI can work normally: one patch is ready to merge, and it is not based on the latest HEAD, but there is no conflict. We can merge the patch directly and let gerrit do rebase by itself. But we cannot confirm the CI test can pass. Any comment for this from others? For multiple feature branches, I think we can stop to discuss about it now until we have some strong demands for it. It is indeed a big change for us now. Thanks, Edison -----Original Message----- From: Soby Mathew <Soby.Mathew(a)arm.com> Sent: Friday, December 13, 2019 5:14 AM To: Edison Ai (Arm Technology China) <Edison.Ai(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] Create another branch for feature development On 11/12/2019 09:05, Edison Ai (Arm Technology China) via TF-M wrote: > Hi Gyorgy, > > Thanks to point it out. I agree with you that it will be better if we can align these two projects in this. I had a quick check the branches from TF-A: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/. > There are three branches in TF-A: > - "integration" branch, should be used for new features. > - "master" branch, which is behind of "integration" branch. But I am nor sure what is the strategy to update it. Hi Edison, Integration is a temporary merge branch to merge several patches and run the CI against. Usually once CI passes, the master will be fast forwarded to integration within a day. This helps us to test integration of patches and detect any failure before master is updated. This means the master will pass CI at any given merge point. > - "topics/epic_beta0_spmd", I thinks it should like a feature branch for big feature. > @Soby Mathew Could you help to share more information about it? Thanks very much. We usually do not have feature branches in TF-A. The topics/epic_beta0_spmd is a prototyping branch where we wanted to share code with collaborators outside TF-A. The patches on this branch are not visible in gerrit review and no patches in gerrit review will be merged to this branch. Once the prototyping is complete, then patches on this branch will be reworked and pushed to gerrit review and finally get merged to integration and this branch will be deleted. Our experience have been, long running development branches are generally a maintenance overhead. Merging these development branches before a release may also be risky as some of the changes may have unknown interactions and may become difficult to resolve. The "topic" in gerrit review is effectively a branch. For example, this review: https://review.trustedfirmware.org/#/q/topic:od/debugfs+(status:open+OR+sta… is a set of patches on topic "od/debugfs" and can be treated as development branch. This branch is alive as long as patches are not merged. We need to understand the motivations for the change. Broken CI is an argument but development branches will only exacerbate that problem since we don't know the stability of each of those branches. Also merge conflict will not reduce due to development branches. Its just delaying the merge conflict to a later point. There may be other reasons, but generally it is better to merge sensible patches (+2ed) within a feature even before the feature is complete as it will reduce merge conflicts (we have to ensure testing/build coverage for the patch). These are my thoughts on this. Best Regards Soby Mathew -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 2 months

1
0
0 0

Re: [TF-M] [Request For Comments] apply "-fno-builtin" as default compiler flags

by Thomas Törnblom

Hi Tamas, IAR provides C libraries in various configurations, depending on optimization levels, target types, needed features. Normally the linker selects the appropriate libraries depending on target, optimization, semihosting etc, but it can be told to not do that, in case there is a need to provide non-standard libraries. Cheers, /Thomas Den 2020-01-09 kl. 09:41, skrev Tamas Ban via TF-M: > > Hi Thomas, > > Just for my understanding: > > * Does IAR provide a C std. lib as part of IAR toolchain package? > * How the std C lib linked to the image? Does user provide an > explicit flag which std. C lib to linked to the image? > > Tamas > > *From:*TF-M <tf-m-bounces(a)lists.trustedfirmware.org> *On Behalf Of > *Thomas Törnblom via TF-M > *Sent:* 08 January 2020 12:45 > *To:* tf-m(a)lists.trustedfirmware.org > *Subject:* Re: [TF-M] [Request For Comments] apply "-fno-builtin" as > default compiler flags > > The IAR toolchain does not produce any special "builtin" calls and > thus does not have any flag similar to "-fno-builtin". > > /Thomas > > Den 2020-01-08 kl. 03:53, skrev Ken Liu via TF-M: > > Hi, > > ï¿½ > > As TF-M needs runtime APIs so we are creating the Secure Partition > runtime library, code is ready but we have not forwarded all > necessary runtime APIs to the version TF-M implemented, this was > caused by the toolchain optimization for built-in APIs, such as: > > ï¿½ > > - Forward printf(%s) to puts if there is only one string parameter. > > - ARMCLANG would forward memxxx API into an optimized variant. > > ï¿½ > > With the '-fno-builtin' flags set in the toolchain, this > optimization would be disabled so that user just implement the > same name built-in to replace the toolchain version. > > ï¿½ > > Please help to check these point before applying '-fno-builtin' > and provide your feedback: > > ï¿½ > > - Could toolchains out of ARMCLANG and GNUARM have a similar flag? > > - Would it affect your project setting and how does it affect? > > ï¿½ > > Please help to feedback. I will keep this thread open for ~1 week > and let's get a conclusion after this. > > ï¿½ > > Thanks! > > ï¿½ > > /Ken > > > > -- > > *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> > > 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. > -- *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, 2 months

1
0
0 0

TF-M Technical Forum call - January 23

by Anton Komlev

Dear All, The next session of the Technical Forum is planned in 2 weeks, Thursday, January 23rd at 7:00-8:00 UTC. Please treat this email and an early invitation for agenda topic collection. Any questions, proposals, concerns are all valid points for our open discussion so do not hesitate to share it. A big or complicated topics are worth to preliminary discussed over a mailing list. Best regards, Anton Komlev

6 years, 2 months

1
0
0 0

Re: [TF-M] Code Protection between secure services

by Ken Liu

Hi, I assume the main purpose of isolation would be protect the code been seen by the AppRoT. Let's check with the FF author for detailed answers. The building instructions now is just create separate libraries and finally combine them together - since vendors can create Secure Partitions, these modularized building can't be avoided. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: Thursday, January 9, 2020 4:00 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Code Protection between secure services I suggest we review the requirement of code isolation on the secure side. R/W data and R/O data should definitely be isolated, but code isolation has implications: * Code cannot be share between services (i.e. no linker optimization to reduce memory footprint) * Sharing library code * Overall the build instructions of the system are more complicated * Adding device specific driver code (i.e. to crypto) can become tricky Reinhard 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, 2 months

1
0
0 0

Re: [TF-M] [Request For Comments] apply "-fno-builtin" as default compiler flags

by Tamas Ban

Hi Thomas, Just for my understanding: * Does IAR provide a C std. lib as part of IAR toolchain package? * How the std C lib linked to the image? Does user provide an explicit flag which std. C lib to linked to the image? Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 08 January 2020 12:45 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] [Request For Comments] apply "-fno-builtin" as default compiler flags The IAR toolchain does not produce any special "builtin" calls and thus does not have any flag similar to "-fno-builtin". /Thomas Den 2020-01-08 kl. 03:53, skrev Ken Liu via TF-M: Hi, ï¿½ As TF-M needs runtime APIs so we are creating the Secure Partition runtime library, code is ready but we have not forwarded all necessary runtime APIs to the version TF-M implemented, this was caused by the toolchain optimization for built-in APIs, such as: ï¿½ - Forward printf(%s) to puts if there is only one string parameter. - ARMCLANG would forward memxxx API into an optimized variant. ï¿½ With the '-fno-builtin' flags set in the toolchain, this optimization would be disabled so that user just implement the same name built-in to replace the toolchain version. ï¿½ Please help to check these point before applying '-fno-builtin' and provide your feedback: ï¿½ - Could toolchains out of ARMCLANG and GNUARM have a similar flag? - Would it affect your project setting and how does it affect? ï¿½ Please help to feedback. I will keep this thread open for ~1 week and let's get a conclusion after this. ï¿½ Thanks! ï¿½ /Ken -- 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> 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, 2 months

1
0
0 0

Re: [TF-M] The logging mechanism change in TF-M

by Ken Liu

Hi, We have a prototype audit logging service and one of the purposes is to provide the event logging. The reason we keep printf first is that it is so direct and some projects reference it, for example, booting or services. Eventually, we need can investigate the possibility of forwarding all printf into event logging. One question is that there needs to be a buffer for collecting the events so it has limited capacity? /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: Thursday, January 9, 2020 3:42 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] The logging mechanism change in TF-M I recommend instead of using printf with plain text strings, to change the concept to event annotations. This is already implemented in several RTOS systems (i.e. FreeRTOS or RTX). Event annotations give you more flexibility: * can be mapped to memory buffer, printf output, or analysers like Event Recorder in MDK or Percepio * annotations are described in XML file using event groups. Can be mapped to test automation systems and reduce overhead * no direct mapping to a peripheral. UART may be not available on all systems. * overall less overhead in the system (as printf is expensive). Can remain in production code when it just goes to memory buffer Let me know if you want to have further pointers or information. Reinhard 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, 2 months

1
0
0 0

Code Protection between secure services

by Reinhard Keil

I suggest we review the requirement of code isolation on the secure side. R/W data and R/O data should definitely be isolated, but code isolation has implications: * Code cannot be share between services (i.e. no linker optimization to reduce memory footprint) * Sharing library code * Overall the build instructions of the system are more complicated * Adding device specific driver code (i.e. to crypto) can become tricky Reinhard 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, 2 months

1
0
0 0

The logging mechanism change in TF-M

by Reinhard Keil

I recommend instead of using printf with plain text strings, to change the concept to event annotations. This is already implemented in several RTOS systems (i.e. FreeRTOS or RTX). Event annotations give you more flexibility: * can be mapped to memory buffer, printf output, or analysers like Event Recorder in MDK or Percepio * annotations are described in XML file using event groups. Can be mapped to test automation systems and reduce overhead * no direct mapping to a peripheral. UART may be not available on all systems. * overall less overhead in the system (as printf is expensive). Can remain in production code when it just goes to memory buffer Let me know if you want to have further pointers or information. Reinhard 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, 2 months

1
0
0 0

Re: [TF-M] [Call for cygwin volunteers] Remove the mbed-crypto building workaround

by Ken Liu

Got 3 feedbacks till now all reports no problem. I am going to merge this one before end of today. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Monday, January 6, 2020 1:56 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [Call for cygwin volunteers] Remove the mbed-crypto building workaround Thanks for the feedback, let me take a note. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Qixiang Xu via TF-M Sent: Monday, January 6, 2020 1:49 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] [Call for cygwin volunteers] Remove the mbed-crypto building workaround Ken, I have cherry picked the patch and tested it on Cygwin: $ cmake --version cmake version 3.11.1 CMake suite maintained and supported by Kitware (kitware.com/cmake). The patch works and no issue found. Best Regards, Qixiang Xu 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: Monday, January 6, 2020 11:00 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: [TF-M] [Call for cygwin volunteers] Remove the mbed-crypto building workaround Hi, I create a patch for removing the workaround for mbed-crypto building: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3022 We tried on cmake 3.7 and 3.10 with cygwin and it works; can some Cygwin/mingw user pick this patch and test if it could work in your side? Thanks for your contribution 😊 /Ken 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, 2 months

1
0
0 0

Re: [TF-M] [Request For Comments] apply "-fno-builtin" as default compiler flags

by Ken Liu

Thanks Thomas, then IAR won't be a difficult part for this. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Wednesday, January 8, 2020 7:45 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] [Request For Comments] apply "-fno-builtin" as default compiler flags The IAR toolchain does not produce any special "builtin" calls and thus does not have any flag similar to "-fno-builtin". /Thomas Den 2020-01-08 kl. 03:53, skrev Ken Liu via TF-M: Hi, ï¿½ As TF-M needs runtime APIs so we are creating the Secure Partition runtime library, code is ready but we have not forwarded all necessary runtime APIs to the version TF-M implemented, this was caused by the toolchain optimization for built-in APIs, such as: ï¿½ - Forward printf(%s) to puts if there is only one string parameter. - ARMCLANG would forward memxxx API into an optimized variant. ï¿½ With the '-fno-builtin' flags set in the toolchain, this optimization would be disabled so that user just implement the same name built-in to replace the toolchain version. ï¿½ Please help to check these point before applying '-fno-builtin' and provide your feedback: ï¿½ - Could toolchains out of ARMCLANG and GNUARM have a similar flag? - Would it affect your project setting and how does it affect? ï¿½ Please help to feedback. I will keep this thread open for ~1 week and let's get a conclusion after this. ï¿½ Thanks! ï¿½ /Ken -- 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, 2 months

1
0
0 0

Re: [TF-M] [Request For Comments] apply "-fno-builtin" as default compiler flags

by Thomas Törnblom

The IAR toolchain does not produce any special "builtin" calls and thus does not have any flag similar to "-fno-builtin". /Thomas Den 2020-01-08 kl. 03:53, skrev Ken Liu via TF-M: > > Hi, > > As TF-M needs runtime APIs so we are creating the Secure Partition > runtime library, code is ready but we have not forwarded all necessary > runtime APIs to the version TF-M implemented, this was caused by the > toolchain optimization for built-in APIs, such as: > > - Forward printf(%s) to puts if there is only one string parameter. > > - ARMCLANG would forward memxxx API into an optimized variant. > > With the '-fno-builtin' flags set in the toolchain, this optimization > would be disabled so that user just implement the same name built-in > to replace the toolchain version. > > Please help to check these point before applying '-fno-builtin' and > provide your feedback: > > - Could toolchains out of ARMCLANG and GNUARM have a similar flag? > > - Would it affect your project setting and how does it affect? > > Please help to feedback. I will keep this thread open for ~1 week and > let's get a conclusion after this. > > Thanks! > > /Ken > > -- *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, 2 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - January 9

by Anton Komlev

Hi All, Thanks, Ken and Edison for offering the topics for tomorrow's Tech forum. The agenda (always open) starts from: 1. Secure Partition Runtime Library 2. PSA FF 1.0.0 alignment Best regards, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai via TF-M Sent: 07 January 2020 08:19 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 Technical Forum call - January 9 Hi Anton, I will share something about the PSA FF 1.0.0 alignment. About 10 - 15 minutes. Thanks, Edison 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 7, 2020 3:33 PM 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] TF-M Technical Forum call - January 9 Hi Anton, I can share the status of Secure Partition Runtime Library in the tech forum. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: Tuesday, January 7, 2020 1:56 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: [TF-M] TF-M Technical Forum call - January 9 Hello, Hope that the new year is truly happy for everybody. The next session of the Technical Forum is planned on the coming Thursday, January 9th. Regarding the time, I think that the last session was a good compromise to suit majority of the participants so propose to keep the time slot at 7:00-8:00 UTC. This time suits members in Europe and Asia, although participants from US (specially from the East coast) might have inconveniences. Reminding that the recorded sessions and materials are available on the web site: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Please reply to this email to post your topics for the agenda. Any questions, proposals, concerns are all valid points for our open discussion so do not hesitate to share it. Best regards, Anton Komlev

6 years, 2 months

1
0
0 0

[Request For Comments] apply "-fno-builtin" as default compiler flags

by Ken Liu

Hi, As TF-M needs runtime APIs so we are creating the Secure Partition runtime library, code is ready but we have not forwarded all necessary runtime APIs to the version TF-M implemented, this was caused by the toolchain optimization for built-in APIs, such as: - Forward printf(%s) to puts if there is only one string parameter. - ARMCLANG would forward memxxx API into an optimized variant. With the '-fno-builtin' flags set in the toolchain, this optimization would be disabled so that user just implement the same name built-in to replace the toolchain version. Please help to check these point before applying '-fno-builtin' and provide your feedback: - Could toolchains out of ARMCLANG and GNUARM have a similar flag? - Would it affect your project setting and how does it affect? Please help to feedback. I will keep this thread open for ~1 week and let's get a conclusion after this. Thanks! /Ken

6 years, 2 months

1
0
0 0

Re: [TF-M] The logging mechanism change in TF-M

by Soby Mathew

On 07/01/2020 01:23, Ken Liu via TF-M wrote: > Hi Soby, > > Thanks for providing the reference - we have investigated the version in TF-A earlier, the difference part is we are facing the problem about how to flush the formatted data into device - TF-A has full control to the device so it could just output_char() but the secure partition cannot do this due to some driver sharing consideration. We can reference the TF-A implementation after the logging device mechanism is settled down. > > One question, the ARM Complier built-in would change printf to puts or some other variants in RVCT like __2printf, I searched TF-A sources found there is no '--fbulit-in' or 'no_scanlib' flags for the compiler but looks like TF-A has not met the scenarios TF-M met? Or...the runtime library mechanism for A and M are different? > > /Ken Hi Ken, The TF-A uses -fno-builtin compiler flag. Hence it doesn't face this problem. If the goal is to not to pull in compiler builtin libraries, setting this flag would be the right approach. The TF-M source tree would need to provide libc. Best Regards Soby Mathew

6 years, 2 months

2
1
0 0

Last call for reviewing TIMER IRQ naming

by Alamy Liu

Hi all, Please help to review the patch, and it would be merged soon if there is no other comment https://review.trustedfirmware.org/c/trusted-firmware-m/+/2687 Best Regards, Alamy

6 years, 2 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - January 9

by Edison Ai

Hi Anton, I will share something about the PSA FF 1.0.0 alignment. About 10 - 15 minutes. Thanks, Edison From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Tuesday, January 7, 2020 3:33 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M Technical Forum call - January 9 Hi Anton, I can share the status of Secure Partition Runtime Library in the tech forum. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: Tuesday, January 7, 2020 1:56 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: [TF-M] TF-M Technical Forum call - January 9 Hello, Hope that the new year is truly happy for everybody. The next session of the Technical Forum is planned on the coming Thursday, January 9th. Regarding the time, I think that the last session was a good compromise to suit majority of the participants so propose to keep the time slot at 7:00-8:00 UTC. This time suits members in Europe and Asia, although participants from US (specially from the East coast) might have inconveniences. Reminding that the recorded sessions and materials are available on the web site: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Please reply to this email to post your topics for the agenda. Any questions, proposals, concerns are all valid points for our open discussion so do not hesitate to share it. Best regards, Anton Komlev

6 years, 2 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - January 9

by Ken Liu

Hi Anton, I can share the status of Secure Partition Runtime Library in the tech forum. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Tuesday, January 7, 2020 1:56 AM To: TF-M(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - January 9 Hello, Hope that the new year is truly happy for everybody. The next session of the Technical Forum is planned on the coming Thursday, January 9th. Regarding the time, I think that the last session was a good compromise to suit majority of the participants so propose to keep the time slot at 7:00-8:00 UTC. This time suits members in Europe and Asia, although participants from US (specially from the East coast) might have inconveniences. Reminding that the recorded sessions and materials are available on the web site: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Please reply to this email to post your topics for the agenda. Any questions, proposals, concerns are all valid points for our open discussion so do not hesitate to share it. Best regards, Anton Komlev

6 years, 2 months

1
0
0 0

Re: [TF-M] The logging mechanism change in TF-M

by Ken Liu

Hi Soby, Thanks for providing the reference - we have investigated the version in TF-A earlier, the difference part is we are facing the problem about how to flush the formatted data into device - TF-A has full control to the device so it could just output_char() but the secure partition cannot do this due to some driver sharing consideration. We can reference the TF-A implementation after the logging device mechanism is settled down. One question, the ARM Complier built-in would change printf to puts or some other variants in RVCT like __2printf, I searched TF-A sources found there is no '--fbulit-in' or 'no_scanlib' flags for the compiler but looks like TF-A has not met the scenarios TF-M met? Or...the runtime library mechanism for A and M are different? /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby Mathew via TF-M Sent: Monday, January 6, 2020 9:35 PM To: Anton Komlev <Anton.Komlev(a)arm.com>; TF-M(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] The logging mechanism change in TF-M On 06/01/2020 11:45, Anton Komlev via TF-M wrote: > Hi Ken, All, > > I like your approach of providing a minimalistic version of printf() > for the logging purpose only. > > This would benefit to code size and performance while rich print > formatting has no practical needs in this project. > > Best regards, > > Anton > > *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org> *On Behalf Of > *Ken Liu via TF-M > *Sent:* 27 December 2019 03:38 > *To:* tf-m(a)lists.trustedfirmware.org > *Cc:* nd <nd(a)arm.com> > *Subject:* [TF-M] The logging mechanism change in TF-M > > Hi, > > We met some issues while implementing logging APIs like printf: > > * The build-in symbol optimization references other toolchain provided > symbols into image (like change ‘printf’ to ‘puts’ or ‘xxxprintf’), > this would happen in both we are implementing your ‘printf’ and > referencing toolchain ‘printf’. Use a -fno-builtin would suppress > this but this needs a compiler flag requirement for developers. > * If we don’t provide necessary symbol but somewhere in program > referenced it, ARMCLANG would provide one for us which contains the > semihosting things, this increases the code size and cause trouble > while the device is not running under semihosting env. > * Also there are CMSIS user reports that __stdout would affect > multiple thread object initialization. (No detail about the root > cause, anyone could help provide something?) > > So it would be better that we remove the reference to toolchain stdout > APIs, this could simplify the logging implementation since firmware > logging MAY not need rich format (Comments?). A customized printf-like > API is provided for logging but not being named as ‘printf’ directly. > > Due to the default logging device (UART) driver may be implemented for > threads only, the logging functionality in exceptions is going to be > suppressed for a while until we figure out how the logging in > exceptions can be – there is a trade-off between security > consideration (isolation) and performance (Routing the logging API to somewhere costs). > > Please provide your thinking, or what kind of logging API you are using. > > Thanks > > /Ken > The TF-A code base provides a reduced printf() functionality due to similar concerns and to reduce stack/memory usage https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/lib/libc/p… Also be aware that mbedTLS requires snprintf() so if printf() is being custom implemented, then it makes sense to do the same to snprintf() as well. Best Regards Soby Mathew -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 2 months

1
0
0 0

Updated invitation: TF-M Tech Forum @ Thu 9 Jan 2020 07:00 - 08:00 (GMT) (tf-m@lists.trustedfirmware.org)

by bill.fletcher＠linaro.org

This event has been changed. 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.Due to expected attendees from Asia, Europe and the Americas, the timeslot is challenging. We hope it's not too difficult for anyone - we can review after the first couple of meetings.Initially we propose a bi-weekly call and then we'll change cadence depending on interest Feel free to forward it to colleagues.──────────Bill 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 9 Jan 2020 07:00 – 08:00 United Kingdom Time Where: https://zoom.us/j/5810428000 Calendar: tf-m(a)lists.trustedfirmware.org Who: (Guest list has been hidden at organiser's request) Event details: https://www.google.com/calendar/event?action=VIEW&eid=NTZtNXZwM3BsaGltanJkb… 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, 2 months

1
0
0 0

Invitation: TF-M Tech Forum @ Thu 9 Jan 2020 07:00 - 08:00 (GMT) (tf-m@lists.trustedfirmware.org)

by bill.fletcher＠linaro.org

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.Due to expected attendees from Asia, Europe and the Americas, the timeslot is challenging. We hope it's not too difficult for anyone - we can review after the first couple of meetings.Initially we propose a bi-weekly call and then we'll change cadence depending on interest Feel free to forward it to colleagues.──────────Bill 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 9 Jan 2020 07:00 – 08:00 United Kingdom Time Where: https://zoom.us/j/5810428000 Joining info: Join Hangouts Meet https://meet.google.com/xdb-txmc-xje Or dial: +44 20 3956 3237 (PIN:: 515715720) More phone numbers: https://tel.meet/xdb-txmc-xje?pin=7033981256503&hs=0 Calendar: tf-m(a)lists.trustedfirmware.org Who: (Guest list has been hidden at organiser's request) Event details: https://www.google.com/calendar/event?action=VIEW&eid=NTZtNXZwM3BsaGltanJkb… 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, 2 months

1
0
0 0

TF-M Technical Forum call - January 9

by Anton Komlev

Hello, Hope that the new year is truly happy for everybody. The next session of the Technical Forum is planned on the coming Thursday, January 9th. Regarding the time, I think that the last session was a good compromise to suit majority of the participants so propose to keep the time slot at 7:00-8:00 UTC. This time suits members in Europe and Asia, although participants from US (specially from the East coast) might have inconveniences. Reminding that the recorded sessions and materials are available on the web site: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Please reply to this email to post your topics for the agenda. Any questions, proposals, concerns are all valid points for our open discussion so do not hesitate to share it. Best regards, Anton Komlev

6 years, 2 months

1
0
0 0

Re: [TF-M] irq handling in library mode

by Andrew Thoelke

> Just a question: For Isolation Level 1, the hardware features of v8-M should be sufficient to implement interrupts natively. Is this correct understanding or did I miss anything? This is essentially correct. As this is outside of the PSA-FF at present, TF-M would need to design and document how to integrate such IRQ handlers with its interrupt management framework, and how the interrupt handler can interact with the secure service code. For example, this might be achieved by resuming a SFC call that is waiting for a hardware operation to complete or delivering a signal to an IPC mode Secure Partition. 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, 2 months

1
0
0 0

Re: [TF-M] The logging mechanism change in TF-M

by Soby Mathew

On 06/01/2020 11:45, Anton Komlev via TF-M wrote: > Hi Ken, All, > > I like your approach of providing a minimalistic version of printf() for > the logging purpose only. > > This would benefit to code size and performance while rich print > formatting has no practical needs in this project. > > Best regards, > > Anton > > *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org> *On Behalf Of *Ken > Liu via TF-M > *Sent:* 27 December 2019 03:38 > *To:* tf-m(a)lists.trustedfirmware.org > *Cc:* nd <nd(a)arm.com> > *Subject:* [TF-M] The logging mechanism change in TF-M > > Hi, > > We met some issues while implementing logging APIs like printf: > > * The build-in symbol optimization references other toolchain provided > symbols into image (like change ‘printf’ to ‘puts’ or ‘xxxprintf’), > this would happen in both we are implementing your ‘printf’ and > referencing toolchain ‘printf’. Use a -fno-builtin would suppress > this but this needs a compiler flag requirement for developers. > * If we don’t provide necessary symbol but somewhere in program > referenced it, ARMCLANG would provide one for us which contains the > semihosting things, this increases the code size and cause trouble > while the device is not running under semihosting env. > * Also there are CMSIS user reports that __stdout would affect > multiple thread object initialization. (No detail about the root > cause, anyone could help provide something?) > > So it would be better that we remove the reference to toolchain stdout > APIs, this could simplify the logging implementation since firmware > logging MAY not need rich format (Comments?). A customized printf-like > API is provided for logging but not being named as ‘printf’ directly. > > Due to the default logging device (UART) driver may be implemented for > threads only, the logging functionality in exceptions is going to be > suppressed for a while until we figure out how the logging in exceptions > can be – there is a trade-off between security consideration (isolation) > and performance (Routing the logging API to somewhere costs). > > Please provide your thinking, or what kind of logging API you are using. > > Thanks > > /Ken > The TF-A code base provides a reduced printf() functionality due to similar concerns and to reduce stack/memory usage https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/lib/libc/p… Also be aware that mbedTLS requires snprintf() so if printf() is being custom implemented, then it makes sense to do the same to snprintf() as well. Best Regards Soby Mathew

6 years, 2 months

1
0
0 0

Re: [TF-M] The logging mechanism change in TF-M

by Anton Komlev

Hi Ken, All, I like your approach of providing a minimalistic version of printf() for the logging purpose only. This would benefit to code size and performance while rich print formatting has no practical needs in this project. Best regards, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 27 December 2019 03:38 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] The logging mechanism change in TF-M Hi, We met some issues while implementing logging APIs like printf: * The build-in symbol optimization references other toolchain provided symbols into image (like change 'printf' to 'puts' or 'xxxprintf'), this would happen in both we are implementing your 'printf' and referencing toolchain 'printf'. Use a -fno-builtin would suppress this but this needs a compiler flag requirement for developers. * If we don't provide necessary symbol but somewhere in program referenced it, ARMCLANG would provide one for us which contains the semihosting things, this increases the code size and cause trouble while the device is not running under semihosting env. * Also there are CMSIS user reports that __stdout would affect multiple thread object initialization. (No detail about the root cause, anyone could help provide something?) So it would be better that we remove the reference to toolchain stdout APIs, this could simplify the logging implementation since firmware logging MAY not need rich format (Comments?). A customized printf-like API is provided for logging but not being named as 'printf' directly. Due to the default logging device (UART) driver may be implemented for threads only, the logging functionality in exceptions is going to be suppressed for a while until we figure out how the logging in exceptions can be - there is a trade-off between security consideration (isolation) and performance (Routing the logging API to somewhere costs). Please provide your thinking, or what kind of logging API you are using. Thanks /Ken

6 years, 2 months

1
0
0 0

Re: [TF-M] System reset SPM HAL function

by Edison Ai

This patch will add a new system reset function for SPM without using the existing platform_hal_system_reset(). The basic thinking is to create a dedicated HAL function for SPM to split with services, and not affect the secure partition work. I am not sure if this will bring some problems or any potential risk for platform porting. Please give feedback about this in this mail thread. Thanks, Edison From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai via TF-M Sent: Monday, December 30, 2019 3:43 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] System reset SPM HAL function Hi All, To align with PSA FF 1.0.0, the SPM needs to restart the entire system when some programmer error or panics are detected. So I had upstream a patch to add a system reset HAL function for SPM: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2780/. The basic idea is to add a weak common function so that the platform can use this weak function to do reset. Please note, the platform needs to add its own implementation if there is any different. Unfortunately, there is no such test to test the system reset function curreetly. So please call psa_panic() in secure services for simple testing based on the top of this link: https://review.trustedfirmware.org/#/q/topic:tfm_panic+(status:open+OR+stat…. You can send mail or add comments directly in patches if you have any questions or comments. Thanks, Edison

6 years, 2 months

1
0
0 0

Secure Partition runtime library prototype is available

by Ken Liu

Hi, After couples of patches get merged, the Secure Partition runtime library prototype is available. The purpose of this library (aka SPRTL) is to provide a place for shared functions between secure partitions under isolation level 2/3 which could avoid duplicated code symbols in Secure Partitions. The situation is: - There is a folder for SPE dedicated function implementation: 'secure_fw/lib/sprt'. More APIs can be put in SPRTL by modifying the makefiles under this folder. - Keep using toolchain provided 'memset/memcpy' due to inherit them is a bit complicated (of course these toolchain symbols are put in the shared region to avoid duplication). And we keep the customized candidate in source code for further investigation to see if we need this customized version or the default version. - Overriding toolchain 'memcmp' into a customized version to show security consideration. - Implemented a customized 'tfm_log_printf' to replace 'printf', which could avoid involving complicated STDIO mechanism into the code base. - PSA FF APIs are now in it. These changes are now working under the code base, some other functions are not available yet and to be done later due to no actual requirement for them, such as: - Heap APIs, now crypto uses its own implemented heap while other services do not need them. - RoT Service APIs, would request service owner to move the existing RoT Service APIs into SPRTL (should be just some function attribute change, let's check it). Any feedbacks or issue reporting is welcome, please reply in the mailing list or create an issue at developer.trustedfirmware.org and assign to 'KenLSoft'. BR and thanks. /Ken

6 years, 2 months

1
0
0 0

Re: [TF-M] [Call for cygwin volunteers] Remove the mbed-crypto building workaround

by Ken Liu

Thanks for the feedback, let me take a note. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Qixiang Xu via TF-M Sent: Monday, January 6, 2020 1:49 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] [Call for cygwin volunteers] Remove the mbed-crypto building workaround Ken, I have cherry picked the patch and tested it on Cygwin: $ cmake --version cmake version 3.11.1 CMake suite maintained and supported by Kitware (kitware.com/cmake). The patch works and no issue found. Best Regards, Qixiang Xu 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: Monday, January 6, 2020 11:00 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: [TF-M] [Call for cygwin volunteers] Remove the mbed-crypto building workaround Hi, I create a patch for removing the workaround for mbed-crypto building: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3022 We tried on cmake 3.7 and 3.10 with cygwin and it works; can some Cygwin/mingw user pick this patch and test if it could work in your side? Thanks for your contribution 😊 /Ken 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, 2 months

1
0
0 0

Re: [TF-M] [Call for cygwin volunteers] Remove the mbed-crypto building workaround

by Qixiang Xu

Ken, I have cherry picked the patch and tested it on Cygwin: $ cmake --version cmake version 3.11.1 CMake suite maintained and supported by Kitware (kitware.com/cmake). The patch works and no issue found. Best Regards, Qixiang Xu From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Monday, January 6, 2020 11:00 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [Call for cygwin volunteers] Remove the mbed-crypto building workaround Hi, I create a patch for removing the workaround for mbed-crypto building: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3022 We tried on cmake 3.7 and 3.10 with cygwin and it works; can some Cygwin/mingw user pick this patch and test if it could work in your side? Thanks for your contribution 😊 /Ken 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, 2 months

1
0
0 0

[Call for cygwin volunteers] Remove the mbed-crypto building workaround

by Ken Liu

Hi, I create a patch for removing the workaround for mbed-crypto building: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3022 We tried on cmake 3.7 and 3.10 with cygwin and it works; can some Cygwin/mingw user pick this patch and test if it could work in your side? Thanks for your contribution 😊 /Ken

6 years, 2 months

1
0
0 0

Re: [TF-M] irq handling in library mode

by Reinhard Keil

Hi Andrew, Thanks for the reply and the confirmation of the flexibility of the PSA-FF Just a question: For Isolation Level 1, the hardware features of v8-M should be sufficient to implement interrupts natively. Is this correct understanding or did I miss anything? Reinhard 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, 2 months

1
0
0 0

[RFC] TF-M core updates

by Ken Liu

Hi TF-Mers, Happy new year! Till now, the core has evolved much and keep evolving. Let's take a breath before we go further, some updates are on the table and wait for comments. Most of the core changes will not affect the usage, but there do have interface related parts needs to be mentioned. Here are the overall topics for comments: - SPM/core sources renaming and changes, I think this part won't affect user much except those who copied sources into your own project and do the integration. - The HAL design is on the way, this part do affect the existing platform integration, please take apart in the discussions for this topic (The design would come first). - Some interface sources changing. Those PSA APIs won't be changed, but the folder name and place may be updated so you may need to change your project setting. We also got some new features, the design would go first and they would be merged after the update is done (Ideally ;)). Such as interrupt logic/test publish. These changes are trying to make the platform integration easier, so your feedback is important before these changes take place. And, it also makes the contribution to core logic easier. If you find something is missing, feel free to propose it here and we can discuss how much we could cover. The detailed topics would be sent one by one (avoid makes everyone too busy). Please put comments ;) Thanks /Ken

6 years, 2 months

1
0
0 0

Re: [TF-M] Initialize IPC SPM in handler mode

by Ken Liu

Almost miss the link 😉 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2964 /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Monday, December 30, 2019 6:45 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Initialize IPC SPM in handler mode Hi, The existing SPM initialization is done in thread mode with PSP, because library model needs to enumerate the partition initialization function in thread mode. And IPC SPM re-uses the code so it is get initialized in this mode, too. For IPC SPM, it needs to initial thread context and push the initial EXC_RETURN context in each thread’s stack, and the veneer thread (which belongs to non-secure partition instance) re-uses the stack of initial thread mode. This may cause problem since SPM is manipulating the stack it is now standing on. It does not cause problem now is because SPM initialization is working at the low end of stack pointer while the thread context is written at high end stack bottom, and SPM initialization would not return to thread, it just enters PendSV and then go away. So SPM must work under MSP to avoid touching his standing place – and, the used part of initial thread stack needs to be clean up, for security issues. Now we can’t find a better way to clean both the used PSP stack and the MSP stack, unless we clear the PSP manually while working with MSP, and do a EXC_RETURN from handler mode to reset the MSP stack usage by hardware. The patches is on the way for this purpose – and follows the patches of jumping to ns without cmse call – cmse call consumes secure stack during the calling while we want a known stack position to identify the caller frames in handler mode. Patches would come later (I am testing if it could on different platforms). Thanks. /Ken

6 years, 2 months

1
0
0 0

Initialize IPC SPM in handler mode

by Ken Liu

Hi, The existing SPM initialization is done in thread mode with PSP, because library model needs to enumerate the partition initialization function in thread mode. And IPC SPM re-uses the code so it is get initialized in this mode, too. For IPC SPM, it needs to initial thread context and push the initial EXC_RETURN context in each thread's stack, and the veneer thread (which belongs to non-secure partition instance) re-uses the stack of initial thread mode. This may cause problem since SPM is manipulating the stack it is now standing on. It does not cause problem now is because SPM initialization is working at the low end of stack pointer while the thread context is written at high end stack bottom, and SPM initialization would not return to thread, it just enters PendSV and then go away. So SPM must work under MSP to avoid touching his standing place - and, the used part of initial thread stack needs to be clean up, for security issues. Now we can't find a better way to clean both the used PSP stack and the MSP stack, unless we clear the PSP manually while working with MSP, and do a EXC_RETURN from handler mode to reset the MSP stack usage by hardware. The patches is on the way for this purpose - and follows the patches of jumping to ns without cmse call - cmse call consumes secure stack during the calling while we want a known stack position to identify the caller frames in handler mode. Patches would come later (I am testing if it could on different platforms). Thanks. /Ken

6 years, 2 months

1
0
0 0

System reset SPM HAL function

by Edison Ai

Hi All, To align with PSA FF 1.0.0, the SPM needs to restart the entire system when some programmer error or panics are detected. So I had upstream a patch to add a system reset HAL function for SPM: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2780/. The basic idea is to add a weak common function so that the platform can use this weak function to do reset. Please note, the platform needs to add its own implementation if there is any different. Unfortunately, there is no such test to test the system reset function curreetly. So please call psa_panic() in secure services for simple testing based on the top of this link: https://review.trustedfirmware.org/#/q/topic:tfm_panic+(status:open+OR+stat…. You can send mail or add comments directly in patches if you have any questions or comments. Thanks, Edison

6 years, 2 months

1
0
0 0

The logging mechanism change in TF-M

by Ken Liu

Hi, We met some issues while implementing logging APIs like printf: * The build-in symbol optimization references other toolchain provided symbols into image (like change 'printf' to 'puts' or 'xxxprintf'), this would happen in both we are implementing your 'printf' and referencing toolchain 'printf'. Use a -fno-builtin would suppress this but this needs a compiler flag requirement for developers. * If we don't provide necessary symbol but somewhere in program referenced it, ARMCLANG would provide one for us which contains the semihosting things, this increases the code size and cause trouble while the device is not running under semihosting env. * Also there are CMSIS user reports that __stdout would affect multiple thread object initialization. (No detail about the root cause, anyone could help provide something?) So it would be better that we remove the reference to toolchain stdout APIs, this could simplify the logging implementation since firmware logging MAY not need rich format (Comments?). A customized printf-like API is provided for logging but not being named as 'printf' directly. Due to the default logging device (UART) driver may be implemented for threads only, the logging functionality in exceptions is going to be suppressed for a while until we figure out how the logging in exceptions can be - there is a trade-off between security consideration (isolation) and performance (Routing the logging API to somewhere costs). Please provide your thinking, or what kind of logging API you are using. Thanks /Ken

6 years, 2 months

1
0
0 0

Re: [TF-M] [RFC] Code restructure of core/spm

by Ken Liu

Hi, I want to arise this topic again - some patches are blocked due to feature implementation but I think now it is a good chance since staging tag has been done. Will notify you with the patches - don't worry, it is just about some file rename in core/spm folder so if your patch does not rely on these folders a simple rebase should work for your patch. /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Thursday, August 29, 2019 4:49 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Code restructure of core/spm Two more patches added under this topic: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1836 https://review.trustedfirmware.org/c/trusted-firmware-m/+/1837 BR /Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > Liu (Arm Technology China) via TF-M > Sent: Thursday, August 15, 2019 3:15 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [RFC] Code restructure of core/spm > > Hi, > The first patch for moving header files is ready at: > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1561 > Comments are welcome. I had thought to push patches together but looks > like it would block other patches for a while to show a neat merged > list, so I would push them one by one. > > Will keep you update when incoming patches are ready. > > BR > > /Ken > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > > Liu (Arm Technology China) via TF-M > > Sent: Thursday, August 1, 2019 11:12 AM > > To: tf-m(a)lists.trustedfirmware.org > > Cc: nd <nd(a)arm.com> > > Subject: [TF-M] [RFC] Code restructure of core/spm > > > > Hi, > > > > Several patches for code restructure is coming. Before I post the > > gerrit items, I want to collect your feedback on this. These changes contain: > > > > - Move header files into dedicated directory for easy include, and > > clean the included headers in sources; > > - Change some files' name to let them make more sense. > > - Move SPM related files into 'spm' folder instead of putting them in 'core'. > > - Move some interface files into 'ns_callable' since they are interfaces. > > - Remove 'ipc' folder after all files in it are well arranged. > > > > I will try to do these patches together so they can be merged together. > > But before that I want to request for comments about this, feel free > > to reply in this thread or comment on the task (add yourself if you > > are missing as > > subscribers): > > https://developer.trustedfirmware.org/T426 > > > > BR > > > > /Ken > > > > > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 2 months

1
0
0 0

Re: [TF-M] irq handling in library mode

by Andrew Thoelke

Hi Reinhard & Ken, There are definitely some challenging trade-offs, and the right approach can depend on the system and use case. PSA Firmware Framework is a architectural interface design for deployment on different CPU/SoC designs, and defines an interrupt framework that: 1. can be implemented on these different architectures 2. is aligned with the security & isolation principles of the Framework PSA-FF does not stop an implementation (such as TF-M) from providing additional interrupt frameworks that provide lower-latency for some components. These will obviously be non-portable (to other PSA-FF implementations) and may have security trade-offs if the ISR runs in a privileged secure state to achieve performance requirements. As you suggest, although it is possible to discuss the options in general - it is only possible to make good design decisions with real use cases for integrating hardware devices into the secure side of the system, and the required behaviour of the interrupt handlers. There is a substantial evidence that weakening the isolation requirements is not typically balanced by keeping the critical code simple, reviewed and secure - based on the experience of TrustZone and other TEE software implementations. I agree that such careful code development is possible, but it is not normal (at the moment). Regards, Andrew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: 18 December 2019 13:49 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] irq handling in library mode Ken, thanks for the reply. My take on that is that instead of adding overhead to ISR, ISR should be executed fast. For ISRs we should publish clear guidelines that explain potential side effects of ISR execution. These guidelines should advocate that ISR is kept short, and workload is off-loaded to thread execution. How this is exactly done in secure side needs to be defined, as the RTOS (on non-secure side) might inconsistent and not be available. What would be really good is to have typical ISR routines that execute in secure side. This would better allow us to judge what is really needed. I believe most of them are small anyway. Reinhard 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, 2 months

1
0
0 0

Re: [TF-M] irq handling in library mode

by Edison Ai

Hi Matt, Sorry not to review your patch as soon as possible because you forget adding me to the reviewer list😊 I had reviewed it now. By the way, there is a contributing process in TF-M which require to create a related ‘task’ for task management. I had helped to create one for this issue. Please help to create it the next time. I can help you if you have any problems with it. For more detail, you can refer to this:https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/proce…, Hi All, Here is the patch link: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2923. Please help to review it Thanks, Edison From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Matt via TF-M Sent: Friday, December 20, 2019 12:49 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] irq handling in library mode Hi Edison, If it is a bug, I will upsteam a patch to fix it later. Thanks, Matt

6 years, 2 months

1
0
0 0

IRQ: use defined name from platform

by Alamy Liu

Hi all, There are new platforms (cypress/psoc64/ & sse-200_aws), and I update the patch to includes the two new platforms. Please help on reviewing. https://review.trustedfirmware.org/c/trusted-firmware-m/+/2687/ Thanks, Alamy

6 years, 2 months

1
0
0 0

19th December TF-M Technical Forum call - slides and video

by Bill Fletcher

These are now available at: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Regards Bill -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

6 years, 3 months

1
0
0 0

User guide doc about how to add a Secure Partition

by Edison Ai

Hi all, There are many people had asked that is there a user guide document about how to add a Secure Partition in TF-M? Now, here is it: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2921/. Please help to review it.😊 Thanks, Edison

6 years, 3 months

1
0
0 0

Re: [TF-M] irq handling in library mode

by Matt

Hi Edison, If it is a bug, I will upsteam a patch to fix it later. Thanks, Matt At 2019-12-19 16:43:18, "Edison Ai via TF-M" <tf-m(a)lists.trustedfirmware.org> wrote: Hi Matt, Sorry not got your point in the first time. Yes, you are right. It is indeed a bug here. And thanks for your detail explaining and good example. Can you upstream a patch to fix it? Thanks, Edison From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of lg via TF-M Sent: Wednesday, December 18, 2019 9:54 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] irq handling in library mode Hi Edison, Thanks for your reply. In file tfm_secure_irq_handling.rst, we can know every SP have a continuous irq related stack as follows, | interrupted_ctx_stack_frame_t | | handler_ctx_stack_frame_t | | interrupted_ctx_stack_frame_t | | ... | | handler_ctx_stack_frame_t | | interrupted_ctx_stack_frame_t | And this stack pointer is saved in the field ctx_stack_ptr of structure spm_partition_runtime_data_t for each partition. If partition A is interrupted for the first time by a lower priority interrupt, as current code shown bellow, the interrupted_ctx_stack_frame_t will be pushed at the beginning of the irq stack. void tfm_spm_partition_push_interrupted_ctx(uint32_t partition_idx) { struct spm_partition_runtime_data_t *runtime_data = &g_spm_partition_db.partitions[partition_idx].runtime_data; struct interrupted_ctx_stack_frame_t *stack_frame = (struct interrupted_ctx_stack_frame_t *)runtime_data->ctx_stack_ptr; stack_frame->partition_state = runtime_data->partition_state; } Now the stack is show as below, | interrupted_ctx_stack_frame_t (used) | | handler_ctx_stack_frame_t | | interrupted_ctx_stack_frame_t | | ... | | handler_ctx_stack_frame_t | | interrupted_ctx_stack_frame_t | But the stack pointer is not moved upper after pushing interrupted_ctx_stack_frame_t, so the ctx_stack_ptr is still point to the beginning of the stack. At this time,if a higher priority interrupt of partition A is coming, partition A becomes handler partition, so the structure handler_ctx_stack_frame_t should be pushed in the stack of partition A, as current code shown below, void tfm_spm_partition_push_handler_ctx(uint32_t partition_idx) { struct spm_partition_runtime_data_t *runtime_data = &g_spm_partition_db.partitions[partition_idx].runtime_data; struct handler_ctx_stack_frame_t *stack_frame = (struct handler_ctx_stack_frame_t *) runtime_data->ctx_stack_ptr; stack_frame->partition_state = runtime_data->partition_state; stack_frame->caller_partition_idx = runtime_data->caller_partition_idx; runtime_data->ctx_stack_ptr += sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t); } As it shown above, the content of handler_ctx_stack_frame_t will be overlapped with already pushed content of interrupted_ctx_stack_frame_t. My question is exactly about the above scenario. If the stack pointer is also moved upper after pushing the interrupted_ctx_stack_frame_t, handler_ctx_stack_frame_t will be pushed at different location in the stack as follows, | interrupted_ctx_stack_frame_t (used) | | handler_ctx_stack_frame_t (used) | | interrupted_ctx_stack_frame_t | | ... | | handler_ctx_stack_frame_t | | interrupted_ctx_stack_frame_t | Please read the file tfm_secure_irq_handling.rst again , and help to check about this question. Thanks, Matt At 2019-12-17 14:22:13, "Edison Ai \$Arm Technology China\$ via TF-M" <tf-m(a)lists.trustedfirmware.org> wrote: Hi Matt, Thanks for your email. Let me try to answer your question because of the designer of the TF-M interrupt handling is on leave now. First, you are right about this: “If the interrupted partition is the same as the handler partition, interrupted_ctx_stack_frame_t and handler_ctx_stack_frame_t should be pushed at different location.” Let’s start from an example, there are 3 SPs with different interrupt priority, SP1 < SP2 < SP3. And there is one scenario like this: SP1 is running, SP2 interrupt SP1. Current, the interrupted partition is SP1, and the handler partition is SP2. As the below code show in tfm_spm_partition_push_handler_ctx(), the stack pointer will be moved upper as below: | SP2 stack pointer -à | | | | Caller_partition_indx(handler) | | | Partition_sate(handler) | SP2 starts to run, and it is interrupted by SP3. Current, the interrupted partition is SP2, and the handler partition is SP3. As the code shown in tfm_spm_partition_push_interrupted_ctx(), it uses the current stack member directly without moving its pointer. | SP2 stack pointer -à | Partition_state(interrupted) | | | Caller_partition_indx(handler) | | | Partition_sate(handler) | And after SP2 is interrupted by SP3, its partition status will be changed to “SPM_PARTITION_STATE_SUSPENDED”. So that this partition will not be interrupted by others anymore unless it comes back to running state. Which means it does not need more stack anymore. We can consider that after one SP is interrupted by others, there is no more stack is needed for it before it comes back to running status. So I think it should be ok in the current design for the interrupt in the library model. I am not sure if this can solve your confuse. Please feel free to give feedback. We can discuss more about it. Thanks, Edison From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of lg via TF-M Sent: Monday, December 16, 2019 1:08 PM To:tf-m@lists.trustedfirmware.org Subject: [TF-M] irq handling in library mode Hi TFM experts, I have a question about the code logic of irq handling in library mode, code blocks in spm_api_func.c are as follows: void tfm_spm_partition_push_interrupted_ctx(uint32_t partition_idx) { struct spm_partition_runtime_data_t *runtime_data = &g_spm_partition_db.partitions[partition_idx].runtime_data; struct interrupted_ctx_stack_frame_t *stack_frame = (struct interrupted_ctx_stack_frame_t *)runtime_data->ctx_stack_ptr; stack_frame->partition_state = runtime_data->partition_state; } void tfm_spm_partition_push_handler_ctx(uint32_t partition_idx) { struct spm_partition_runtime_data_t *runtime_data = &g_spm_partition_db.partitions[partition_idx].runtime_data; struct handler_ctx_stack_frame_t *stack_frame = (struct handler_ctx_stack_frame_t *) runtime_data->ctx_stack_ptr; stack_frame->partition_state = runtime_data->partition_state; stack_frame->caller_partition_idx = runtime_data->caller_partition_idx; runtime_data->ctx_stack_ptr += sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t); } My question is why there is not the following such code logic at the end of function tfm_spm_partition_push_interrupted_ctx. runtime_data->ctx_stack_ptr += sizeof(struct interrupted_ctx_stack_frame_t ) / sizeof(uint32_t); If the interrupted partition is the same as the handler partition, interrupted_ctx_stack_frame_t and handler_ctx_stack_frame_t should be pushed at different location. And when pop the stack frame after handling irq, there is the following code logic in tfm_spm_partition_pop_handler_ctx runtime_data->ctx_stack_ptr -= sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t); I think the same logic of changing ctx_stack_ptr should be added the begining of the function tfm_spm_partition_pop_interrupted_ctx like the above code logic in tfm_spm_partition_pop_handler_ctx. runtime_data->ctx_stack_ptr -= sizeof(struct interrupted_ctx_stack_frame_t ) / sizeof(uint32_t); Please help to check. Thanks, Matt

6 years, 3 months

1
0
0 0

New blog post: Trusted Firmware at Lyon.

by Augustina Adjei

Hello, We have a new blog post detailing TF-M in Lyon here: https://www.trustedfirmware.org/blog/trusted_firmware_at_lyon/ Thank you, Augustina Adjei [cid:image001.jpg@01D5B688.34C152B0] Mawuelome - Seyram Augustina Adjei Central Engineering - Open Source Software Group augustina.adjei(a)arm.com 110 Fulbourn Road, Cambridge, CB1 9NJ www.arm.com<http://www.arm.com/> 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, 3 months

1
0
0 0

Trusted Firmware-M CI-Trigger Behavior change notification

by Minos Galanakis

Hi all, The triggering behavior of the Trusted Firmware-M CI has been adjusted. Tests jobs will no longer trigger automatically. Instead when the patch submitter would like their code to be tested, they will need to assert the newly introduced `Allow-CI` Gerrit voting flag. Regards Minos

6 years, 3 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - 19th December

by Anton Komlev

Because of New Year holidays, the next forum is planned on Jan 9, 2020. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang via TF-M Sent: 19 December 2019 02:37 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M Technical Forum call - 19th December Update the Agenda: (added TF-M profile session) - The interrupts' topic was followed by email and looks like closed. Are there remaining points for discussion? - TF-M and Amazon FreeRTOS integration update - [RFC] TF-M Profile - Cryptocell integration Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Friday, December 13, 2019 2:14 AM To: TF-M(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - 19th December Hello, To continuing our open discussion, started a week ago let me propose the 2nd session and create this mail thread to discuss related topics. 1. The time slot. Looking on participants' distribution [Asia:6, Europe:20, US East:1, US Cent:1, US West:4, Total:32] I see the majority is in Europe. The Asian region could be more presented giving a more comfortable time. Having this in mind, I would propose to have the 2nd session on Dec 19 at 7:00 UTC time. This compromise gives US West coast a chance to join at 23:00 (Dec 18!). Here is the summary: https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=… Please share your thoughts and alternatives. The related question: shall we fix the time or rotating? You can play with the time slot here: https://www.timeanddate.com/worldclock/meetingtime.html?day=19&month=12&yea… 2. Agenda as a proposal - The interrupts' topic was followed by email and looks like closed. Are there remaining points for discussion? - TF-M and Amazon FreeRTOS integration update - Cryptocell integration - ? Best regards, Anton Komlev -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Re: [TF-M] irq handling in library mode

by Edison Ai

Hi Matt, Sorry not got your point in the first time. Yes, you are right. It is indeed a bug here. And thanks for your detail explaining and good example. Can you upstream a patch to fix it? Thanks, Edison From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of lg via TF-M Sent: Wednesday, December 18, 2019 9:54 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] irq handling in library mode Hi Edison, Thanks for your reply. In file tfm_secure_irq_handling.rst, we can know every SP have a continuous irq related stack as follows, interrupted_ctx_stack_frame_t handler_ctx_stack_frame_t interrupted_ctx_stack_frame_t ... handler_ctx_stack_frame_t interrupted_ctx_stack_frame_t And this stack pointer is saved in the field ctx_stack_ptr of structure spm_partition_runtime_data_t for each partition. If partition A is interrupted for the first time by a lower priority interrupt, as current code shown bellow, the interrupted_ctx_stack_frame_t will be pushed at the beginning of the irq stack. void tfm_spm_partition_push_interrupted_ctx(uint32_t partition_idx) { struct spm_partition_runtime_data_t *runtime_data = &g_spm_partition_db.partitions[partition_idx].runtime_data; struct interrupted_ctx_stack_frame_t *stack_frame = (struct interrupted_ctx_stack_frame_t *)runtime_data->ctx_stack_ptr; stack_frame->partition_state = runtime_data->partition_state; } Now the stack is show as below, interrupted_ctx_stack_frame_t (used) handler_ctx_stack_frame_t interrupted_ctx_stack_frame_t ... handler_ctx_stack_frame_t interrupted_ctx_stack_frame_t But the stack pointer is not moved upper after pushing interrupted_ctx_stack_frame_t, so the ctx_stack_ptr is still point to the beginning of the stack. At this time,if a higher priority interrupt of partition A is coming, partition A becomes handler partition, so the structure handler_ctx_stack_frame_t should be pushed in the stack of partition A, as current code shown below, void tfm_spm_partition_push_handler_ctx(uint32_t partition_idx) { struct spm_partition_runtime_data_t *runtime_data = &g_spm_partition_db.partitions[partition_idx].runtime_data; struct handler_ctx_stack_frame_t *stack_frame = (struct handler_ctx_stack_frame_t *) runtime_data->ctx_stack_ptr; stack_frame->partition_state = runtime_data->partition_state; stack_frame->caller_partition_idx = runtime_data->caller_partition_idx; runtime_data->ctx_stack_ptr += sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t); } As it shown above, the content of handler_ctx_stack_frame_t will be overlapped with already pushed content of interrupted_ctx_stack_frame_t. My question is exactly about the above scenario. If the stack pointer is also moved upper after pushing the interrupted_ctx_stack_frame_t, handler_ctx_stack_frame_t will be pushed at different location in the stack as follows, interrupted_ctx_stack_frame_t (used) handler_ctx_stack_frame_t (used) interrupted_ctx_stack_frame_t ... handler_ctx_stack_frame_t interrupted_ctx_stack_frame_t Please read the file tfm_secure_irq_handling.rst again , and help to check about this question. Thanks, Matt At 2019-12-17 14:22:13, "Edison Ai \$Arm<file://(Arm> Technology China\$ via TF-M" <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: Hi Matt, Thanks for your email. Let me try to answer your question because of the designer of the TF-M interrupt handling is on leave now. First, you are right about this: "If the interrupted partition is the same as the handler partition, interrupted_ctx_stack_frame_t and handler_ctx_stack_frame_t should be pushed at different location." Let's start from an example, there are 3 SPs with different interrupt priority, SP1 < SP2 < SP3. And there is one scenario like this: * SP1 is running, SP2 interrupt SP1. Current, the interrupted partition is SP1, and the handler partition is SP2. As the below code show in tfm_spm_partition_push_handler_ctx(), the stack pointer will be moved upper as below: SP2 stack pointer ---> Caller_partition_indx(handler) Partition_sate(handler) * SP2 starts to run, and it is interrupted by SP3. Current, the interrupted partition is SP2, and the handler partition is SP3. As the code shown in tfm_spm_partition_push_interrupted_ctx(), it uses the current stack member directly without moving its pointer. SP2 stack pointer ---> Partition_state(interrupted) Caller_partition_indx(handler) Partition_sate(handler) And after SP2 is interrupted by SP3, its partition status will be changed to "SPM_PARTITION_STATE_SUSPENDED". So that this partition will not be interrupted by others anymore unless it comes back to running state. Which means it does not need more stack anymore. We can consider that after one SP is interrupted by others, there is no more stack is needed for it before it comes back to running status. So I think it should be ok in the current design for the interrupt in the library model. I am not sure if this can solve your confuse. Please feel free to give feedback. We can discuss more about it. Thanks, Edison From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of lg via TF-M Sent: Monday, December 16, 2019 1:08 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] irq handling in library mode Hi TFM experts, I have a question about the code logic of irq handling in library mode, code blocks in spm_api_func.c are as follows: void tfm_spm_partition_push_interrupted_ctx(uint32_t partition_idx) { struct spm_partition_runtime_data_t *runtime_data = &g_spm_partition_db.partitions[partition_idx].runtime_data; struct interrupted_ctx_stack_frame_t *stack_frame = (struct interrupted_ctx_stack_frame_t *)runtime_data->ctx_stack_ptr; stack_frame->partition_state = runtime_data->partition_state; } void tfm_spm_partition_push_handler_ctx(uint32_t partition_idx) { struct spm_partition_runtime_data_t *runtime_data = &g_spm_partition_db.partitions[partition_idx].runtime_data; struct handler_ctx_stack_frame_t *stack_frame = (struct handler_ctx_stack_frame_t *) runtime_data->ctx_stack_ptr; stack_frame->partition_state = runtime_data->partition_state; stack_frame->caller_partition_idx = runtime_data->caller_partition_idx; runtime_data->ctx_stack_ptr += sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t); } My question is why there is not the following such code logic at the end of function tfm_spm_partition_push_interrupted_ctx. runtime_data->ctx_stack_ptr += sizeof(struct interrupted_ctx_stack_frame_t ) / sizeof(uint32_t); If the interrupted partition is the same as the handler partition, interrupted_ctx_stack_frame_t and handler_ctx_stack_frame_t should be pushed at different location. And when pop the stack frame after handling irq, there is the following code logic in tfm_spm_partition_pop_handler_ctx runtime_data->ctx_stack_ptr -= sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t); I think the same logic of changing ctx_stack_ptr should be added the begining of the function tfm_spm_partition_pop_interrupted_ctx like the above code logic in tfm_spm_partition_pop_handler_ctx. runtime_data->ctx_stack_ptr -= sizeof(struct interrupted_ctx_stack_frame_t ) / sizeof(uint32_t); Please help to check. Thanks, Matt

6 years, 3 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - 19th December

by David Wang

Update the Agenda: (added TF-M profile session) - The interrupts' topic was followed by email and looks like closed. Are there remaining points for discussion? - TF-M and Amazon FreeRTOS integration update - [RFC] TF-M Profile - Cryptocell integration Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Friday, December 13, 2019 2:14 AM To: TF-M(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - 19th December Hello, To continuing our open discussion, started a week ago let me propose the 2nd session and create this mail thread to discuss related topics. 1. The time slot. Looking on participants' distribution [Asia:6, Europe:20, US East:1, US Cent:1, US West:4, Total:32] I see the majority is in Europe. The Asian region could be more presented giving a more comfortable time. Having this in mind, I would propose to have the 2nd session on Dec 19 at 7:00 UTC time. This compromise gives US West coast a chance to join at 23:00 (Dec 18!). Here is the summary: https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=… Please share your thoughts and alternatives. The related question: shall we fix the time or rotating? You can play with the time slot here: https://www.timeanddate.com/worldclock/meetingtime.html?day=19&month=12&yea… 2. Agenda as a proposal - The interrupts' topic was followed by email and looks like closed. Are there remaining points for discussion? - TF-M and Amazon FreeRTOS integration update - Cryptocell integration - ? Best regards, Anton Komlev -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Re: [TF-M] irq handling in library mode

by lg

Hi Edison, Thanks for your reply. In file tfm_secure_irq_handling.rst, we can know every SP have a continuous irq related stack as follows, | interrupted_ctx_stack_frame_t | | handler_ctx_stack_frame_t | | interrupted_ctx_stack_frame_t | | ... | | handler_ctx_stack_frame_t | | interrupted_ctx_stack_frame_t | And this stack pointer is saved in the field ctx_stack_ptr of structure spm_partition_runtime_data_t for each partition. If partition A is interrupted for the first time by a lower priority interrupt, as current code shown bellow, the interrupted_ctx_stack_frame_t will be pushed at the beginning of the irq stack. void tfm_spm_partition_push_interrupted_ctx(uint32_t partition_idx) { struct spm_partition_runtime_data_t *runtime_data = &g_spm_partition_db.partitions[partition_idx].runtime_data; struct interrupted_ctx_stack_frame_t *stack_frame = (struct interrupted_ctx_stack_frame_t *)runtime_data->ctx_stack_ptr; stack_frame->partition_state = runtime_data->partition_state; } Now the stack is show as below, | interrupted_ctx_stack_frame_t (used) | | handler_ctx_stack_frame_t | | interrupted_ctx_stack_frame_t | | ... | | handler_ctx_stack_frame_t | | interrupted_ctx_stack_frame_t | But the stack pointer is not moved upper after pushing interrupted_ctx_stack_frame_t, so the ctx_stack_ptr is still point to the beginning of the stack. At this time,if a higher priority interrupt of partition A is coming, partition A becomes handler partition, so the structure handler_ctx_stack_frame_t should be pushed in the stack of partition A, as current code shown below, void tfm_spm_partition_push_handler_ctx(uint32_t partition_idx) { struct spm_partition_runtime_data_t *runtime_data = &g_spm_partition_db.partitions[partition_idx].runtime_data; struct handler_ctx_stack_frame_t *stack_frame = (struct handler_ctx_stack_frame_t *) runtime_data->ctx_stack_ptr; stack_frame->partition_state = runtime_data->partition_state; stack_frame->caller_partition_idx = runtime_data->caller_partition_idx; runtime_data->ctx_stack_ptr += sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t); } As it shown above, the content of handler_ctx_stack_frame_t will be overlapped with already pushed content of interrupted_ctx_stack_frame_t. My question is exactly about the above scenario. If the stack pointer is also moved upper after pushing the interrupted_ctx_stack_frame_t, handler_ctx_stack_frame_t will be pushed at different location in the stack as follows, | interrupted_ctx_stack_frame_t (used) | | handler_ctx_stack_frame_t (used) | | interrupted_ctx_stack_frame_t | | ... | | handler_ctx_stack_frame_t | | interrupted_ctx_stack_frame_t | Please read the file tfm_secure_irq_handling.rst again , and help to check about this question. Thanks, Matt At 2019-12-17 14:22:13, "Edison Ai \$Arm Technology China\$ via TF-M" <tf-m(a)lists.trustedfirmware.org> wrote: Hi Matt, Thanks for your email. Let me try to answer your question because of the designer of the TF-M interrupt handling is on leave now. First, you are right about this: “If the interrupted partition is the same as the handler partition, interrupted_ctx_stack_frame_t and handler_ctx_stack_frame_t should be pushed at different location.” Let’s start from an example, there are 3 SPs with different interrupt priority, SP1 < SP2 < SP3. And there is one scenario like this: SP1 is running, SP2 interrupt SP1. Current, the interrupted partition is SP1, and the handler partition is SP2. As the below code show in tfm_spm_partition_push_handler_ctx(), the stack pointer will be moved upper as below: | SP2 stack pointer -à | | | | Caller_partition_indx(handler) | | | Partition_sate(handler) | SP2 starts to run, and it is interrupted by SP3. Current, the interrupted partition is SP2, and the handler partition is SP3. As the code shown in tfm_spm_partition_push_interrupted_ctx(), it uses the current stack member directly without moving its pointer. | SP2 stack pointer -à | Partition_state(interrupted) | | | Caller_partition_indx(handler) | | | Partition_sate(handler) | And after SP2 is interrupted by SP3, its partition status will be changed to “SPM_PARTITION_STATE_SUSPENDED”. So that this partition will not be interrupted by others anymore unless it comes back to running state. Which means it does not need more stack anymore. We can consider that after one SP is interrupted by others, there is no more stack is needed for it before it comes back to running status. So I think it should be ok in the current design for the interrupt in the library model. I am not sure if this can solve your confuse. Please feel free to give feedback. We can discuss more about it. Thanks, Edison From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of lg via TF-M Sent: Monday, December 16, 2019 1:08 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] irq handling in library mode Hi TFM experts, I have a question about the code logic of irq handling in library mode, code blocks in spm_api_func.c are as follows: void tfm_spm_partition_push_interrupted_ctx(uint32_t partition_idx) { struct spm_partition_runtime_data_t *runtime_data = &g_spm_partition_db.partitions[partition_idx].runtime_data; struct interrupted_ctx_stack_frame_t *stack_frame = (struct interrupted_ctx_stack_frame_t *)runtime_data->ctx_stack_ptr; stack_frame->partition_state = runtime_data->partition_state; } void tfm_spm_partition_push_handler_ctx(uint32_t partition_idx) { struct spm_partition_runtime_data_t *runtime_data = &g_spm_partition_db.partitions[partition_idx].runtime_data; struct handler_ctx_stack_frame_t *stack_frame = (struct handler_ctx_stack_frame_t *) runtime_data->ctx_stack_ptr; stack_frame->partition_state = runtime_data->partition_state; stack_frame->caller_partition_idx = runtime_data->caller_partition_idx; runtime_data->ctx_stack_ptr += sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t); } My question is why there is not the following such code logic at the end of function tfm_spm_partition_push_interrupted_ctx. runtime_data->ctx_stack_ptr += sizeof(struct interrupted_ctx_stack_frame_t ) / sizeof(uint32_t); If the interrupted partition is the same as the handler partition, interrupted_ctx_stack_frame_t and handler_ctx_stack_frame_t should be pushed at different location. And when pop the stack frame after handling irq, there is the following code logic in tfm_spm_partition_pop_handler_ctx runtime_data->ctx_stack_ptr -= sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t); I think the same logic of changing ctx_stack_ptr should be added the begining of the function tfm_spm_partition_pop_interrupted_ctx like the above code logic in tfm_spm_partition_pop_handler_ctx. runtime_data->ctx_stack_ptr -= sizeof(struct interrupted_ctx_stack_frame_t ) / sizeof(uint32_t); Please help to check. Thanks, Matt

6 years, 3 months

1
0
0 0

irq handling in library mode

by Reinhard Keil

Ken, thanks for the reply. My take on that is that instead of adding overhead to ISR, ISR should be executed fast. For ISRs we should publish clear guidelines that explain potential side effects of ISR execution. These guidelines should advocate that ISR is kept short, and workload is off-loaded to thread execution. How this is exactly done in secure side needs to be defined, as the RTOS (on non-secure side) might inconsistent and not be available. What would be really good is to have typical ISR routines that execute in secure side. This would better allow us to judge what is really needed. I believe most of them are small anyway. Reinhard 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, 3 months

1
0
0 0

Level 2/Level 3 Isolation requires IPC?

by Reinhard Keil

Ken thanks for your answer. So it is up to the PSA Framework team to define the right framework? Reinhard _______________________________________________________________________________ Reinhard Keil | Phone: +49 89 456040-13 | Email: reinhard.keil(a)arm.com<mailto:reinhard.keil@arm.com> | www.keil.com<http://www.keil.com> ARM Germany GmbH | Bretonischer Ring 16 | D-85630 Grasbrunn,Germany Sitz der Gesellschaft: Grasbrunn | Handelsregister: München (HRB 175362) Geschäftsführer: Andrew Smith, 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, 3 months

1
0
0 0

Re: [TF-M] Adding a new test partition to test multi-partition scenarios

by Andrej Butok

We already have about 7 test services/partitions. It's growing. To save resources. Is it possible to combine the test partitions to one or just few? From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Jamie Fox via TF-M Sent: Wednesday, December 18, 2019 12:34 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Adding a new test partition to test multi-partition scenarios Hi all, There's a need to test service features in TF-M involving more than one partition taking certain actions. For example, the ITS service implements access control for assets in storage based on the partition ID of the client, so we want to test the case where one partition attempts to access an asset belonging to another. There is a similar scenario for Crypto involving access control for keys. Previously we have tested the same feature in SST with multiple NS RTOS threads, relying on the NS RTOS to provide distinct client IDs for each, but as NS client identification may not always be available this is not the ideal solution. I am proposing we add a 'Secure Client 2' test partition to act as slave for the Secure Client (1) test partition that executes the secure test suites. The new partition provides a service to call test functions by ID within its execution context and return the resulting status to the caller. The initial implementation is here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2838<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> . For now it is as simple as possible, just provides one API to call functions by ID, no support for passing other arguments, but we can extend when there is a need for more features. Here I have implemented a basic test for ITS access control using the new partition: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2790<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> Kind regards, Jamie

6 years, 3 months

2
1
0 0

Adding a new test partition to test multi-partition scenarios

by Jamie Fox

Hi all, There's a need to test service features in TF-M involving more than one partition taking certain actions. For example, the ITS service implements access control for assets in storage based on the partition ID of the client, so we want to test the case where one partition attempts to access an asset belonging to another. There is a similar scenario for Crypto involving access control for keys. Previously we have tested the same feature in SST with multiple NS RTOS threads, relying on the NS RTOS to provide distinct client IDs for each, but as NS client identification may not always be available this is not the ideal solution. I am proposing we add a 'Secure Client 2' test partition to act as slave for the Secure Client (1) test partition that executes the secure test suites. The new partition provides a service to call test functions by ID within its execution context and return the resulting status to the caller. The initial implementation is here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2838 . For now it is as simple as possible, just provides one API to call functions by ID, no support for passing other arguments, but we can extend when there is a need for more features. Here I have implemented a basic test for ITS access control using the new partition: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2790 Kind regards, Jamie

6 years, 3 months

1
0
0 0

Re: [TF-M] Coding guideline

by Gyorgy Szing

Hi, "... with 80 column while reviewing (not put this into document) ... " FIY our coding standard explicitly requires 80 chars limit for C code. (See: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… ) /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 18 December 2019 02:04 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Coding guideline Hi, For me both 100 or 80 are acceptable for c sources, and no limit for scripts/makefiles. But at current I am trying to limit the core/spm source with 80 column while reviewing (not put this into document) because it works well under default gerrit setting and easies the review. For services, I won't propose specified limits because some of them may be external projects which is hard to be limited. /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: Wednesday, December 18, 2019 12:40 AM To: David Brown <david.brown(a)linaro.org>; Reinhard Keil <Reinhard.Keil(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Coding guideline Hi, One limit we have to regularly face is imposed by the gerrit diff view (i.e: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2560/6/bl2/ext/… ). It might be worth to check how many characters do fit the half of the view on a full-hd monitor with default font size settings in modern browsers (chrome, firefox, etc..). (In my environment the limit seems to be around 100.) Of course unified view may help (i.e. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2560/6/bl2/ext/…), but we should try to avoid limiting UI usage as much as possible. /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Brown via TF-M Sent: 17 December 2019 17:17 To: Reinhard Keil <Reinhard.Keil(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Coding guideline On Tue, Dec 17, 2019 at 08:58:13AM +0000, Reinhard Keil via TF-M wrote: > IMHO a 80-char restriction is irrelevant with today’s screens/editors > – it comes from the teletype time where 80 characters was the natural > limit on CRT or punch card. I do tend to agree to this. I still think it is useful to have a limit, but something like 100 or even 120 makes a lot more sense. However, even though we have bigger screens, it is still useful to have multiple smaller terminal windows rather than just one big one. But, for myself, I tend to always have them at least be 100 characters. David -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

2
1
0 0

Re: [TF-M] Level 2/Level 3 Isolation requires IPC?

by Ken Liu

Hi Reinhard, This is correct at current and needs SFC specification to clarification in future. The existing PSA Firmware Framework proposes a thread based Secure Partition and the IPC manner about how the information is shared between these process. The SFC model (which is a well know model but do not have a specification yet) combines secure services as a library and makes the information-sharing mechanism complicate under isolation level 2/3, which lost the advantage of 'library' model. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: Tuesday, December 17, 2019 4:10 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Level 2/Level 3 Isolation requires IPC? I have heard that Level 2/Level 3 isolation with TF-M requires Inter-Process Communication (IPC) mode. It does not work with Secure Function Call (SFC) mode (aka Library mode). Is it correct, and why does Level2/Level 3 isolation require IPC? Reinhard _______________________________________________________________________________ Reinhard Keil | Phone: +49 89 456040-13 | Email: reinhard.keil(a)arm.com<mailto:reinhard.keil@arm.com> | www.keil.com<http://www.keil.com> ARM Germany GmbH | Bretonischer Ring 16 | D-85630 Grasbrunn,Germany Sitz der Gesellschaft: Grasbrunn | Handelsregister: München (HRB 175362) Geschäftsführer: Andrew Smith, 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, 3 months

1
0
0 0

Re: [TF-M] irq handling in library mode

by Ken Liu

Hi Reinhard, Your approach is good for a RTOS. For secure firmware, we need to: * A secure partition may bind an interrupt in its manifest, which means the interrupt related logic of a secure partition should be inside secure partition's scope. (This is what the library model is doing.) * To avoid affect non-secure RTOS execution, IRQ should be quick and heavy execution can be delay into secure partition thread. (This is what IPC model is doing). This interrupt handling is keeping evolution, we are trying to create a proposal to provide: * Fast ISR execution. * Put non-urgent interrupt related logic into thread. Now we are collecting proposals and your comment is an important input. And I think the DMA part needs to be considerate much as you have mentioned, it may bypass MPU. If anyone is also working on this topic, please send mail in this mailing list or create an issue (developer.trustedfirmware.org). Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: Tuesday, December 17, 2019 4:04 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] irq handling in library mode I would argue that "IRQ handling" should just be standard v8M hardware behaviour for the following rational: * IRQ routines should be short and simple by nature - it is therefore relative easy to fully verify it and ensure that there are no side effects. * IRQ should be therefore executed in handler mode using MSP, no MPU protection, only protection via SAU, PPC, MPC. Another reason of this relaxed approach is the usage of DMA. * DMA is frequently controlled by IRQ * DMA also bypasses MPU, therefore same behaviour as IRQ. Overall this approach ensures simple, fast IRQ execution (sales argument of v8M) and reduces risk software glitches in TF-M Core. What is wrong with that approach? Reinhard _______________________________________________________________________________ Reinhard Keil | Phone: +49 89 456040-13 | Email: reinhard.keil(a)arm.com<mailto:reinhard.keil@arm.com> | www.keil.com<http://www.keil.com> ARM Germany GmbH | Bretonischer Ring 16 | D-85630 Grasbrunn,Germany Sitz der Gesellschaft: Grasbrunn | Handelsregister: München (HRB 175362) Geschäftsführer: Andrew Smith, 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. 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, 3 months

1
0
0 0

Re: [TF-M] Coding guideline

by Ken Liu

Hi, For me both 100 or 80 are acceptable for c sources, and no limit for scripts/makefiles. But at current I am trying to limit the core/spm source with 80 column while reviewing (not put this into document) because it works well under default gerrit setting and easies the review. For services, I won't propose specified limits because some of them may be external projects which is hard to be limited. /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: Wednesday, December 18, 2019 12:40 AM To: David Brown <david.brown(a)linaro.org>; Reinhard Keil <Reinhard.Keil(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Coding guideline Hi, One limit we have to regularly face is imposed by the gerrit diff view (i.e: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2560/6/bl2/ext/… ). It might be worth to check how many characters do fit the half of the view on a full-hd monitor with default font size settings in modern browsers (chrome, firefox, etc..). (In my environment the limit seems to be around 100.) Of course unified view may help (i.e. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2560/6/bl2/ext/…), but we should try to avoid limiting UI usage as much as possible. /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Brown via TF-M Sent: 17 December 2019 17:17 To: Reinhard Keil <Reinhard.Keil(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Coding guideline On Tue, Dec 17, 2019 at 08:58:13AM +0000, Reinhard Keil via TF-M wrote: > IMHO a 80-char restriction is irrelevant with today’s screens/editors > – it comes from the teletype time where 80 characters was the natural > limit on CRT or punch card. I do tend to agree to this. I still think it is useful to have a limit, but something like 100 or even 120 makes a lot more sense. However, even though we have bigger screens, it is still useful to have multiple smaller terminal windows rather than just one big one. But, for myself, I tend to always have them at least be 100 characters. David -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Re: [TF-M] Coding guideline

by Gyorgy Szing

Hi, One limit we have to regularly face is imposed by the gerrit diff view (i.e: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2560/6/bl2/ext/… ). It might be worth to check how many characters do fit the half of the view on a full-hd monitor with default font size settings in modern browsers (chrome, firefox, etc..). (In my environment the limit seems to be around 100.) Of course unified view may help (i.e. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2560/6/bl2/ext/…), but we should try to avoid limiting UI usage as much as possible. /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Brown via TF-M Sent: 17 December 2019 17:17 To: Reinhard Keil <Reinhard.Keil(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Coding guideline On Tue, Dec 17, 2019 at 08:58:13AM +0000, Reinhard Keil via TF-M wrote: > IMHO a 80-char restriction is irrelevant with today’s screens/editors > – it comes from the teletype time where 80 characters was the natural > limit on CRT or punch card. I do tend to agree to this. I still think it is useful to have a limit, but something like 100 or even 120 makes a lot more sense. However, even though we have bigger screens, it is still useful to have multiple smaller terminal windows rather than just one big one. But, for myself, I tend to always have them at least be 100 characters. David -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Re: [TF-M] Coding guideline

by David Brown

On Tue, Dec 17, 2019 at 08:58:13AM +0000, Reinhard Keil via TF-M wrote: > IMHO a 80-char restriction is irrelevant with today’s screens/editors – it > comes from the teletype time where 80 characters was the natural limit on CRT > or punch card. I do tend to agree to this. I still think it is useful to have a limit, but something like 100 or even 120 makes a lot more sense. However, even though we have bigger screens, it is still useful to have multiple smaller terminal windows rather than just one big one. But, for myself, I tend to always have them at least be 100 characters. David

6 years, 3 months

1
0
0 0

T398/T413: Source cleanup and tool integration

by Thomas Törnblom

I have just pushed the latest commits for the source cleanup and IAR integration. https://review.trustedfirmware.org/c/trusted-firmware-m/+/2560 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2831 Please review. Thanks, Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

6 years, 3 months

1
0
0 0

Invitation: TF-M Tech Forum @ Thu 19 Dec 2019 07:00 - 08:00 (GMT) (tf-m@lists.trustedfirmware.org)

by bill.fletcher＠linaro.org

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.Due to expected attendees from Asia, Europe and the Americas, the timeslot is challenging. We hope it's not too difficult for anyone - we can review after the first couple of meetings.Initially we propose a bi-weekly call and then we'll change cadence depending on interest Feel free to forward it to colleagues.──────────Bill 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)+17207072699,,5810428000# US (Denver)Dial by your location +1 646 558 8656 US (New York) +1 720 707 2699 US (Denver) 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 19 Dec 2019 07:00 – 08:00 United Kingdom Time Where: https://zoom.us/j/5810428000 Calendar: tf-m(a)lists.trustedfirmware.org Who: (Guest list has been hidden at organiser's request) Event details: https://www.google.com/calendar/event?action=VIEW&eid=MnVjODY4YmlscGlxbHU2b… 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, 3 months

1
0
0 0

Coding guideline

by Reinhard Keil

Has there been any conclusion on coding guidelines. IMHO a 80-char restriction is irrelevant with today's screens/editors - it comes from the teletype time where 80 characters was the natural limit on CRT or punch card. MISRA in contrast is industry standard and a fundamental requirement in many projects. What is the progress here? Reinhard _______________________________________________________________________________ Reinhard Keil | Phone: +49 89 456040-13 | Email: reinhard.keil(a)arm.com<mailto:reinhard.keil@arm.com> | www.keil.com<http://www.keil.com> ARM Germany GmbH | Bretonischer Ring 16 | D-85630 Grasbrunn,Germany Sitz der Gesellschaft: Grasbrunn | Handelsregister: München (HRB 175362) Geschäftsführer: Andrew Smith, 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, 3 months

1
0
0 0

Level 2/Level 3 Isolation requires IPC?

by Reinhard Keil

I have heard that Level 2/Level 3 isolation with TF-M requires Inter-Process Communication (IPC) mode. It does not work with Secure Function Call (SFC) mode (aka Library mode). Is it correct, and why does Level2/Level 3 isolation require IPC? Reinhard _______________________________________________________________________________ Reinhard Keil | Phone: +49 89 456040-13 | Email: reinhard.keil(a)arm.com<mailto:reinhard.keil@arm.com> | www.keil.com<http://www.keil.com> ARM Germany GmbH | Bretonischer Ring 16 | D-85630 Grasbrunn,Germany Sitz der Gesellschaft: Grasbrunn | Handelsregister: München (HRB 175362) Geschäftsführer: Andrew Smith, 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, 3 months

1
0
0 0

Re: [TF-M] irq handling in library mode

by Reinhard Keil

I would argue that "IRQ handling" should just be standard v8M hardware behaviour for the following rational: * IRQ routines should be short and simple by nature - it is therefore relative easy to fully verify it and ensure that there are no side effects. * IRQ should be therefore executed in handler mode using MSP, no MPU protection, only protection via SAU, PPC, MPC. Another reason of this relaxed approach is the usage of DMA. * DMA is frequently controlled by IRQ * DMA also bypasses MPU, therefore same behaviour as IRQ. Overall this approach ensures simple, fast IRQ execution (sales argument of v8M) and reduces risk software glitches in TF-M Core. What is wrong with that approach? Reinhard _______________________________________________________________________________ Reinhard Keil | Phone: +49 89 456040-13 | Email: reinhard.keil(a)arm.com<mailto:reinhard.keil@arm.com> | www.keil.com<http://www.keil.com> ARM Germany GmbH | Bretonischer Ring 16 | D-85630 Grasbrunn,Germany Sitz der Gesellschaft: Grasbrunn | Handelsregister: München (HRB 175362) Geschäftsführer: Andrew Smith, 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, 3 months

1
0
0 0

Re: [TF-M] Support for optional build for secure partitions and test suites

by Kevin Peng (Arm Technology China)

Hi, I will be collecting for new review comments till this Friday. If there were no new comments, I will get the patches merged after addressing the existing comments. Best Regards, Kevin -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Peng (Arm Technology China) via TF-M Sent: Wednesday, December 11, 2019 11:02 AM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] Support for optional build for secure partitions and test suites Hi, I've made some patches to support optional build for secure partitions and test suites: https://review.trustedfirmware.org/q/topic:%22optional_build_sp_and_tests%2… With this patch set, you can optionally build secure partitions by setting the TFM_PARTITION_XXX in CommonConfig.cmake around line 152 - 162. And for test suites, by setting ENABLE_XXX_TESTS in test/TestConfig.cmake. I'm collecting for review comments. Thanks. Best Regards, Kevin -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Re: [TF-M] irq handling in library mode

by Edison Ai (Arm Technology China)

Hi Matt, Thanks for your email. Let me try to answer your question because of the designer of the TF-M interrupt handling is on leave now. First, you are right about this: "If the interrupted partition is the same as the handler partition, interrupted_ctx_stack_frame_t and handler_ctx_stack_frame_t should be pushed at different location." Let's start from an example, there are 3 SPs with different interrupt priority, SP1 < SP2 < SP3. And there is one scenario like this: * SP1 is running, SP2 interrupt SP1. Current, the interrupted partition is SP1, and the handler partition is SP2. As the below code show in tfm_spm_partition_push_handler_ctx(), the stack pointer will be moved upper as below: SP2 stack pointer ---> Caller_partition_indx(handler) Partition_sate(handler) * SP2 starts to run, and it is interrupted by SP3. Current, the interrupted partition is SP2, and the handler partition is SP3. As the code shown in tfm_spm_partition_push_interrupted_ctx(), it uses the current stack member directly without moving its pointer. SP2 stack pointer ---> Partition_state(interrupted) Caller_partition_indx(handler) Partition_sate(handler) And after SP2 is interrupted by SP3, its partition status will be changed to "SPM_PARTITION_STATE_SUSPENDED". So that this partition will not be interrupted by others anymore unless it comes back to running state. Which means it does not need more stack anymore. We can consider that after one SP is interrupted by others, there is no more stack is needed for it before it comes back to running status. So I think it should be ok in the current design for the interrupt in the library model. I am not sure if this can solve your confuse. Please feel free to give feedback. We can discuss more about it. Thanks, Edison From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of lg via TF-M Sent: Monday, December 16, 2019 1:08 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] irq handling in library mode Hi TFM experts, I have a question about the code logic of irq handling in library mode, code blocks in spm_api_func.c are as follows: void tfm_spm_partition_push_interrupted_ctx(uint32_t partition_idx) { struct spm_partition_runtime_data_t *runtime_data = &g_spm_partition_db.partitions[partition_idx].runtime_data; struct interrupted_ctx_stack_frame_t *stack_frame = (struct interrupted_ctx_stack_frame_t *)runtime_data->ctx_stack_ptr; stack_frame->partition_state = runtime_data->partition_state; } void tfm_spm_partition_push_handler_ctx(uint32_t partition_idx) { struct spm_partition_runtime_data_t *runtime_data = &g_spm_partition_db.partitions[partition_idx].runtime_data; struct handler_ctx_stack_frame_t *stack_frame = (struct handler_ctx_stack_frame_t *) runtime_data->ctx_stack_ptr; stack_frame->partition_state = runtime_data->partition_state; stack_frame->caller_partition_idx = runtime_data->caller_partition_idx; runtime_data->ctx_stack_ptr += sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t); } My question is why there is not the following such code logic at the end of function tfm_spm_partition_push_interrupted_ctx. runtime_data->ctx_stack_ptr += sizeof(struct interrupted_ctx_stack_frame_t ) / sizeof(uint32_t); If the interrupted partition is the same as the handler partition, interrupted_ctx_stack_frame_t and handler_ctx_stack_frame_t should be pushed at different location. And when pop the stack frame after handling irq, there is the following code logic in tfm_spm_partition_pop_handler_ctx runtime_data->ctx_stack_ptr -= sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t); I think the same logic of changing ctx_stack_ptr should be added the begining of the function tfm_spm_partition_pop_interrupted_ctx like the above code logic in tfm_spm_partition_pop_handler_ctx. runtime_data->ctx_stack_ptr -= sizeof(struct interrupted_ctx_stack_frame_t ) / sizeof(uint32_t); Please help to check. Thanks, Matt

6 years, 3 months

1
0
0 0

Re: [TF-M] MPU issues, was Re: Regression test issues with IAR port

by Edison Ai (Arm Technology China)

Hi Thomas, What I can see from your description is that the problem should is caused the MPU configure. You are working on the isolation level 2 model by using ConfigRegressionIPCTfmLevel2 configure file. In isolation level 2, PSA FF says this: "the PSA Root of Trust is also protected from access by the Application Root of Trust". You can see more detail about the isolation information from PSA FF with this link: https://pages.arm.com/psa-resources-ff.html?_ga=2.156169596.61580709.154261…. So, we need to configure MPU(MSUCA_A board which you are using) for APP RoT to limit the source the APP RoT can access in isolation level 2. You can see from code: __attribute__((naked, section("SFN"))) psa_signal_t psa_wait(psa_signal_t signal_mask, uint32_t timeout) { __ASM volatile("SVC %0 \n" "BX LR \n" : : "I" (TFM_SVC_PSA_WAIT)); } The psa_wait() is put in the "SFN" region, and the "SFN" region in put in the "TFM_UNPRIV_CODE" section. You can see the information about the "TFM_UNPRIV_CODE" in platform/ext/common/armclang/tfm_common_s.sct. You can refer tfm_spm_mpu_init() in platfrom/ext/target/musca_a/spm_hal.c. There are some MPU region we need to configure for APP RoT in isolation level 2, include the "TFM_UNPRIV_CODE". If you are interested, you can see some detail about the design of isolation level 2 from here: https://developer.trustedfirmware.org/w/tf_m/design/trusted_firmware-m_isol… Please check this first. If cannot work, please feel free to tell us. Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Friday, December 13, 2019 4:25 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] MPU issues, was Re: Regression test issues with IAR port Next issue. For some reason the secure image runs into a MemManage exception fairly early in the irq test of the ConfigRegressionIPCTfmLevel2 config and I have not yet been able to figure out why. It happens in the psa_wait() call in: --- int32_t tfm_irq_test_1_init(void) { tfm_enable_irq(SPM_CORE_IRQ_TEST_1_SIGNAL_TIMER_0_IRQ); #ifdef TFM_PSA_API psa_signal_t signals = 0; while (1) { signals = psa_wait(PSA_WAIT_ANY, PSA_BLOCK); --- The exact point of the exception is the SVC call in: --- __attribute__((naked, section("SFN"))) psa_signal_t psa_wait(psa_signal_t signal_mask, uint32_t timeout) { __ASM volatile("SVC %0 \n" "BX LR \n" : : "I" (TFM_SVC_PSA_WAIT)); } --- The cause is IACCVIOL, "The processor attempted an instruction fetch from a location that does not permit execution." The stack frame indicates that it happened on the SVC instruction, but I as far as I can see none of the MPU regions maps the address so I assumed it should be allowed as it should be handled by the background map, which should allow secure access. If I don't enable the mpu (just skipping the enable call) then all tests run without problems. I have tried to compare it with an image built with ARMCLANG, and I don't see anything obviously different. The regions are roughly the same, all regions with fixed addresses are the same, the enable bits are the same and the SVC handler is not mapped to any MPU region there either. I wish there were an MPU status register that would tell exactly what region was causing the exception. The odd thing is that there is an SVC call in the tfm_enable_irq() call prior to the psa_wait() call, and that works. This is on a Musca A by the way. Ideas? -- *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> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 3 months

2
2
0 0

irq handling in library mode

by lg

Hi TFM experts, I have a question about the code logic of irq handling in library mode, code blocks in spm_api_func.c are as follows: void tfm_spm_partition_push_interrupted_ctx(uint32_t partition_idx) { struct spm_partition_runtime_data_t *runtime_data = &g_spm_partition_db.partitions[partition_idx].runtime_data; struct interrupted_ctx_stack_frame_t *stack_frame = (struct interrupted_ctx_stack_frame_t *)runtime_data->ctx_stack_ptr; stack_frame->partition_state = runtime_data->partition_state; } void tfm_spm_partition_push_handler_ctx(uint32_t partition_idx) { struct spm_partition_runtime_data_t *runtime_data = &g_spm_partition_db.partitions[partition_idx].runtime_data; struct handler_ctx_stack_frame_t *stack_frame = (struct handler_ctx_stack_frame_t *) runtime_data->ctx_stack_ptr; stack_frame->partition_state = runtime_data->partition_state; stack_frame->caller_partition_idx = runtime_data->caller_partition_idx; runtime_data->ctx_stack_ptr += sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t); } My question is why there is not the following such code logic at the end of function tfm_spm_partition_push_interrupted_ctx. runtime_data->ctx_stack_ptr += sizeof(struct interrupted_ctx_stack_frame_t ) / sizeof(uint32_t); If the interrupted partition is the same as the handler partition, interrupted_ctx_stack_frame_t and handler_ctx_stack_frame_t should be pushed at different location. And when pop the stack frame after handling irq, there is the following code logic in tfm_spm_partition_pop_handler_ctx runtime_data->ctx_stack_ptr -= sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t); I think the same logic of changing ctx_stack_ptr should be added the begining of the function tfm_spm_partition_pop_interrupted_ctx like the above code logic in tfm_spm_partition_pop_handler_ctx. runtime_data->ctx_stack_ptr -= sizeof(struct interrupted_ctx_stack_frame_t ) / sizeof(uint32_t); Please help to check. Thanks, Matt

6 years, 3 months

1
0
0 0

Re: [TF-M] Adding Cypress PSoC64 platform support

by David Hu (Arm Technology China)

Hi all, After several rounds of review, I'd like to merge Cypress PSoC 64 support on master branch this Tuesday. If you have more comments or opinions, please share them before Tuesday. Thank you. Best regards, Hu Ziji -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: Saturday, December 7, 2019 4:13 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Adding Cypress PSoC64 platform support Hi, I recently pushed patches to add support for a platform based on Cypress' PSoC64 SoC to gerrit. Given that this is the first non-Arm platform to be posted, it seems worth drawing attention to. Comments very much appreciated. I do anticipate a few small updates to the patchset, even in the absence of comments. In particular, there are some documentation improvements to come. There are four patches in total, ending with https://review.trustedfirmware.org/c/trusted-firmware-m/+/2728 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2725/1 adds files to the platform/ext/cmsis directory, and so will affect/be affected by https://review.trustedfirmware.org/c/trusted-firmware-m/+/2578 Thanks, Chris This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Re: [TF-M] Please review the patch set to extract duplicated template files from platforms

by David Hu (Arm Technology China)

Hi all, I'd like to merge the patch set https://review.trustedfirmware.org/q/topic:%22template_plat_files%22+(statu… soon if no further comments. Please share your comments before this Tuesday. Best regards, Hu Ziji -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Thursday, December 12, 2019 11:57 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Please review the patch set to extract duplicated template files from platforms Hi all, I submit a patch set to extract the duplicated identical template files dummy_xxx.c from targets and put them under platform/ext/common/template folder. The purpose is to collect a common template of booting/attestation example for platforms and each platform doesn't need to keep a copy under its folder anymore. Since it is a general change related to all platforms using template files, I'd like to ask for review here. Any comments would be appreciated. Please check the patch details in https://review.trustedfirmware.org/q/topic:%22template_plat_files%22+(statu… The background is described in https://developer.trustedfirmware.org/T539. Best regards, Hu Ziji -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Re: [TF-M] Simplify RTOS / TF-M interface (single thread execution)

by David Wang (Arm Technology China)

The current RTOS integration with TZ API support is to make it generic. You can use "empty" implementation for these API if you don't use multiple secure context (SFC or IPC model) and have no multiple NS client IDs requirements. Besides that, the users can leverage TZ API for some other purposes, e.g. policy control for which NS task can access which secure partitions and etc. But that's quite use case specific. Just FYI. Regards, David Wang ARM Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Reinhard Keil via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 13 December 2019 19:41 To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] Simplify RTOS / TF-M interface (single thread execution) Ken, thanks for all your swift answers. Sorry, I need to check on this part of the answer again: * What happens worst case when an RTOS does not implement TZ RTOS Context Management? Ken.L: If there is no locking protection in NS and multiple ns calling would panic. TZ RTOS Context Management does not prevent from that. Correct. So the only feature that is enabled with TZ RTOS Context Management is 'client ID identification' for Protected Storage (and potentially other services). Reinhard IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Re: [TF-M] Create another branch for feature development

by Gyorgy Szing

Hi, Hi, I agree, the CI shall not dictate how we use the version control system. It shall adapt. Regarding your suggestions, I think the main problem is we are mixing stuff, this time quality with version control. Before we make decisions we shall understand where we are. The current quality policy is that we only make releases for communication purposes. To give a clean interface for tf-m users and to allow planning their work. Releases allow them to execute their tf-m integration process less frequently. Only for each release or specific releases and not for each commit. The current quality policy identifies a single quality level only, and says any patch we publish is "golden quality", it matches the highest quality standard we can achieve (with sane constraints). Also to make our life easy we decided to use the master branch to hold these patches. At the same time we use the master branch for development. Any change we make is made against master. This means each pull request and thus each review targets master. For review purposes the best is to have a chain of small modifications, otherwise the review content becomes too large to follow. The TF-A "branching strategy" tries to address this issue by introducing an integration branch used for development. This allows master to be more release specific. I suggest to take the following approach (details to be discussed): - introduce more quality levels i.e.: - none: content of a topic branch, or content pushed to review. - bronze: content passed code review and patch specific testing. - silver: content passed a more though daily testing. - gold: a release. A pack of source-code, feature state document (release notes), reviewed documentation (user manual, reference manual), test evidence, documentation of test efforts to allow repeatability. The version control system can be used to store content, and to provide identification info (i.e. tagging), but most likely the release will need other kind of storage to be used (i.e. documentation). - platina: reaching extra quality level trough passing PSA or some FUSA qualification. Or we may simply use extra release for this. Naming the quality levels allows us to have a cleaner definition of what can be expected at a specific level (set of quality measures, i.e. static analysis, code review, test configuration). It would also allow us cleaner communication and to find how we use the version system for quality purposes. I also expect this discussion to help defining how the version system is used for development purposes. The current state works ok, but is a sort of naturally grown. We might have reached the point when more pragmatic approach may be needed. /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Minos Galanakis via TF-M Sent: 13 December 2019 12:23 To: Edison Ai (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org>; Soby Mathew <Soby.Mathew(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Create another branch for feature development Hi all. My personal comments on this. I would like to point out that the CI is a tool, not the core project. I do not believe we should be changing our development strategy based on what the tool is doing. We should instead adjust the tool to fit our requirements. * No patches should be/ are merged to master when CI fails. If master breaks it should most commonly be because of something we are not testing for. Using an integration branch would not change that. * As a developer I find it more convoluted to work with projects who use different integration strategies. The most common assumption in open source projects is that you have a master branch which is the bleeding edge, but can contain untested bugs, and the release immutable git tags for versioning. Using branch merges as versioning is a design for the pull request model which is not quite compatible with Gerrit. * Most of the CI downtime has nothing to do with the merge strategy, they are more of a chicken and the egg philosophical problem. If your patch or branch introduced a change which affects the tests outputs, how will you test it if the CI expects the old output? An integration branch would not solve the merge freeze periods, would just affect a different branch from master. * I believe feature branches are quite useful, since changes to master do not disrupt the development flow of a big change, and even though they will require some maintenance to re-sync before the final patch , it will be handled by an engineer who knows the feature, and full understands the regression vectors. If I were to suggest some changes for stability purposes, I would start smaller: * Update documentation to instruct users to check out from release tags, warning then that master is constantly changing. * Adjust the CI to detect an Allow-CI flag from every branch. That way developers can test any patch from any feature branch. The logic for that is already present in the code, but requires Gerrit to be configured accordingly. * Add an undo process. This would be the only case for an integration branch. All patches are merged to a temporary branch, after confirming they have passed testing individually. On the once per day nightly test, the group of different patches, will be tested against an extensive job, in models and hardware, and only if successful it will fast forward master to that state. Regards Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Edison Ai (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 13 December 2019 08:55 To: Soby Mathew <Soby.Mathew(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] Create another branch for feature development Hi Soby, Thanks for your detail description. > Integration is a temporary merge branch to merge several patches and run the CI against. Usually once CI passes, the master will be fast forwarded to integration within a day. > This helps us to test integration of patches and detect any failure before master is updated. This means the master will pass CI at any given merge point. I think it's a good method like this so that we can double confirm the "master" branch is stable. And this also can fix one case even the CI can work normally: one patch is ready to merge, and it is not based on the latest HEAD, but there is no conflict. We can merge the patch directly and let gerrit do rebase by itself. But we cannot confirm the CI test can pass. Any comment for this from others? For multiple feature branches, I think we can stop to discuss about it now until we have some strong demands for it. It is indeed a big change for us now. Thanks, Edison -----Original Message----- From: Soby Mathew <Soby.Mathew(a)arm.com> Sent: Friday, December 13, 2019 5:14 AM To: Edison Ai (Arm Technology China) <Edison.Ai(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] Create another branch for feature development On 11/12/2019 09:05, Edison Ai (Arm Technology China) via TF-M wrote: > Hi Gyorgy, > > Thanks to point it out. I agree with you that it will be better if we can align these two projects in this. I had a quick check the branches from TF-A: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/. > There are three branches in TF-A: > - "integration" branch, should be used for new features. > - "master" branch, which is behind of "integration" branch. But I am nor sure what is the strategy to update it. Hi Edison, Integration is a temporary merge branch to merge several patches and run the CI against. Usually once CI passes, the master will be fast forwarded to integration within a day. This helps us to test integration of patches and detect any failure before master is updated. This means the master will pass CI at any given merge point. > - "topics/epic_beta0_spmd", I thinks it should like a feature branch for big feature. > @Soby Mathew Could you help to share more information about it? Thanks very much. We usually do not have feature branches in TF-A. The topics/epic_beta0_spmd is a prototyping branch where we wanted to share code with collaborators outside TF-A. The patches on this branch are not visible in gerrit review and no patches in gerrit review will be merged to this branch. Once the prototyping is complete, then patches on this branch will be reworked and pushed to gerrit review and finally get merged to integration and this branch will be deleted. Our experience have been, long running development branches are generally a maintenance overhead. Merging these development branches before a release may also be risky as some of the changes may have unknown interactions and may become difficult to resolve. The "topic" in gerrit review is effectively a branch. For example, this review: https://review.trustedfirmware.org/#/q/topic:od/debugfs+(status:open+OR+sta… is a set of patches on topic "od/debugfs" and can be treated as development branch. This branch is alive as long as patches are not merged. We need to understand the motivations for the change. Broken CI is an argument but development branches will only exacerbate that problem since we don't know the stability of each of those branches. Also merge conflict will not reduce due to development branches. Its just delaying the merge conflict to a later point. There may be other reasons, but generally it is better to merge sensible patches (+2ed) within a feature even before the feature is complete as it will reduce merge conflicts (we have to ensure testing/build coverage for the patch). These are my thoughts on this. Best Regards Soby Mathew -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Re: [TF-M] Simplify RTOS / TF-M interface (single thread execution)

by Reinhard Keil

Ken, thanks for all your swift answers. Sorry, I need to check on this part of the answer again: * What happens worst case when an RTOS does not implement TZ RTOS Context Management? Ken.L: If there is no locking protection in NS and multiple ns calling would panic. TZ RTOS Context Management does not prevent from that. Correct. So the only feature that is enabled with TZ RTOS Context Management is 'client ID identification' for Protected Storage (and potentially other services). Reinhard 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, 3 months

1
0
0 0

Re: [TF-M] Create another branch for feature development

by Minos Galanakis

Hi all. My personal comments on this. I would like to point out that the CI is a tool, not the core project. I do not believe we should be changing our development strategy based on what the tool is doing. We should instead adjust the tool to fit our requirements. * No patches should be/ are merged to master when CI fails. If master breaks it should most commonly be because of something we are not testing for. Using an integration branch would not change that. * As a developer I find it more convoluted to work with projects who use different integration strategies. The most common assumption in open source projects is that you have a master branch which is the bleeding edge, but can contain untested bugs, and the release immutable git tags for versioning. Using branch merges as versioning is a design for the pull request model which is not quite compatible with Gerrit. * Most of the CI downtime has nothing to do with the merge strategy, they are more of a chicken and the egg philosophical problem. If your patch or branch introduced a change which affects the tests outputs, how will you test it if the CI expects the old output? An integration branch would not solve the merge freeze periods, would just affect a different branch from master. * I believe feature branches are quite useful, since changes to master do not disrupt the development flow of a big change, and even though they will require some maintenance to re-sync before the final patch , it will be handled by an engineer who knows the feature, and full understands the regression vectors. If I were to suggest some changes for stability purposes, I would start smaller: * Update documentation to instruct users to check out from release tags, warning then that master is constantly changing. * Adjust the CI to detect an Allow-CI flag from every branch. That way developers can test any patch from any feature branch. The logic for that is already present in the code, but requires Gerrit to be configured accordingly. * Add an undo process. This would be the only case for an integration branch. All patches are merged to a temporary branch, after confirming they have passed testing individually. On the once per day nightly test, the group of different patches, will be tested against an extensive job, in models and hardware, and only if successful it will fast forward master to that state. Regards Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Edison Ai (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 13 December 2019 08:55 To: Soby Mathew <Soby.Mathew(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] Create another branch for feature development Hi Soby, Thanks for your detail description. > Integration is a temporary merge branch to merge several patches and run the CI against. Usually once CI passes, the master will be fast forwarded to integration within a day. > This helps us to test integration of patches and detect any failure before master is updated. This means the master will pass CI at any given merge point. I think it's a good method like this so that we can double confirm the "master" branch is stable. And this also can fix one case even the CI can work normally: one patch is ready to merge, and it is not based on the latest HEAD, but there is no conflict. We can merge the patch directly and let gerrit do rebase by itself. But we cannot confirm the CI test can pass. Any comment for this from others? For multiple feature branches, I think we can stop to discuss about it now until we have some strong demands for it. It is indeed a big change for us now. Thanks, Edison -----Original Message----- From: Soby Mathew <Soby.Mathew(a)arm.com> Sent: Friday, December 13, 2019 5:14 AM To: Edison Ai (Arm Technology China) <Edison.Ai(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] Create another branch for feature development On 11/12/2019 09:05, Edison Ai (Arm Technology China) via TF-M wrote: > Hi Gyorgy, > > Thanks to point it out. I agree with you that it will be better if we can align these two projects in this. I had a quick check the branches from TF-A: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/. > There are three branches in TF-A: > - "integration" branch, should be used for new features. > - "master" branch, which is behind of "integration" branch. But I am nor sure what is the strategy to update it. Hi Edison, Integration is a temporary merge branch to merge several patches and run the CI against. Usually once CI passes, the master will be fast forwarded to integration within a day. This helps us to test integration of patches and detect any failure before master is updated. This means the master will pass CI at any given merge point. > - "topics/epic_beta0_spmd", I thinks it should like a feature branch for big feature. > @Soby Mathew Could you help to share more information about it? Thanks very much. We usually do not have feature branches in TF-A. The topics/epic_beta0_spmd is a prototyping branch where we wanted to share code with collaborators outside TF-A. The patches on this branch are not visible in gerrit review and no patches in gerrit review will be merged to this branch. Once the prototyping is complete, then patches on this branch will be reworked and pushed to gerrit review and finally get merged to integration and this branch will be deleted. Our experience have been, long running development branches are generally a maintenance overhead. Merging these development branches before a release may also be risky as some of the changes may have unknown interactions and may become difficult to resolve. The "topic" in gerrit review is effectively a branch. For example, this review: https://review.trustedfirmware.org/#/q/topic:od/debugfs+(status:open+OR+sta… is a set of patches on topic "od/debugfs" and can be treated as development branch. This branch is alive as long as patches are not merged. We need to understand the motivations for the change. Broken CI is an argument but development branches will only exacerbate that problem since we don't know the stability of each of those branches. Also merge conflict will not reduce due to development branches. Its just delaying the merge conflict to a later point. There may be other reasons, but generally it is better to merge sensible patches (+2ed) within a feature even before the feature is complete as it will reduce merge conflicts (we have to ensure testing/build coverage for the patch). These are my thoughts on this. Best Regards Soby Mathew -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Re: [TF-M] Simplify RTOS / TF-M interface (single thread execution)

by Reinhard Keil

Ken, Thanks for your reply. Let me summarize what I have understood: TF-M SFC mode: * Allows only one thread at the time to call secure services. * When secure services are called recursively (multiple threads) TF-M goes into 'panic' state. This should not happen with proper mutex locks. * TZ RTOS Context Management interface is only required when "Client Oriented Policy" is used. I have updated the diagram to reflect what I have understood. Obviously the SVC would be only executed when the call into "secure" is from Thread mode. Is my understanding correct? (diagram is also under: https://developer.trustedfirmware.org/T615) - I just realized that you made a similar picture). [cid:image003.jpg@01D5B197.BE352670] The initial question can be then refined to: * TZ RTOS Context management is only needed when "Client Oriented Policy" is used. * When and why is "Client Oriented Policy" a requirement on v8-M systems? * Is there a way to disable ""Client Oriented Policy" in the current TF-M Core? * This applies for both the TF-M firmware itself and the related test suite. * What happens worst case when an RTOS does not implement TZ RTOS Context Management? Reinhard _______________________________________________________________________________ Reinhard Keil | Phone: +49 89 456040-13 | Email: reinhard.keil(a)arm.com<mailto:reinhard.keil@arm.com> | www.keil.com<http://www.keil.com> ARM Germany GmbH | Bretonischer Ring 16 | D-85630 Grasbrunn,Germany Sitz der Gesellschaft: Grasbrunn | Handelsregister: München (HRB 175362) Geschäftsführer: Andrew Smith, 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, 3 months

2
1
0 0

Re: [TF-M] Secure storage and Internal trusted storage code logic check

by Edison Ai (Arm Technology China)

Hi Matt, Thanks for your quick patch. Hi All, The patch link is here: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2792/. Please help to review it if you are interested. Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of lg via TF-M Sent: Thursday, December 12, 2019 4:42 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Secure storage and Internal trusted storage code logic check Hi Edison, Thanks for your quick reply. I will try to upstream a patch later. Thanks, Matt At 2019-12-12 11:15:51, "Edison Ai \$Arm Technology China\$ via TF-M" <tf-m(a)lists.trustedfirmware.org> wrote: >Hi Matt, > >Thanks very much for your mail. It looks like it is indeed a problem here. >Can you upstream a patch to help to fix them directly? > >Thanks, >Edison > >-----Original Message----- >From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of lg via TF-M >Sent: Thursday, December 12, 2019 9:43 AM >To: tf-m(a)lists.trustedfirmware.org >Subject: [TF-M] Secure storage and Internal trusted storage code logic check > >Hi TFM Secure storage & Internal trusted storage experts, > > > It seems there are code logic errors in both files sst_flash_fs_mblock.c and its_flash_fs_mblock.c. > There are following codes in function its_flash_fs_mblock_reset_metablock in its_flash_fs_mblock.c: > > > for (i = ITS_INIT_DBLOCK_START; i < ITS_NUM_DEDICATED_DBLOCKS; i++) { > /* If a flash error is detected, the code erases the rest > * of the blocks anyway to remove all data stored in them. > */ > err |= its_flash_erase_block(i); > } > This loop starts from ITS_INIT_DBLOCK_START and ends to ITS_NUM_DEDICATED_DBLOCKS. > If there are four ITS blocks including meta blocks and data blocks in all, that means ITS_INIT_DBLOCK_START > is 3 and ITS_NUM_DEDICATED_DBLOCKS is 1. But the above loop can not erase the data block any way. > Should it be the following logic? > > > for (i = 0; i < ITS_NUM_DEDICATED_DBLOCKS; i++) { > /* If a flash error is detected, the code erases the rest > * of the blocks anyway to remove all data stored in them. > */ > err |= its_flash_erase_block(i+ITS_INIT_DBLOCK_START); > } > It is the same logic in function sst_flash_fs_mblock_reset_metablock in file sst_flash_fs_mblock.c. > > > Please help to check. > > >Thanks. >Matt. > >-- >TF-M mailing list >TF-M(a)lists.trustedfirmware.org >https://lists.trustedfirmware.org/mailman/listinfo/tf-m >-- >TF-M mailing list >TF-M(a)lists.trustedfirmware.org >https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Re: [TF-M] Create another branch for feature development

by Soby Mathew

On 11/12/2019 09:05, Edison Ai (Arm Technology China) via TF-M wrote: > Hi Gyorgy, > > Thanks to point it out. I agree with you that it will be better if we can align these two projects in this. I had a quick check the branches from TF-A: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/. > There are three branches in TF-A: > - "integration" branch, should be used for new features. > - "master" branch, which is behind of "integration" branch. But I am nor sure what is the strategy to update it. Hi Edison, Integration is a temporary merge branch to merge several patches and run the CI against. Usually once CI passes, the master will be fast forwarded to integration within a day. This helps us to test integration of patches and detect any failure before master is updated. This means the master will pass CI at any given merge point. > - "topics/epic_beta0_spmd", I thinks it should like a feature branch for big feature. > @Soby Mathew Could you help to share more information about it? Thanks very much. We usually do not have feature branches in TF-A. The topics/epic_beta0_spmd is a prototyping branch where we wanted to share code with collaborators outside TF-A. The patches on this branch are not visible in gerrit review and no patches in gerrit review will be merged to this branch. Once the prototyping is complete, then patches on this branch will be reworked and pushed to gerrit review and finally get merged to integration and this branch will be deleted. Our experience have been, long running development branches are generally a maintenance overhead. Merging these development branches before a release may also be risky as some of the changes may have unknown interactions and may become difficult to resolve. The "topic" in gerrit review is effectively a branch. For example, this review: https://review.trustedfirmware.org/#/q/topic:od/debugfs+(status:open+OR+sta… is a set of patches on topic "od/debugfs" and can be treated as development branch. This branch is alive as long as patches are not merged. We need to understand the motivations for the change. Broken CI is an argument but development branches will only exacerbate that problem since we don't know the stability of each of those branches. Also merge conflict will not reduce due to development branches. Its just delaying the merge conflict to a later point. There may be other reasons, but generally it is better to merge sensible patches (+2ed) within a feature even before the feature is complete as it will reduce merge conflicts (we have to ensure testing/build coverage for the patch). These are my thoughts on this. Best Regards Soby Mathew

6 years, 3 months

2
1
0 0

Re: [TF-M] Simplify RTOS / TF-M interface (single thread execution)

by Ken Liu (Arm Technology China)

Hi Reinhard, Guess this diagram for a long time ago design since the latest version there is no need for NS SVC. (Check diagram attached in the ticket). I think the existing library model implementation is almost the one you described, just some points: - We use a secure SVC in SPM for sanitization input/output buffers. - We do secure partition maintenance in SPM (forward call, maintain state). The TZ API implementation under SFC is for the purpose that some services have bound the client with policies so they need to know which client is calling. It can be skipped if there is no such client-orient policy. And one thing to mention, even we propose to use locks in RTOS for locking the interface, there would be a chance that some RTOS has a limitation on these lock APIs, or someone just acts as an attacker who skips the necessary locking operations, then we need to provide some detection in the secure side as countermeasures, and this part needs to be documented to remind users that, please make sure there is only one ongoing secure call or a panic is generated. Then it would be RTOS' choice to decide if they want to avoid this panic by locking. /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: Thursday, December 12, 2019 11:22 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Simplify RTOS / TF-M interface (single thread execution) As the picture got lost, I did create also https://developer.trustedfirmware.org/T615 This contains the picture Reinhard IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

MPU issues, was Re: Regression test issues with IAR port

by Thomas Törnblom

Next issue. For some reason the secure image runs into a MemManage exception fairly early in the irq test of the ConfigRegressionIPCTfmLevel2 config and I have not yet been able to figure out why. It happens in the psa_wait() call in: --- int32_t tfm_irq_test_1_init(void) { tfm_enable_irq(SPM_CORE_IRQ_TEST_1_SIGNAL_TIMER_0_IRQ); #ifdef TFM_PSA_API psa_signal_t signals = 0; while (1) { signals = psa_wait(PSA_WAIT_ANY, PSA_BLOCK); --- The exact point of the exception is the SVC call in: --- __attribute__((naked, section("SFN"))) psa_signal_t psa_wait(psa_signal_t signal_mask, uint32_t timeout) { __ASM volatile("SVC %0 \n" "BX LR \n" : : "I" (TFM_SVC_PSA_WAIT)); } --- The cause is IACCVIOL, "The processor attempted an instruction fetch from a location that does not permit execution." The stack frame indicates that it happened on the SVC instruction, but I as far as I can see none of the MPU regions maps the address so I assumed it should be allowed as it should be handled by the background map, which should allow secure access. If I don't enable the mpu (just skipping the enable call) then all tests run without problems. I have tried to compare it with an image built with ARMCLANG, and I don't see anything obviously different. The regions are roughly the same, all regions with fixed addresses are the same, the enable bits are the same and the SVC handler is not mapped to any MPU region there either. I wish there were an MPU status register that would tell exactly what region was causing the exception. The odd thing is that there is an SVC call in the tfm_enable_irq() call prior to the psa_wait() call, and that works. This is on a Musca A by the way. Ideas? -- *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, 3 months

1
0
0 0

TF-M Technical Forum call - 19th December

by Anton Komlev

Hello, To continuing our open discussion, started a week ago let me propose the 2nd session and create this mail thread to discuss related topics. 1. The time slot. Looking on participants' distribution [Asia:6, Europe:20, US East:1, US Cent:1, US West:4, Total:32] I see the majority is in Europe. The Asian region could be more presented giving a more comfortable time. Having this in mind, I would propose to have the 2nd session on Dec 19 at 7:00 UTC time. This compromise gives US West coast a chance to join at 23:00 (Dec 18!). Here is the summary: https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=… Please share your thoughts and alternatives. The related question: shall we fix the time or rotating? You can play with the time slot here: https://www.timeanddate.com/worldclock/meetingtime.html?day=19&month=12&yea… 2. Agenda as a proposal - The interrupts' topic was followed by email and looks like closed. Are there remaining points for discussion? - TF-M and Amazon FreeRTOS integration update - Cryptocell integration - ? Best regards, Anton Komlev

6 years, 3 months

1
0
0 0

Re: [TF-M] Simplify RTOS / TF-M interface (single thread execution)

by Gyorgy Szing

Hi, Sorry the image did not got trough. One way to share the image could be to create a ticket here https://developer.trustedfirmware.org/maniphest/ where the image can be uploaded. /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: 12 December 2019 13:13 To: tf-m(a)lists.trustedfirmware.org Cc: Bruno Mendes <Bruno.Mendes(a)arm.com> Subject: [TF-M] Simplify RTOS / TF-M interface (single thread execution) When using TF-M on v8-M with Secure Function Call SFC (aka Library) mode, the entry to the secure side is protected by a Mutex. Thus only one thread at the time is calling a secure service. The picture below should therefore represent the execution flow (Level 1 isolation). [cid:image003.jpg@01D5B0ED.DEEA6A60] Under this assumption there is no need to implement TZ_context management in the RTOS (https://arm-software.github.io/CMSIS_5/Core/html/using_TrustZone_pg.html#RT…). Any RTOS could be used, provided that the Mutex capability is sufficient. Moreover this design should create a really simple secure side: * Only one stack is needed on the secure side for Thread mode execution * No multi-threading issues that need to be resolved (i.e. with access of hardware crypto accelerators) The drawback of course is that only one task at a time can use a secure service. However an RTOS with priority inversion will ensure that the Secure service is executed as fast as possible, once a scheduling conflict arises. I would like to gather feedback on that approach. Let me know what you think. Reinhard IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

2
1
0 0

Simplify RTOS / TF-M interface (single thread execution)

by Reinhard Keil

When using TF-M on v8-M with Secure Function Call SFC (aka Library) mode, the entry to the secure side is protected by a Mutex. Thus only one thread at the time is calling a secure service. The picture below should therefore represent the execution flow (Level 1 isolation). [cid:image003.jpg@01D5B0ED.DEEA6A60] Under this assumption there is no need to implement TZ_context management in the RTOS (https://arm-software.github.io/CMSIS_5/Core/html/using_TrustZone_pg.html#RT…). Any RTOS could be used, provided that the Mutex capability is sufficient. Moreover this design should create a really simple secure side: * Only one stack is needed on the secure side for Thread mode execution * No multi-threading issues that need to be resolved (i.e. with access of hardware crypto accelerators) The drawback of course is that only one task at a time can use a secure service. However an RTOS with priority inversion will ensure that the Secure service is executed as fast as possible, once a scheduling conflict arises. I would like to gather feedback on that approach. Let me know what you think. Reinhard 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, 3 months

1
0
0 0

Re: [TF-M] [EXTERNAL] Secure Interrupt handling - RE: TF-M technical Forum slides and recording

by DeMars, Alan

Ken, Task scheduling (context switching) in our RTOS is always performed in thread mode, even when asynchronous pre-emption occurs resulting from an ISR readying a higher priority task. All kernel-managed interrupts are routed to a common interrupt dispatcher that, just prior to returning from an interrupt, will invoke the task scheduler when it determines that there are no more interrupts pending and there is scheduling work to do. In that case, an artificial interrupt context is created so that thread mode can be "returned to" from handler mode. The task scheduler is then invoked in thread mode from the stack of the pre-empted task. Regarding secure interrupts, our use cases only employ secure interrupts as a consequence of a psa_call() initiating a process that completes when an interrupt goes off sometime later. Rather than spin-waiting for the interrupt-completion signal, or parking in a WFI, we simply return from the psa_call() with a special return code indicating that the process has started and that the calling thread will be notified of completion by the secure callback mechanism I described at the conference in Lyon. The calling thread then pends on a semaphore. When the secure interrupt goes off later on, a dedicated non-secure interrupt is triggered that ultimately ends up posting the semaphore that the NS thread is pended on. Upon returning from the pend, the NS thread then re-enters the SP (using psa_call()) to complete the transaction. Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Tuesday, December 10, 2019 8:04 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] [TF-M] Secure Interrupt handling - RE: TF-M technical Forum slides and recording Thank Bill for updating this. I want to use this thread to follow up on the topic 'secure interrupt' given in the 1st tech forum. That is a prologue of the scheduler and interrupt designs. And I do see there are some use cases that I did not focus on, so I want to collect more user scenarios first, and then try to enhance the drafting design (will be published after I updated it base on your inputs). About the secure interrupt usage: - A secure interrupt would be introduced by a secure service call in general; is there any scenarios that there would be an interval secure interrupt since secure service want to do something? For example, a secure timer triggers to let secure service has the chance to do things in the background (not for an ongoing secure call from NSPE) after a period of time? And the question about the system Alan mentioned, just want to confirm if it is a pure thread mode scheduling system? How does the system handle interrupts? Thanks. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Bill Fletcher via TF-M Sent: Monday, December 9, 2019 7:57 PM To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] TF-M technical Forum slides and recording Hi all, I've posted links to the (updated) slide deck and a recording of the call on the meetings page of the Trusted Firmware website: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Regards Bill -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

2
1
0 0

Re: [TF-M] Secure storage and Internal trusted storage code logic check

by lg

Hi Edison, Thanks for your quick reply. I will try to upstream a patch later. Thanks, Matt At 2019-12-12 11:15:51, "Edison Ai \$Arm Technology China\$ via TF-M" <tf-m(a)lists.trustedfirmware.org> wrote: >Hi Matt, > >Thanks very much for your mail. It looks like it is indeed a problem here. >Can you upstream a patch to help to fix them directly? > >Thanks, >Edison > >-----Original Message----- >From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of lg via TF-M >Sent: Thursday, December 12, 2019 9:43 AM >To: tf-m(a)lists.trustedfirmware.org >Subject: [TF-M] Secure storage and Internal trusted storage code logic check > >Hi TFM Secure storage & Internal trusted storage experts, > > > It seems there are code logic errors in both files sst_flash_fs_mblock.c and its_flash_fs_mblock.c. > There are following codes in function its_flash_fs_mblock_reset_metablock in its_flash_fs_mblock.c: > > > for (i = ITS_INIT_DBLOCK_START; i < ITS_NUM_DEDICATED_DBLOCKS; i++) { > /* If a flash error is detected, the code erases the rest > * of the blocks anyway to remove all data stored in them. > */ > err |= its_flash_erase_block(i); > } > This loop starts from ITS_INIT_DBLOCK_START and ends to ITS_NUM_DEDICATED_DBLOCKS. > If there are four ITS blocks including meta blocks and data blocks in all, that means ITS_INIT_DBLOCK_START > is 3 and ITS_NUM_DEDICATED_DBLOCKS is 1. But the above loop can not erase the data block any way. > Should it be the following logic? > > > for (i = 0; i < ITS_NUM_DEDICATED_DBLOCKS; i++) { > /* If a flash error is detected, the code erases the rest > * of the blocks anyway to remove all data stored in them. > */ > err |= its_flash_erase_block(i+ITS_INIT_DBLOCK_START); > } > It is the same logic in function sst_flash_fs_mblock_reset_metablock in file sst_flash_fs_mblock.c. > > > Please help to check. > > >Thanks. >Matt. > >-- >TF-M mailing list >TF-M(a)lists.trustedfirmware.org >https://lists.trustedfirmware.org/mailman/listinfo/tf-m >-- >TF-M mailing list >TF-M(a)lists.trustedfirmware.org >https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Please review the patch set to extract duplicated template files from platforms

by David Hu (Arm Technology China)

Hi all, I submit a patch set to extract the duplicated identical template files dummy_xxx.c from targets and put them under platform/ext/common/template folder. The purpose is to collect a common template of booting/attestation example for platforms and each platform doesn't need to keep a copy under its folder anymore. Since it is a general change related to all platforms using template files, I'd like to ask for review here. Any comments would be appreciated. Please check the patch details in https://review.trustedfirmware.org/q/topic:%22template_plat_files%22+(statu… The background is described in https://developer.trustedfirmware.org/T539. Best regards, Hu Ziji

6 years, 3 months

1
0
0 0

Re: [TF-M] Secure storage and Internal trusted storage code logic check

by Edison Ai (Arm Technology China)

Hi Matt, Thanks very much for your mail. It looks like it is indeed a problem here. Can you upstream a patch to help to fix them directly? Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of lg via TF-M Sent: Thursday, December 12, 2019 9:43 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Secure storage and Internal trusted storage code logic check Hi TFM Secure storage & Internal trusted storage experts, It seems there are code logic errors in both files sst_flash_fs_mblock.c and its_flash_fs_mblock.c. There are following codes in function its_flash_fs_mblock_reset_metablock in its_flash_fs_mblock.c: for (i = ITS_INIT_DBLOCK_START; i < ITS_NUM_DEDICATED_DBLOCKS; i++) { /* If a flash error is detected, the code erases the rest * of the blocks anyway to remove all data stored in them. */ err |= its_flash_erase_block(i); } This loop starts from ITS_INIT_DBLOCK_START and ends to ITS_NUM_DEDICATED_DBLOCKS. If there are four ITS blocks including meta blocks and data blocks in all, that means ITS_INIT_DBLOCK_START is 3 and ITS_NUM_DEDICATED_DBLOCKS is 1. But the above loop can not erase the data block any way. Should it be the following logic? for (i = 0; i < ITS_NUM_DEDICATED_DBLOCKS; i++) { /* If a flash error is detected, the code erases the rest * of the blocks anyway to remove all data stored in them. */ err |= its_flash_erase_block(i+ITS_INIT_DBLOCK_START); } It is the same logic in function sst_flash_fs_mblock_reset_metablock in file sst_flash_fs_mblock.c. Please help to check. Thanks. Matt. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Secure storage and Internal trusted storage code logic check

by lg

Hi TFM Secure storage & Internal trusted storage experts, It seems there are code logic errors in both files sst_flash_fs_mblock.c and its_flash_fs_mblock.c. There are following codes in function its_flash_fs_mblock_reset_metablock in its_flash_fs_mblock.c: for (i = ITS_INIT_DBLOCK_START; i < ITS_NUM_DEDICATED_DBLOCKS; i++) { /* If a flash error is detected, the code erases the rest * of the blocks anyway to remove all data stored in them. */ err |= its_flash_erase_block(i); } This loop starts from ITS_INIT_DBLOCK_START and ends to ITS_NUM_DEDICATED_DBLOCKS. If there are four ITS blocks including meta blocks and data blocks in all, that means ITS_INIT_DBLOCK_START is 3 and ITS_NUM_DEDICATED_DBLOCKS is 1. But the above loop can not erase the data block any way. Should it be the following logic? for (i = 0; i < ITS_NUM_DEDICATED_DBLOCKS; i++) { /* If a flash error is detected, the code erases the rest * of the blocks anyway to remove all data stored in them. */ err |= its_flash_erase_block(i+ITS_INIT_DBLOCK_START); } It is the same logic in function sst_flash_fs_mblock_reset_metablock in file sst_flash_fs_mblock.c. Please help to check. Thanks. Matt.

6 years, 3 months

1
0
0 0

Re: [TF-M] IAR libc behavior?

by Ken Liu (Arm Technology China)

Thanks Thomas. Let me try that link. /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Wednesday, December 11, 2019 9:13 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] IAR libc behavior? Hi Ken, There should be no difference from GNUARM or ARMCLANG in this respect. Should not need any special switches. If you wish to try out our tools, you can download a trial version until we have arranged for a permanent solution, see: https://www.iar.com/iar-embedded-workbench/#!?architecture=Arm Cheers, Thomas Den 2019-12-11 kl. 11:05, skrev Ken Liu (Arm Technology China) via TF-M: > Hi Thomas, > > I have a question about IAR compiler since we verify default GNUARM and ARMCLANG in the existing sources. > If we are trying to implementing some internal version of libc APIs like 'memcmp', would IAR link with this implemented version first, or it just report a link error of duplicated symbol? Any switches do we need to assign to support this? > > Thanks. > > /Ken -- *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> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Re: [TF-M] IAR libc behavior?

by Thomas Törnblom

Hi Ken, There should be no difference from GNUARM or ARMCLANG in this respect. Should not need any special switches. If you wish to try out our tools, you can download a trial version until we have arranged for a permanent solution, see: https://www.iar.com/iar-embedded-workbench/#!?architecture=Arm Cheers, Thomas Den 2019-12-11 kl. 11:05, skrev Ken Liu (Arm Technology China) via TF-M: > Hi Thomas, > > I have a question about IAR compiler since we verify default GNUARM and ARMCLANG in the existing sources. > If we are trying to implementing some internal version of libc APIs like 'memcmp', would IAR link with this implemented version first, or it just report a link error of duplicated symbol? Any switches do we need to assign to support this? > > Thanks. > > /Ken -- *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, 3 months

1
0
0 0

IAR libc behavior?

by Ken Liu (Arm Technology China)

Hi Thomas, I have a question about IAR compiler since we verify default GNUARM and ARMCLANG in the existing sources. If we are trying to implementing some internal version of libc APIs like 'memcmp', would IAR link with this implemented version first, or it just report a link error of duplicated symbol? Any switches do we need to assign to support this? Thanks. /Ken

6 years, 3 months

1
0
0 0

Re: [TF-M] Create another branch for feature development

by Edison Ai (Arm Technology China)

Hi Gyorgy, Thanks to point it out. I agree with you that it will be better if we can align these two projects in this. I had a quick check the branches from TF-A: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/. There are three branches in TF-A: - "integration" branch, should be used for new features. - "master" branch, which is behind of "integration" branch. But I am nor sure what is the strategy to update it. - "topics/epic_beta0_spmd", I thinks it should like a feature branch for big feature. @Soby Mathew Could you help to share more information about it? Thanks very much. Hi David W, Thanks for your comments. For your first comment, I will say yes. Sorry to give the CI problem as a reason. For your second comment, I think we can use " git merge <commit-id>" to merge up to a special commit of dev to the master branch. In this, we do not need to freeze the patch merging. Maybe other methods to do it. Sorry, I am not a git expert, please correct me if it is wrong. I agree with you that we need to think clearly about it. Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: Wednesday, December 11, 2019 3:58 PM To: David Wang (Arm Technology China) <David.Wang(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Create another branch for feature development Hi, Please sync up with the TF-A team on branching strategy. It would be preferred to keep the two projects aligned if possible. /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang (Arm Technology China) via TF-M Sent: 11 December 2019 07:59 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Create another branch for feature development Hi Edison, It sounds reasonable to evolve the branch management in TF-M because we get more and more contributions in the community. Thanks for raising that. A few comments: >> * Reduce the risk to broke the master branch directly especial when the CI cannot work rightly. This reason of creating dev branch seems like a workaround as CI is not stable. >> * We can use the "master" branch only for release, and in this, we do not need to freeze the patch merging when preparing the release. If we don’t have the feature branches you proposed, then the problem seems to be the same. It's because dev branch is acting as the master branch and the release(master) branch get "git fast-forward" to a point of dev branch when doing the release. Then we still can't stop merging the unnecessary patches in the release unless we do manual rebase which is not what we wanted. For feature branches, I think it's a good idea but we need to make a process/policy about how/when to create the branches, who maintain the branches and the timing of merging this feature. This could align with the roadmap and release plan, e.g. next release will include a few features/bugfixes which are in corresponding branches. Just share my thoughts. Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, December 11, 2019 2:16 PM To: Kevin Peng (Arm Technology China) <Kevin.Peng(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] Create another branch for feature development Hi Kevin, Yes, you are right. The main point does not break a stable branch, it could be the "master" branch or "release" branch. Your suggest is good for it will not conflict with our current patches(upstream to the master branch). But the users may be more like to fetch code from the master branch for a stable version. We can discuss more about it. For this, I think we should discuss if it is necessary to create another branch for release or the stable version firstly. And for "are we already using feature branches such as feature-twincpu?": Yes, you are right again. But current, only several branches are created for huge features. What I mean it that we should not to merge patch to "master" or "release" branch directly. Or we just merge little change patches to master branch. For others, we can create a dedicated feature branch. For example, PSA FF alignment or even a bug fix. Thanks, Edison -----Original Message----- From: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com> Sent: Wednesday, December 11, 2019 1:43 PM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com>; 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: RE: Create another branch for feature development Hi Edison, In your proposal, the new "develop" branch seems to be the current "master" branch and the "master" branch becomes kind of release branch if I'm understand correctly. So why not create a "release" branch instead. And are we already using feature branches such as feature-twincpu? Best Regards, Kevin -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, December 11, 2019 11:24 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Create another branch for feature development Hi all, I have a proposal to create a "develop"(or something like this) branch in TF-M for our feature development. The reasons for this are: * Reduce the risk to broke the master branch directly especial when the CI cannot work rightly. * We can use the "master" branch only for release, and in this, we do not need to freeze the patch merging when preparing the release. More addition, we can create more branches for big features development, such as "develop/feature_a" or "develop/feature_b". All these new features branch need to be merged to the "develop" branch first and then release to the "master" branch. This is different from the current patch upstream mode, and it needs to spend more time maintaining those branches. But I think it is more convenient for us to develop different features. We do not need to spend more time to fix the conflicts and to do rebase when other patches merge to master branch during patch reviewing. Welcome to comment on this. Thanks, Edison -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Hotfix for GNUARM linker script

by David Hu (Arm Technology China)

Hi all, I uploaded a hotfix to fix a issue in GNUARM linker script. https://review.trustedfirmware.org/c/trusted-firmware-m/+/2767 The XXX_ATTR_FN label is named as XXX_LD_ATTR_FN for Application RoT Secure Partitions in GNUARM linker script. Thus GNUARM cannot get the dedicated section address to place the XXX_ATTR_FN section defined in the source code. It may cause linking error and crash during running. Please help review the patch. Any comment is welcome and will speed up the fix. Thank you. Best regards, Hu Ziji

6 years, 3 months

1
0
0 0

Re: [TF-M] Create another branch for feature development

by Gyorgy Szing

Hi, Please sync up with the TF-A team on branching strategy. It would be preferred to keep the two projects aligned if possible. /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang (Arm Technology China) via TF-M Sent: 11 December 2019 07:59 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Create another branch for feature development Hi Edison, It sounds reasonable to evolve the branch management in TF-M because we get more and more contributions in the community. Thanks for raising that. A few comments: >> * Reduce the risk to broke the master branch directly especial when the CI cannot work rightly. This reason of creating dev branch seems like a workaround as CI is not stable. >> * We can use the "master" branch only for release, and in this, we do not need to freeze the patch merging when preparing the release. If we don’t have the feature branches you proposed, then the problem seems to be the same. It's because dev branch is acting as the master branch and the release(master) branch get "git fast-forward" to a point of dev branch when doing the release. Then we still can't stop merging the unnecessary patches in the release unless we do manual rebase which is not what we wanted. For feature branches, I think it's a good idea but we need to make a process/policy about how/when to create the branches, who maintain the branches and the timing of merging this feature. This could align with the roadmap and release plan, e.g. next release will include a few features/bugfixes which are in corresponding branches. Just share my thoughts. Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, December 11, 2019 2:16 PM To: Kevin Peng (Arm Technology China) <Kevin.Peng(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] Create another branch for feature development Hi Kevin, Yes, you are right. The main point does not break a stable branch, it could be the "master" branch or "release" branch. Your suggest is good for it will not conflict with our current patches(upstream to the master branch). But the users may be more like to fetch code from the master branch for a stable version. We can discuss more about it. For this, I think we should discuss if it is necessary to create another branch for release or the stable version firstly. And for "are we already using feature branches such as feature-twincpu?": Yes, you are right again. But current, only several branches are created for huge features. What I mean it that we should not to merge patch to "master" or "release" branch directly. Or we just merge little change patches to master branch. For others, we can create a dedicated feature branch. For example, PSA FF alignment or even a bug fix. Thanks, Edison -----Original Message----- From: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com> Sent: Wednesday, December 11, 2019 1:43 PM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com>; 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: RE: Create another branch for feature development Hi Edison, In your proposal, the new "develop" branch seems to be the current "master" branch and the "master" branch becomes kind of release branch if I'm understand correctly. So why not create a "release" branch instead. And are we already using feature branches such as feature-twincpu? Best Regards, Kevin -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, December 11, 2019 11:24 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Create another branch for feature development Hi all, I have a proposal to create a "develop"(or something like this) branch in TF-M for our feature development. The reasons for this are: * Reduce the risk to broke the master branch directly especial when the CI cannot work rightly. * We can use the "master" branch only for release, and in this, we do not need to freeze the patch merging when preparing the release. More addition, we can create more branches for big features development, such as "develop/feature_a" or "develop/feature_b". All these new features branch need to be merged to the "develop" branch first and then release to the "master" branch. This is different from the current patch upstream mode, and it needs to spend more time maintaining those branches. But I think it is more convenient for us to develop different features. We do not need to spend more time to fix the conflicts and to do rebase when other patches merge to master branch during patch reviewing. Welcome to comment on this. Thanks, Edison -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Re: [TF-M] Create another branch for feature development

by David Wang (Arm Technology China)

Hi Edison, It sounds reasonable to evolve the branch management in TF-M because we get more and more contributions in the community. Thanks for raising that. A few comments: >> * Reduce the risk to broke the master branch directly especial when the CI cannot work rightly. This reason of creating dev branch seems like a workaround as CI is not stable. >> * We can use the "master" branch only for release, and in this, we do not need to freeze the patch merging when preparing the release. If we don’t have the feature branches you proposed, then the problem seems to be the same. It's because dev branch is acting as the master branch and the release(master) branch get "git fast-forward" to a point of dev branch when doing the release. Then we still can't stop merging the unnecessary patches in the release unless we do manual rebase which is not what we wanted. For feature branches, I think it's a good idea but we need to make a process/policy about how/when to create the branches, who maintain the branches and the timing of merging this feature. This could align with the roadmap and release plan, e.g. next release will include a few features/bugfixes which are in corresponding branches. Just share my thoughts. Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, December 11, 2019 2:16 PM To: Kevin Peng (Arm Technology China) <Kevin.Peng(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] Create another branch for feature development Hi Kevin, Yes, you are right. The main point does not break a stable branch, it could be the "master" branch or "release" branch. Your suggest is good for it will not conflict with our current patches(upstream to the master branch). But the users may be more like to fetch code from the master branch for a stable version. We can discuss more about it. For this, I think we should discuss if it is necessary to create another branch for release or the stable version firstly. And for "are we already using feature branches such as feature-twincpu?": Yes, you are right again. But current, only several branches are created for huge features. What I mean it that we should not to merge patch to "master" or "release" branch directly. Or we just merge little change patches to master branch. For others, we can create a dedicated feature branch. For example, PSA FF alignment or even a bug fix. Thanks, Edison -----Original Message----- From: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com> Sent: Wednesday, December 11, 2019 1:43 PM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com>; 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: RE: Create another branch for feature development Hi Edison, In your proposal, the new "develop" branch seems to be the current "master" branch and the "master" branch becomes kind of release branch if I'm understand correctly. So why not create a "release" branch instead. And are we already using feature branches such as feature-twincpu? Best Regards, Kevin -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, December 11, 2019 11:24 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Create another branch for feature development Hi all, I have a proposal to create a "develop"(or something like this) branch in TF-M for our feature development. The reasons for this are: * Reduce the risk to broke the master branch directly especial when the CI cannot work rightly. * We can use the "master" branch only for release, and in this, we do not need to freeze the patch merging when preparing the release. More addition, we can create more branches for big features development, such as "develop/feature_a" or "develop/feature_b". All these new features branch need to be merged to the "develop" branch first and then release to the "master" branch. This is different from the current patch upstream mode, and it needs to spend more time maintaining those branches. But I think it is more convenient for us to develop different features. We do not need to spend more time to fix the conflicts and to do rebase when other patches merge to master branch during patch reviewing. Welcome to comment on this. Thanks, Edison -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Re: [TF-M] Create another branch for feature development

by Kevin Peng (Arm Technology China)

Hi Edison, In your proposal, the new "develop" branch seems to be the current "master" branch and the "master" branch becomes kind of release branch if I'm understand correctly. So why not create a "release" branch instead. And are we already using feature branches such as feature-twincpu? Best Regards, Kevin -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, December 11, 2019 11:24 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Create another branch for feature development Hi all, I have a proposal to create a "develop"(or something like this) branch in TF-M for our feature development. The reasons for this are: * Reduce the risk to broke the master branch directly especial when the CI cannot work rightly. * We can use the "master" branch only for release, and in this, we do not need to freeze the patch merging when preparing the release. More addition, we can create more branches for big features development, such as "develop/feature_a" or "develop/feature_b". All these new features branch need to be merged to the "develop" branch first and then release to the "master" branch. This is different from the current patch upstream mode, and it needs to spend more time maintaining those branches. But I think it is more convenient for us to develop different features. We do not need to spend more time to fix the conflicts and to do rebase when other patches merge to master branch during patch reviewing. Welcome to comment on this. Thanks, Edison -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

2
1
0 0

Create another branch for feature development

by Edison Ai (Arm Technology China)

Hi all, I have a proposal to create a "develop"(or something like this) branch in TF-M for our feature development. The reasons for this are: * Reduce the risk to broke the master branch directly especial when the CI cannot work rightly. * We can use the "master" branch only for release, and in this, we do not need to freeze the patch merging when preparing the release. More addition, we can create more branches for big features development, such as "develop/feature_a" or "develop/feature_b". All these new features branch need to be merged to the "develop" branch first and then release to the "master" branch. This is different from the current patch upstream mode, and it needs to spend more time maintaining those branches. But I think it is more convenient for us to develop different features. We do not need to spend more time to fix the conflicts and to do rebase when other patches merge to master branch during patch reviewing. Welcome to comment on this. Thanks, Edison

6 years, 3 months

1
0
0 0

Secure Interrupt handling - RE: TF-M technical Forum slides and recording

by Ken Liu (Arm Technology China)

Thank Bill for updating this. I want to use this thread to follow up on the topic 'secure interrupt' given in the 1st tech forum. That is a prologue of the scheduler and interrupt designs. And I do see there are some use cases that I did not focus on, so I want to collect more user scenarios first, and then try to enhance the drafting design (will be published after I updated it base on your inputs). About the secure interrupt usage: - A secure interrupt would be introduced by a secure service call in general; is there any scenarios that there would be an interval secure interrupt since secure service want to do something? For example, a secure timer triggers to let secure service has the chance to do things in the background (not for an ongoing secure call from NSPE) after a period of time? And the question about the system Alan mentioned, just want to confirm if it is a pure thread mode scheduling system? How does the system handle interrupts? Thanks. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Bill Fletcher via TF-M Sent: Monday, December 9, 2019 7:57 PM To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] TF-M technical Forum slides and recording Hi all, I've posted links to the (updated) slide deck and a recording of the call on the meetings page of the Trusted Firmware website: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Regards Bill -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Support for optional build for secure partitions and test suites

by Kevin Peng (Arm Technology China)

Hi, I've made some patches to support optional build for secure partitions and test suites: https://review.trustedfirmware.org/q/topic:%22optional_build_sp_and_tests%2… With this patch set, you can optionally build secure partitions by setting the TFM_PARTITION_XXX in CommonConfig.cmake around line 152 - 162. And for test suites, by setting ENABLE_XXX_TESTS in test/TestConfig.cmake. I'm collecting for review comments. Thanks. Best Regards, Kevin

6 years, 3 months

1
0
0 0

TF-M technical Forum slides and recording

by Bill Fletcher

Hi all, I've posted links to the (updated) slide deck and a recording of the call on the meetings page of the Trusted Firmware website: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Regards Bill -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

6 years, 3 months

1
0
0 0

Adding Cypress PSoC64 platform support

by Christopher Brand

Hi, I recently pushed patches to add support for a platform based on Cypress' PSoC64 SoC to gerrit. Given that this is the first non-Arm platform to be posted, it seems worth drawing attention to. Comments very much appreciated. I do anticipate a few small updates to the patchset, even in the absence of comments. In particular, there are some documentation improvements to come. There are four patches in total, ending with https://review.trustedfirmware.org/c/trusted-firmware-m/+/2728 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2725/1 adds files to the platform/ext/cmsis directory, and so will affect/be affected by https://review.trustedfirmware.org/c/trusted-firmware-m/+/2578 Thanks, Chris This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

6 years, 3 months

1
0
0 0

Re: [TF-M] Regression test issues with IAR port

by Jamie Fox

Hi Thomas, Looks to me like the call to psa_ps_get() is retrieving the data set by psa_ps_set() in tfm_sst_test_1018_task_1(). This shouldn’t happen, because the two task functions are run in two different threads, which should have different client IDs. Can you check the client ID returned by tfm_core_get_caller_client_id() in tfm_sst_set_req() and tfm_sst_get_req() in each case? They should be different. Kind regards, Jamie From: Thomas Törnblom <thomas.tornblom(a)iar.com> Sent: 02 December 2019 22:50 To: Jamie Fox <Jamie.Fox(a)arm.com>; Minos Galanakis <Minos.Galanakis(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Regression test issues with IAR port Hi Jamie, From tfm_sst_test_1018_task_2(): --- ... uint8_t read_data[] = READ_DATA; status = psa_ps_get(uid, offset, data_len, read_data); if (status != PSA_PS_ERROR_UID_NOT_FOUND) { TEST_FAIL("Get should not succeed with invalid thread name"); return; } /* Check that read data has not been modified */ if (memcmp(read_data, READ_DATA, sizeof(read_data)) != 0) { TEST_FAIL("Read data should not have changed"); return; } ... --- The call to psa_ps_get() returns 0, which is a failure in this test. Out of curiosity I stopped right after this call and I notice that the read_data array had been clobbered and now starts with the string "THEQUICKBROWNFOX". This appears to happen in the following call chain: sst_object_read() -> sst_req_mngr_write_asset_data() -> memcpy() As there is a test that the data has not been clobbered after the return, I suspect that the two issues are related. sst_req_mngr_write_asset_data() uses a global variable p_data as the destination for the memcpy() call, and this variable gets set in the call chain tfm_core_sfn_request() -> tfm_sst_get_req() I see that the "info" argument in tfm_sst_test_1019_task_2() is also clobbered after the call to psa_ps_get(). It appears that it is only the tests with invalid thread names that fails, 1018, 1019 and 1020. I'll continue debugging this... Cheers, Thomas Den 2019-11-28 kl. 17:37, skrev Jamie Fox: Hi Thomas, We use prebuilt RTX binaries from the CMSIS_5 repo, which does make debugging RTX code more difficult. Before we go down that route, it's worth checking that the error isn't in TF-M I think. Just looking at the errors you are getting, the most likely explanation to me is that something has gone wrong with registering the mapping from RTX thread name to NS client ID. Your first failure is on line 936 of test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c for example, which checks that one thread cannot access the uid belonging to a different thread. This could happen, for example, if the two threads ended up with the same client_id due to some error in the mapping. The mapping is done by tfm_nspm_register_client_id() in interface/src/tfm_nspm_api.c, which is called by test_task_runner() in test/suites/sst/non_secure/ns_test_helpers.c at the start of the execution of each SST test thread. Could you check that tfm_nspm_register_client_id() is getting the correct client ID for each test thread? Also, it calls a function with the " __attribute__ ((naked))" attribute. As this is a compiler extension could there be some problem there? Kind regards, Jamie -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org><mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 28 November 2019 15:45 To: Minos Galanakis <Minos.Galanakis(a)arm.com><mailto:Minos.Galanakis@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] Regression test issues with IAR port Sorry, I was being unclear. I know where the tests start and ends, but the work appears to be handed off to the OS so that I can't (easily) step through the code and find what function is being used to look up the thread. The call to psa_ps_get() is used by the test and I assume it ends up using an RTX call and I would like to check what happens there. Cheers, Thomas Den 2019-11-28 kl. 16:00, skrev Minos Galanakis: Thomas, Tests are placed under the test -> suites -> service name directory. In your case you are looking at the Secure Storage Service non secure suite. For SST The logic is located at : * Non Secure side tests: test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c * Secure side tests: test/suites/sst/secure/psa_ps_s_interface_testsuite.c Hope that helps Minos ---------------------------------------------------------------------- -- *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org><mailto:tf-m-bounces@lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org><mailto:tf-m@lists.trustedfirmware.org> *Sent:* 28 November 2019 14:49 *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> *Subject:* [TF-M] Regression test issues with IAR port In my quest to port TF-M to the IAR toolchain I've run into issues with a few of the tests, and I need some hints where to look. The cmake build command line: --- cmake .. -G"Unix Makefiles" -DPROJ_CONFIG=C:\Users\thomasto\Projects\tf-m16\trusted-firmware-m\con figs\ConfigRegression.cmake -DTARGET_PLATFORM=MUSCA_A -DCOMPILER=IARARM -DCMAKE_BUILD_TYPE=RelWithDebInfo --- This results in three similar tests that fails: --- > Executing 'TFM_SST_TEST_1018' Description: 'Get interface with invalid thread name' Get should not succeed with invalid thread name (Failed at C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/n on_secure/psa_ps_ns_interface_testsuite.c:936) TEST FAILED! > Executing 'TFM_SST_TEST_1019' Description: 'Get info interface with invalid thread name' Get info should not succeed with invalid thread name (Failed at C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/n on_secure/psa_ps_ns_interface_testsuite.c:1015) TEST FAILED! > Executing 'TFM_SST_TEST_1020' Description: 'Remove interface with invalid thread name' Remove should not succeed with invalid thread name (Failed at C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/n on_secure/psa_ps_ns_interface_testsuite.c:1093) TEST FAILED! --- Where do I find the logic that determines if these tests succeed or fails? Cheers, 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> <mailto:thomas.tornblom@iar.com><mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com> <http://www.iar.com><http://www.iar.com> <http://www.iar.com><http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems> <http://www.twitter.com/iarsystems><http://www.twitter.com/iarsystems> <http://www.twitter.com/iarsystems><http://www.twitter.com/iarsystems> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- 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, 3 months

2
3
0 0

X.509 Certificate Chain Support in TF-M

by Kevin Townsend

Hi, As part of some of our work on TF-M, specifically around attestation, device provisioning and firmware management, we've been reviewing some of what various companies are currently doing or requiring during the provisioning process (whether provisioning at the manufacturing phase, or provisioning devices into cloud or similar services post manufacturing). The common thread in almost all of these scenarios is the use of X.509 certification chains when working with the public key(s) held on the end device. At Linaro, we've been thinking through some of the benefits and tradeoffs of migrating from the current approach of exposing unsigned public keys for things like initial attestation and signing firmware, and what would be required to allow the signing of the attestation/firmware keys on devices, and generating new keys such as provisioning a device onto an Amazon/Google/Microsoft cloud service which would require creating a new private key held in secure storage, and storing the signed certificate chain associated with that new private key for on-demand retrieval. - Some of the initial thinking and imagined benefits of migrating to X.509 certificate chains are described here: https://github.com/microbuilder/certificate_chains/blob/master/rfc_tfm.md - Some general notes on X.509 certificates are available here: https://github.com/microbuilder/certificate_chains/blob/master/README.md - And here are two scripts showing how to create 2 and 3 level certificate chains, just as a proof of concept to better understand how this might work with something like TF-M: - https://github.com/microbuilder/certificate_chains/blob/master/2lev_cert_cr… - https://github.com/microbuilder/certificate_chains/blob/master/3lev_cert_cr… Specifically, they key missing aspects to enable the use of standard X.509 certificates are: - Update mcuboot to understand a certificate chain -- rather than the raw public key -- when verifying firmware images - Generating PKSC#10 (RFC2986) certificate signing requests on the secure side, using a securely held private key during the request generation process - Generate new private keys and store them in secure storage for non-attestation uses like cloud services, and retrieve the associated and signed cert chains for that key on demand A proposal of how this might work in the real world is shown here, with the TF-M secure code requrements in the 'opt' box of the sequence diagram: https://github.com/microbuilder/certificate_chains/blob/master/rfc_tfm.md#c… We don't have a full TF-M proof of concept ready yet, but wanted to put the idea on the table of migrating to X.509 certificate chains while we work on a proof of concept, and continue analysis of how provision at manufacturing and in the field (to cloud services, etc.) can be improved. Any feedback/concerns is welcome here or perhaps in the Github repo above until a specific change request can be prepared for TF-M. Best regards, Kevin Townsend

6 years, 3 months

1
0
0 0

Re: [TF-M] [EXTERNAL] Re: out of tree build

by DeMars, Alan

In our use case, we added complete paths to the build area's corresponding directory to the embedded include paths and removed the default generated content from our git repo. Consequently only the newly generated content is found, wherever it happens to be placed. Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Kevin Peng (Arm Technology China) via TF-M Sent: Friday, November 22, 2019 2:15 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: Re: [TF-M] [EXTERNAL] Re: out of tree build Hi all, I'm having issues on supporting the out of tree build. So I'd like to propose some additional changes. What does the out of tree build currently support is that: The user uses the tfm_parse_manifest_list.py with the custom manifests to generate the customized files to a directory out of TF-M. And the TF-M build system uses the customized files rather than the pre-generated ones in the TF-M for building. The problem is that some of the source files include the generated headers using the relative path to where the source itself is. And the directory of the source file is always searched first. This makes it impossible to use the generated files outside TF-M even the custom output directory is added to searching list. So I suggest to put the generated files to a dedicated directory in TF-M. Then for the default build, add the directory and its subdirectories to the search list for headers. For out of tree build, use the specified directory and its subdirectories instead. Then there would only one header file with the same name in all the directories for searching headers. Any concerns, thoughts or suggestions? Best Regards, Kevin -----Original Message----- From: Kevin Peng (Arm Technology China) Sent: Friday, November 22, 2019 3:45 PM To: DeMars, Alan <ademars(a)ti.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: [EXTERNAL] Re: [TF-M] out of tree build Hi Alan, I've created a patch for the tfm_parse_manifest_list.py as the first step for the out of tree build support: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2606 The changes for build system is ongoing. The functionality changes for the tfm_parse_manifest_list.py is the same as your version. Please have a review and help verify it if possible. Comments from anyone else are also welcome. Best Regards, Kevin -----Original Message----- From: Kevin Peng (Arm Technology China) Sent: Thursday, November 14, 2019 3:31 PM To: DeMars, Alan <ademars(a)ti.com> Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> Subject: RE: [EXTERNAL] Re: [TF-M] out of tree build OK. It's much clearer for me now. Thanks. Best Regards, Kevin -----Original Message----- From: DeMars, Alan <ademars(a)ti.com> Sent: Thursday, November 14, 2019 10:34 AM To: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> Subject: Re: [EXTERNAL] Re: [TF-M] out of tree build 1) I verified the tfm_parse_manifest.py script changes using the master branch’s version of the tfm_manifest_list.yaml and tfm_generated_file_list.yaml files. 2) Yes, I’m building using the unmodified master branch’s cmake build system. 3) Just as all other build artifacts are placed in the user’s build directory and NOT in the source tree, the generated files should also. Otherwise, the user is required to update the source tree’s tfm_manifest_list.yaml and tfm_generated_file_list.yaml files to build a custom SPE, with the generated files also ending up in the source tree. The files necessary to create a custom SPE should not be kept in the source tree. Nor should the generated content be inserted in the source tree. This creates headaches for maintaining the original source tree. Alan > On Nov 13, 2019, at 1:57 AM, Kevin Peng (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Alan, > > I checked your modified tfm_parse_manifest_list.py. > It basically uses the input tfm_manifest_list.yaml and tfm_generated_file_list.yaml to generate the TF-M auto generated files to the third input. > > I'm sorry I was not in the workshop. So I have some questions. > 1. Do you have your own tfm_manifest_list.yaml and tfm_generated_file_list.yaml that is not upstreamed in TF-M? > 2. Are you using the TF-M provided CMake build system? > 3. Do you only need the files generated by tfm_parse_manifest_list.py to be out of the TF-M source directory? > > Could you provide some details about your requirements. Thanks. > > Best Regards, > Kevin > > -----Original Message----- > From: Kevin Peng (Arm Technology China) > Sent: Wednesday, November 13, 2019 10:27 AM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: RE: out of tree build > > Hi Alan, > > I'm following on this and will get you updated on any progress. > > Best Regards, > Kevin > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M > Sent: Thursday, November 7, 2019 12:42 PM > To: Abhishek Pandit <Abhishek.Pandit(a)arm.com> > Cc: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> > Subject: Re: [TF-M] out of tree build > > Trying again after renaming tfm_parse_manifest_list.py to tfm_parse_manifest_list.txt so it wouldn't get deleted. > --- > > With the attached modified secure_fw/CMakeLists.txt and tools/tfm_parse_manifest_list.py files, I am able to redirect the generated files using the following command line: > > python3 <full_path_to_your>/tfm_parse_manifest_list.py <full_path_to_your>/tfm_manifest_list.yaml <full_path_to_your>/tfm_generated_file_list.yaml <full_path_to_your>/<build_dir> > > And then build the ConfigCoreIPC artifacts within <your_build_dir> using the following cmake line: > > cmake -G"Unix Makefiles" -DPROJ_CONFIG=`readlink -f ../configs/ConfigCoreIPC.cmake` -DREMOTE_GEN_DIR=<full_path_to_your><build_dir> -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM ../ > > The changes to tfm_parse_manifest_list.py are backward compatible with the standard usage. > > Alan > > > -----Original Message----- > From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M > Sent: Monday, November 4, 2019 4:36 PM > To: Abhishek Pandit; tf-m(a)lists.trustedfirmware.org > Subject: [EXTERNAL] Re: [TF-M] out of tree build > > Abishek, > > Yes, we have modified tfm_gen.py and tfm_parse_manifest_list.py to support redirecting the destination of the generated template files into a command line provided destination build directory. > A corresponding change to our platform's platform/ext/xyz.cmake file was also required to add the path to the root of the build directory to the embedded_include_directories() list as well as the paths to the generated linker command files. > > I was not planning to provide these changes as a patch for review as I am very unsure of the applicability of this to other platforms. Also, I was fairly certain that given my very poor understanding of the CMake build system, my approach to the problem was not utilizing features present in CMake that would make the job simpler and more extensible. > > Since the topic came up at the conference and you already seemed willing to address the out-of-tree build problem that the templates lead to, I assumed you folks would find a simple and elegant solution that would save me the embarrassment of exposing my lack of CMake expertise. > > Alan > > -----Original Message----- > From: Abhishek Pandit [mailto:Abhishek.Pandit@arm.com] > Sent: Monday, November 4, 2019 3:08 PM > To: DeMars, Alan; tf-m(a)lists.trustedfirmware.org > Subject: [EXTERNAL] RE: out of tree build > > Hi Alan, > Not sure if I remember the exact detail from the workshop last week, but did you mention that you have a prototype for this? If so, are you planning to push a patch for review? > Thanks, > Abhishek > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M > Sent: 01 November 2019 16:29 > To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> > Subject: [TF-M] out of tree build > > Please modify the template generators to support out of tree build, and modify the CMake files to add the necessary include paths so that the files that include the template-generated files can find them. > > Alan > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

2
1
0 0

TF-M Technical Forum call - 5th December

by Bill Fletcher

Hi all, As mentioned in the TF-M workshop in Lyon last month, we propose to kick off the TF-M Technical Forum meeting, starting on the 5th December. This is an open forum for anyone to participate and it is not restricted to TF members. It will operate under the guidance of the TF TSC. - Due to expected attendees from Asia, Europe and the Americas, the timeslot is challenging. We hope it's not too difficult for anyone - we can review after the first couple of meetings. - Initially we propose a bi-weekly call and then we'll change cadence depending on interest For more details of the call click on the Google Calendar image at https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

6 years, 3 months

1
0
0 0

TF-M RC3 release

by Tamas Ban

Hi, A new tag TF-Mv1.0-RC3 was created last Friday. The main change since RC2 is that it provides support for integrated Cryptocell-312 cryptographic hardware accelerator on MuscaB1e platform. This enables TF-M to make use of Cryptocell-312 (CC-312) for crypto acceleration during Secure boot and runtime. TF-M is also can use the provisioned HUK (Hardware Unique Key), Attestation key and RoTPK (Root of Trust Public Key) in Cryptocell's OTP memory. Tamas

6 years, 3 months

1
0
0 0

Re: [TF-M] Regression test issues with IAR port

by Minos Galanakis

Thomas, Tests are placed under the test -> suites -> service name directory. In your case you are looking at the Secure Storage Service non secure suite. For SST The logic is located at : * Non Secure side tests: test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c * Secure side tests: test/suites/sst/secure/psa_ps_s_interface_testsuite.c Hope that helps Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 28 November 2019 14:49 To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Regression test issues with IAR port In my quest to port TF-M to the IAR toolchain I've run into issues with a few of the tests, and I need some hints where to look. The cmake build command line: --- cmake .. -G"Unix Makefiles" -DPROJ_CONFIG=C:\Users\thomasto\Projects\tf-m16\trusted-firmware-m\configs\ConfigRegression.cmake -DTARGET_PLATFORM=MUSCA_A -DCOMPILER=IARARM -DCMAKE_BUILD_TYPE=RelWithDebInfo --- This results in three similar tests that fails: --- > Executing 'TFM_SST_TEST_1018' Description: 'Get interface with invalid thread name' Get should not succeed with invalid thread name (Failed at C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c:936) TEST FAILED! > Executing 'TFM_SST_TEST_1019' Description: 'Get info interface with invalid thread name' Get info should not succeed with invalid thread name (Failed at C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c:1015) TEST FAILED! > Executing 'TFM_SST_TEST_1020' Description: 'Remove interface with invalid thread name' Remove should not succeed with invalid thread name (Failed at C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c:1093) TEST FAILED! --- Where do I find the logic that determines if these tests succeed or fails? Cheers, 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> <http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems> <http://www.twitter.com/iarsystems> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

2
1
0 0

Regression test issues with IAR port

by Thomas Törnblom

In my quest to port TF-M to the IAR toolchain I've run into issues with a few of the tests, and I need some hints where to look. The cmake build command line: --- cmake .. -G"Unix Makefiles" -DPROJ_CONFIG=C:\Users\thomasto\Projects\tf-m16\trusted-firmware-m\configs\ConfigRegression.cmake -DTARGET_PLATFORM=MUSCA_A -DCOMPILER=IARARM -DCMAKE_BUILD_TYPE=RelWithDebInfo --- This results in three similar tests that fails: --- > Executing 'TFM_SST_TEST_1018' Description: 'Get interface with invalid thread name' Get should not succeed with invalid thread name (Failed at C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c:936) TEST FAILED! > Executing 'TFM_SST_TEST_1019' Description: 'Get info interface with invalid thread name' Get info should not succeed with invalid thread name (Failed at C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c:1015) TEST FAILED! > Executing 'TFM_SST_TEST_1020' Description: 'Remove interface with invalid thread name' Remove should not succeed with invalid thread name (Failed at C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c:1093) TEST FAILED! --- Where do I find the logic that determines if these tests succeed or fails? Cheers, 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, 3 months

1
0
0 0

Re: [TF-M] PSA Certification without PS?

by Shebu Varghese Kuriakose

Hi Andrej/Kevin, Pasting the ;Secure Storage' Security Function Requirement below from the PSA Certified Level2 Protection Profile* It doesn’t specifically mention Protected Storage and Internal Trusted Storage Service as a requirement. As long as the Target of Evaluation can prove that the confidentiality and integrity of assets in Secure Storage can be maintained, the requirement can be met. PSA defines Protected Storage (PS)** and Internal Trusted Storage (ITS)**. PS is meant to store larger data sets stored on external flash and ITS for device intimate data stored on chip flash storage. If the device doesn’t have an on chip flash storage, maybe it is still possible to just use PS implementation using external flash to ensure confidentiality and integrity of the secret assets on the platform. @Marcus Streets<mailto:Marcus.Streets@arm.com> – Could you please share your thought on this >>> 5.3 F.SECURE_STORAGE The TOE protects the confidentiality and integrity of assets in a secure storage. The secure storage is bound to the platform. Only the TOE can retrieve and modify assets from this secure storage. This security function mitigates T.STORAGE by preventing direct and unprotected access to assets. >>> Regards, Shebu * https://www.psacertified.org/app/uploads/2019/02/JSADEN002-PSA_Certified_Le… ** https://developer.arm.com/-/media/Files/pdf/PlatformSecurityArchitecture/Im… -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Thursday, November 28, 2019 7:50 AM To: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] PSA Certification without PS? Hi Kevin, So, platforms without internal flash memory, required by Internal Trusted Storage, may apply only for PSA L1. Right? Thank you for your clarification, Andrej Butok -----Original Message----- From: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com<mailto:Kevin.Peng@arm.com>> Sent: Thursday, November 28, 2019 5:14 AM To: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.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] PSA Certification without PS? A quick information: Internal Trusted Storage is mandatory by PSA for isolation level 2 and 3. Best Regards, Kevin -----Original Message----- 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: Wednesday, November 27, 2019 7:32 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] PSA Certification without PS? Hello, Most probably, we will port TFM to a platform with TZ and external flash, BUT without internal flash. Is it possible to certify it for PSA L1 & L2 & Dev API, without Internal Trusted Storage service and its API? Do you see any issue? Thanks Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 3 months

3
3
0 0

Re: [TF-M] PSA Certification without PS?

by Kevin Peng (Arm Technology China)

A quick information: Internal Trusted Storage is mandatory by PSA for isolation level 2 and 3. Best Regards, Kevin -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Wednesday, November 27, 2019 7:32 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] PSA Certification without PS? Hello, Most probably, we will port TFM to a platform with TZ and external flash, BUT without internal flash. Is it possible to certify it for PSA L1 & L2 & Dev API, without Internal Trusted Storage service and its API? Do you see any issue? Thanks Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

2
1
0 0

Re: [TF-M] The svcall switch-case vs function table

by Anton Komlev

Hi Ken, all, Right, let's see the binary size of a prototype. Regarding TBB instruction, It's applied at the stage of binary generation, after source parsing and references resolution so it is irrelevant to the problem of dead references, I have mentioned. The best, Anton -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: 22 November 2019 10:23 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] The svcall switch-case vs function table Hi Anton, Thanks for the reminder. About code size, two points: - We saved code size for switch/case usage: switch(num) {case1:case2:} -> func_tbl[num].func(); - The compiler uses 'TBB' instruction, which is a function table already. So I think it should be okay; we can verify the code size after the prototype is available. BR /Ken -----Original Message----- From: Anton Komlev <Anton.Komlev(a)arm.com> Sent: Thursday, November 21, 2019 8:09 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com>; Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Subject: RE: The svcall switch-case vs function table Hi Ken, All, Just a reminder of a side-effect of array-based function table. It creates unconditional reference to a function and blocks that function from removal during code size optimization. TF-M is quite sensitive to binary image size and we should be very careful to avoid its increase. This is a general comment on functions table, irrelevant to the patch, where I have no knowledge yet to comment. The best, Anton -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: 14 November 2019 09:33 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] The svcall switch-case vs function table Hi, I am trying to look at into the svcall logics and found if we keep using the switch/case would make it hard to abstract this logic for different configurations. Thinking to move this static defined svc codes into an array-based function table. The pros are, the svc code set for different configurations is configurable, we don't need any #ifdef inside the svc numbers but rely on the configuration provided svc headers, and these headers are used inside configuration logic. And the overall svcall logic does not need to know the exact number definition but just do a f[num].func() call. The cons... I think the only thing is table may be out of date and cause a potential problem? or some function has only <4 parameter but we have to define a f(a0,a1,a2,a3) type function and fill extra parameter as zeros? This won't improve the execution efficiency if the svc numbers are continuous since compiler uses 'TBB' to create a mapping table while processing switch/case, so we can skip this point while talking pros. Welcome to comment or propose patches for this. Thanks. /Ken -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

PSA Certification without PS?

by Andrej Butok

Hello, Most probably, we will port TFM to a platform with TZ and external flash, BUT without internal flash. Is it possible to certify it for PSA L1 & L2 & Dev API, without Internal Trusted Storage service and its API? Do you see any issue? Thanks Andrej Butok

6 years, 3 months

1
0
0 0

Re: [TF-M] Coding guideline

by Anton Komlev

Hello, I do also support the move to loose the requirement of 80 columns. The real need is outdated and supported as a legacy style, making more trouble than help. The best, Anton -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Laurence Lundblade via TF-M Sent: 26 November 2019 21:12 To: Tamas Ban <Tamas.Ban(a)arm.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Coding guideline For line length I’m following these rules for t_cose <https://github.com/laurencelundblade/t_cose> - All comments blocks are 80 columns or less - 2% of code lines can be over 80 columns (1% is too few) - No lines over 120 columns I am much happier and think the code is much better by allowing 2% of code lines over 80 columns. I don’t have to make variable names short and obscure, break up if statements in unnatural places, break up for(;;) statements unnaturally and such. LL > On Nov 18, 2019, at 8:31 AM, Tamas Ban <Tamas.Ban(a)arm.com> wrote: > > Hi, > > I would like to open a conversation about TF-M coding guideline <https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/coding_gui…>. I have these proposals: > Change the rule of the 80 character column width: > Max 80 characters length. > Column length is max 80 character in first place, but there are exceptions when length could be MAX 120 character: > Degrades code understandability: short, obscured variable names; > awkward line breaks Maximum 1% of the lines can exceed 80 charter length. > Might remove this rule, because in many cases we are not complaint with it. For example PSA Crypto API: > o Order function parameters so that input params are before output params. > o https://git.trustedfirmware.org/trusted-firmware-m.git/tree/interface/inclu… <https://git.trustedfirmware.org/trusted-firmware-m.git/tree/interface/inclu…> > > I’m interested in your opinions! Other rules also can be revisited! > > Tamas -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Re: [TF-M] Using git submodules for dependencies?

by Gyorgy Szing

Hi, Build environment provisioning (and dependency management) is a larger topic and sub-modules can only solve a small part of it. There is definitely room for improvement in this area, but as far as I can see sub-modules are a sub optimal answer. Some of the issues which came to my mind: 1. The user experience of sub-modules is sometimes quirky. For example it is a headache if you have to switch between branches where one of the branches does not have a specific sub-module. 2. With sub-modules you can not have complex dependencies. I.e.: when one platform needs a dependency and another not, or you need two version of a dependency, or a different version for two platforms. 3. It is easy to see on what the repo having the sub-module depends, but the other direction is not. It is hard to see what is using a module. 4. The validness of tests are limited if you use source code. Longer term it would be nice to allow using tested binaries of tf-m dependencies and sub-modules can not handle this need. 5. Flexibility. If we use sub-modules, then the version control and the dependency handling "layers" get bounded. For tf-m developers this might not be an issue but for integrators it can be. Can you please explain the problem you see a bit more? Zephyr is using cmake and you could use the External_project or the FetchContent module to get all needed dependencies. Also nothing really stops you to use sub-modules in the Zephyr repo to get tf-m and all it's dependencies. /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: 26 November 2019 19:23 To: Kumar Gala <kumar.gala(a)linaro.org> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Using git submodules for dependencies? Hi, I'm reviving an old thread (sorry, probably bad form), but we're running into this issue again now with Zephyr (and probably with FreeRTOS later) where we need to produce a TF-M 'module' got Zephyr that we can include in the zephyr github repo. With the current approach for TF-M, we will have to produce 5 forks of the 5 projects/dependencies, which seems superfluous versus a single 'master' TF-M repo with the four dependencies as sub-modules, and I can't see why technically this would be more of a challenge for end-users (you can even init the submodules at the same time you clone the parent TF-M repo so it's actually LESS work), and means a single repo where all of the dependency versions can change over time in sync with the various releases. I may be missing or misunderstanding an obvious technical drawback made earlier, but I haven't understand why submodules are less desirable than 1+4 independent repos both for TF-M and any projects on the RTOS side depending on it? Kevin On Wed, 10 Jul 2019 at 18:09, Kumar Gala via TF-M < tf-m(a)lists.trustedfirmware.org> wrote: > How would a git repo with some submodules preclude any of the things > you mentioned? I guess my initial thought is that there would be an “uber” > repo in which TFM, CMSIS and mbedcrypto would all be sub-modules. > > There’s also the option of using cmake ExternalProject ( > https://cmake.org/cmake/help/latest/module/ExternalProject.html?highli > ght=external > ) > > Or west > > https://pypi.org/project/west/ > > - k > > > On Jul 10, 2019, at 8:47 AM, Ashutosh Singh via TF-M < > tf-m(a)lists.trustedfirmware.org> wrote: > > > > Hi, > > > > Initial idea was to keep the external dependencies clearly visible > > (from > code auditability point of view). With submodule we can't checkout the > dependencies out of tree. Since the dependencies need to be checked > out only once it was considered acceptable nuisance, until you do a > pull and version of the dependencies have changed. > > 'repo' was considered as well, but repo tool doesn't work on > windows(last I checked). > > > > Thanks, > > Ashu > > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > > Kumar > Gala via TF-M > > Sent: 10 July 2019 09:50 > > To: Andrej Butok <andrey.butok(a)nxp.com> > > Cc: tf-m(a)lists.trustedfirmware.org > > Subject: Re: [TF-M] Using git submodules for dependencies? > > > > There can always be a fork of the sources kept in TF-M repos to > > handle > the case of needing local modifications for some reason. > > > > - k > > > >> On Jul 10, 2019, at 3:48 AM, Andrej Butok via TF-M < > tf-m(a)lists.trustedfirmware.org> wrote: > >> > >> Hi Kevin, > >> > >> Only if 100% of the external project source code is used without > change. > >> Even if it is valid now, nobody will give you this guarantee in future. > >> > >> Regards, > >> Andrej > >> > >> -----Original Message----- > >> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > >> Kevin > Townsend via TF-M > >> Sent: Wednesday, July 10, 2019 10:41 AM > >> To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> > >> Subject: [TF-M] Using git submodules for dependencies? > >> > >> Hi, > >> > >> I'm currently working on integrating TF-M into Zephyr and getting > >> TF-M > working with QEMU. Part of that work is simplifying the setup and > build process to generate a TF-M secure library. > >> > >> Was the idea of git submodules for dependencies considered and rejected? > >> Using sub-modules would reduce the number of setup steps required, > >> and > pair external dependency versions with specific TF-M commits/releases. > >> > >> There may be a valid reason this approach was rejected, but it > >> seems > like a sensible option on the surface? > >> > >> Best regards, > >> Kevin Townsend > >> -- > >> TF-M mailing list > >> TF-M(a)lists.trustedfirmware.org > >> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-m&data=02%7C01%7Ca > ndrey.butok%40nxp.com%7C04856a3b68604d01153208d705124e6a%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636983448498201722&sdata=IjOFM44xG > bA2Zgrj%2F2VSmHEYLuXvMzqS7HH6h7gekF4%3D&reserved=0 > >> -- > >> TF-M mailing list > >> TF-M(a)lists.trustedfirmware.org > >> https://lists.trustedfirmware.org/mailman/listinfo/tf-m > > > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Coding guideline

by Tamas Ban

Hi, I would like to open a conversation about TF-M coding guideline<https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/coding_gui…>. I have these proposals: * Change the rule of the 80 character column width: * Max 80 characters length. * Column length is max 80 character in first place, but there are exceptions when length could be MAX 120 character: * Degrades code understandability: short, obscured variable names; awkward line breaks * Maximum 1% of the lines can exceed 80 charter length. * Might remove this rule, because in many cases we are not complaint with it. For example PSA Crypto API: o Order function parameters so that input params are before output params. o https://git.trustedfirmware.org/trusted-firmware-m.git/tree/interface/inclu… I'm interested in your opinions! Other rules also can be revisited! Tamas

6 years, 3 months

2
1
0 0

Re: [TF-M] Using git submodules for dependencies?

by Kevin Townsend

Hi, I'm reviving an old thread (sorry, probably bad form), but we're running into this issue again now with Zephyr (and probably with FreeRTOS later) where we need to produce a TF-M 'module' got Zephyr that we can include in the zephyr github repo. With the current approach for TF-M, we will have to produce 5 forks of the 5 projects/dependencies, which seems superfluous versus a single 'master' TF-M repo with the four dependencies as sub-modules, and I can't see why technically this would be more of a challenge for end-users (you can even init the submodules at the same time you clone the parent TF-M repo so it's actually LESS work), and means a single repo where all of the dependency versions can change over time in sync with the various releases. I may be missing or misunderstanding an obvious technical drawback made earlier, but I haven't understand why submodules are less desirable than 1+4 independent repos both for TF-M and any projects on the RTOS side depending on it? Kevin On Wed, 10 Jul 2019 at 18:09, Kumar Gala via TF-M < tf-m(a)lists.trustedfirmware.org> wrote: > How would a git repo with some submodules preclude any of the things you > mentioned? I guess my initial thought is that there would be an “uber” > repo in which TFM, CMSIS and mbedcrypto would all be sub-modules. > > There’s also the option of using cmake ExternalProject ( > https://cmake.org/cmake/help/latest/module/ExternalProject.html?highlight=e… > ) > > Or west > > https://pypi.org/project/west/ > > - k > > > On Jul 10, 2019, at 8:47 AM, Ashutosh Singh via TF-M < > tf-m(a)lists.trustedfirmware.org> wrote: > > > > Hi, > > > > Initial idea was to keep the external dependencies clearly visible (from > code auditability point of view). With submodule we can't checkout the > dependencies out of tree. Since the dependencies need to be checked out > only once it was considered acceptable nuisance, until you do a pull and > version of the dependencies have changed. > > 'repo' was considered as well, but repo tool doesn't work on > windows(last I checked). > > > > Thanks, > > Ashu > > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kumar > Gala via TF-M > > Sent: 10 July 2019 09:50 > > To: Andrej Butok <andrey.butok(a)nxp.com> > > Cc: tf-m(a)lists.trustedfirmware.org > > Subject: Re: [TF-M] Using git submodules for dependencies? > > > > There can always be a fork of the sources kept in TF-M repos to handle > the case of needing local modifications for some reason. > > > > - k > > > >> On Jul 10, 2019, at 3:48 AM, Andrej Butok via TF-M < > tf-m(a)lists.trustedfirmware.org> wrote: > >> > >> Hi Kevin, > >> > >> Only if 100% of the external project source code is used without > change. > >> Even if it is valid now, nobody will give you this guarantee in future. > >> > >> Regards, > >> Andrej > >> > >> -----Original Message----- > >> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin > Townsend via TF-M > >> Sent: Wednesday, July 10, 2019 10:41 AM > >> To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> > >> Subject: [TF-M] Using git submodules for dependencies? > >> > >> Hi, > >> > >> I'm currently working on integrating TF-M into Zephyr and getting TF-M > working with QEMU. Part of that work is simplifying the setup and build > process to generate a TF-M secure library. > >> > >> Was the idea of git submodules for dependencies considered and rejected? > >> Using sub-modules would reduce the number of setup steps required, and > pair external dependency versions with specific TF-M commits/releases. > >> > >> There may be a valid reason this approach was rejected, but it seems > like a sensible option on the surface? > >> > >> Best regards, > >> Kevin Townsend > >> -- > >> TF-M mailing list > >> TF-M(a)lists.trustedfirmware.org > >> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… > >> -- > >> TF-M mailing list > >> TF-M(a)lists.trustedfirmware.org > >> https://lists.trustedfirmware.org/mailman/listinfo/tf-m > > > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m >

6 years, 3 months

1
0
0 0

Design proposal for enabling byte-aligned flash devices.

by Minos Galanakis

Hi all, I have recently submitted the following design proposal, currently under review, which is aimed at enabling byte-aligned flash devices on TF-M https://review.trustedfirmware.org/c/trusted-firmware-m/+/2392 Any feedback, suggestions would be greatly appreciated. Regards, Minos Galanakis

6 years, 3 months

1
0
0 0

Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure

by David Hu (Arm Technology China)

Hi Qixiang, It is a very reasonable suggestion. I will write it down as a further improvement. Thanks a lot. Best regards, Hu Ziji -----Original Message----- From: Qixiang Xu (Arm Technology China) Sent: Tuesday, November 26, 2019 2:18 PM To: David Hu (Arm Technology China) <David.Hu(a)arm.com>; Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com>; Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com>; tf-m(a)lists.trustedfirmware.org. Cc: nd <nd(a)arm.com> Subject: RE: [RFC] Re-organize the TF-M platform folder structure Hi David, When we add a platform into the TF-M, we need modify the top makefile to add it into build the system build, maybe we can consider to fix this issue at the same time. My proposal has changed a little from your proposal: ├── ext │ ├── arm │ │ ├── common │ │ │ └── arm_common.c │ │ ├── mps2 │ │ │ ├── an519 │ │ │ │ ├── an519.c │ │ │ │ └── plat.cmake │ │ │ ├── an521 │ │ │ │ ├── an521.c │ │ │ │ └── plat.cmake │ │ │ ├── an539 │ │ │ │ ├── an539.c │ │ │ │ └── plat.cmake │ │ │ ├── mps2.cmake │ │ │ └── mps2_common.c │ │ ├── mps3 │ │ │ ├── an524 │ │ │ │ ├── an524.c │ │ │ │ └── plat.cmake │ │ │ ├── mps3.cmake │ │ │ └── mps3_common.c │ │ └── musca │ │ ├── a │ │ │ ├── a.c │ │ │ └── plat.cmake │ │ ├── b1 │ │ │ ├── b1.c │ │ │ └── plat.cmake │ │ ├── musca.cmake │ │ ├── musca_common.c │ │ └── s1 │ │ ├── plat.cmake │ │ └── s1.c │ └── vendor1 │ ├── board1 │ │ ├── board1.cmake │ │ ├── board1_common.c │ │ ├── var1 │ │ │ ├── plat.cmake │ │ │ └── var1.c │ │ └── var2 │ │ ├── plat.cmake │ │ └── var2.c │ ├── board2 │ │ ├── board1.cmake │ │ ├── board1_common.c │ │ ├── var1 │ │ │ ├── plat.cmake │ │ │ └── var1.c │ │ └── var2 │ │ ├── plat.cmake │ │ └── var2.c │ └── common │ └── vendor1_common.c In the different vendor, we have different boards and the board have different variants, so the plat.cmake can include the boardx.cmake and the boardx.cmake can include the vendorx.cmake. To build the TF-M, we change the command line from PLAT=xxxx to PLAT=vendorX/boardY/varZ. The top makefile finds the plat.cmake from the platform directory with PLAT variable which passed by command line. So we don't need touch the top makefile when we add a new platform. Thanks. Best Regards, Qixiang Xu -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Tuesday, November 26, 2019 11:05 AM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com>; Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi Edison, IMO, `target` folder is still required to separate the platforms from common files and drivers. Best regards, Hu Ziji -----Original Message----- From: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Sent: Monday, November 25, 2019 11:48 AM To: David Hu (Arm Technology China) <David.Hu(a)arm.com>; Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: [RFC] Re-organize the TF-M platform folder structure Hi David, Support the idea to support more different platforms and common drivers. One suggestion for your proposal, is it necessary to add the "target" folders? It looks like we can short the folder depth. What about this? Platform |-- ext | |--Partner ABC | | |-- *common drivers and files* | | |-- target_abc_1 | | | |-- target_abc_1.cmake | | |-- target_abc_2 | | | |-- Partner XYZ | | |-- *common drivers and files* | | |-- target_xyz_1 | | | |-- target_xyz_1.cmake | | |-- target_xyz_2 | |-- ... |--include Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Monday, November 25, 2019 10:33 AM To: Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi Andrei, Thanks a lot for the positive feedback. Adding another common layer for all the partners sounds similar to Andrej's proposal. In my very own opinion, currently CMSIS can cover the general arch features. The general multi-core mailbox code is kept in TF-M Core. But I won't be surprised if additional common features should be extracted and kept under platform folder. Apparently, we need more partners/platforms on TF-M to specify the requirements. I'd suggest that we can discuss the additional common part as another topic in a separated email thread. Best regards, Hu Ziji -----Original Message----- From: Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com> Sent: Saturday, November 23, 2019 3:49 AM To: David Hu (Arm Technology China) <David.Hu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: [RFC] Re-organize the TF-M platform folder structure Hi David, I support this idea as it is a quick and easy solution for the growing list of supported platforms. Perhaps, I would also add another common layer in platform/ext/target to keep platform code that can be reused by other partners in their platforms - for the multicore mailbox code, for example. Thanks, Andrei -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Tuesday, November 19, 2019 7:20 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi all, I'd like to propose to adjust the platform folder structure. Would you please check the details below and share your opinions? Any suggestion or feedback will be very helpful. In current platform folder structure, all the targets are listed together at the same level under `target` folder. Platform |-- ext |-- . |-- target_xxx.cmake |-- . |-- target_zzz.cmake |-- target |-- mps2 |-- musca_a |-- . A drawback is that, there are many duplicated files in those targets folders. It may become difficult to maintain the target support when targets, platforms, drivers and features continue growing. - A platform may have a series of variants. If each variant target folder has to contain a copy of platform drivers or library, it is difficult to align and maintain the duplicated drivers. - All targets belonging to the same platform contain the duplicated common operation files or configurations, such as HUK, NV counter and platform configurations. A small change has to be applied to multiple identical files. To solve the duplicated files management issue, I'd propose to insert partner folders under `target` and move the targets under the partner folder. The proposed structure looks like the following: Z` The ideas behind the proposal: - It is more close to the platform support structure in popular RTOSs. It can be more convenient for partners to port platform support to TF-M from existing projects. - Common drivers and operations implementations can be gathered into partner/platform specific folder. Thus each partner/platform folder doesn't have to hold a duplicated copy. - It is easier for partners to fully organize and maintain their platform folders with full permission. More layers can be added under a specific partner folder, such as diverse platforms. - Put the target specific cmake config file back into the target folder. It can make the `platform` folder much more clear. Best regards, Hu Ziji -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m 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. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Re: [TF-M] Including board-specific libraries in TF-M

by Tamas Ban

Hi Kevin, Currently there is no established pattern how to link a library to secure code on platform level. Currently only services and crypto libraries are built as libraries but not platform code. I think the suggested solution (put a `target_link_libraries` entry in that platform/ext/*.cmake file) is feasible, because the platform level cmake files are included by the secure_fw/CMakeList.txt (through CommonConfig.cmake) and in this way the library will be linked to secure code. We have similar solution in case of CC312 library integration: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2526/6/platform… Tamas -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: 25 November 2019 16:47 To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Including board-specific libraries in TF-M Hi, While working on upstreaming support for a new MCU in TF-M, I've bumped into a requirement to link against an external library that's required for the device init sequence. I may (or may not) be able to remove this dependency, but is there currently a cross-platform mechanism to link .a files (etc.) during the build process at the platform/ext/*.cmake level? It's possible to put something together for this one target ('target_link_libraries'???), but I was wondering if I'm missing an instance where this is handled at a higher level, similar to how the RTX library is handled in the same makefiles: if (DEFINED CMSIS_5_DIR) # Not all projects define CMSIS_5_DIR, only the ones that use it. set(RTX_LIB_PATH "${CMSIS_5_DIR}/CMSIS/RTOS2/RTX/Library/GCC/libRTX_V8MMN.a") endif() Best regards, Kevin -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure

by Qixiang Xu (Arm Technology China)

Correct the mail list address to send it again. -----Original Message----- From: Qixiang Xu (Arm Technology China) Sent: Tuesday, November 26, 2019 2:18 PM To: David Hu (Arm Technology China) <David.Hu(a)arm.com>; Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com>; Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com>; tf-m(a)lists.trustedfirmware.org. Cc: nd <nd(a)arm.com> Subject: RE: [RFC] Re-organize the TF-M platform folder structure Hi David, When we add a platform into the TF-M, we need modify the top makefile to add it into build the system build, maybe we can consider to fix this issue at the same time. My proposal has changed a little from your proposal: ├── ext │ ├── arm │ │ ├── common │ │ │ └── arm_common.c │ │ ├── mps2 │ │ │ ├── an519 │ │ │ │ ├── an519.c │ │ │ │ └── plat.cmake │ │ │ ├── an521 │ │ │ │ ├── an521.c │ │ │ │ └── plat.cmake │ │ │ ├── an539 │ │ │ │ ├── an539.c │ │ │ │ └── plat.cmake │ │ │ ├── mps2.cmake │ │ │ └── mps2_common.c │ │ ├── mps3 │ │ │ ├── an524 │ │ │ │ ├── an524.c │ │ │ │ └── plat.cmake │ │ │ ├── mps3.cmake │ │ │ └── mps3_common.c │ │ └── musca │ │ ├── a │ │ │ ├── a.c │ │ │ └── plat.cmake │ │ ├── b1 │ │ │ ├── b1.c │ │ │ └── plat.cmake │ │ ├── musca.cmake │ │ ├── musca_common.c │ │ └── s1 │ │ ├── plat.cmake │ │ └── s1.c │ └── vendor1 │ ├── board1 │ │ ├── board1.cmake │ │ ├── board1_common.c │ │ ├── var1 │ │ │ ├── plat.cmake │ │ │ └── var1.c │ │ └── var2 │ │ ├── plat.cmake │ │ └── var2.c │ ├── board2 │ │ ├── board1.cmake │ │ ├── board1_common.c │ │ ├── var1 │ │ │ ├── plat.cmake │ │ │ └── var1.c │ │ └── var2 │ │ ├── plat.cmake │ │ └── var2.c │ └── common │ └── vendor1_common.c In the different vendor, we have different boards and the board have different variants, so the plat.cmake can include the boardx.cmake and the boardx.cmake can include the vendorx.cmake. To build the TF-M, we change the command line from PLAT=xxxx to PLAT=vendorX/boardY/varZ. The top makefile finds the plat.cmake from the platform directory with PLAT variable which passed by command line. So we don't need touch the top makefile when we add a new platform. Thanks. Best Regards, Qixiang Xu -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Tuesday, November 26, 2019 11:05 AM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com>; Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi Edison, IMO, `target` folder is still required to separate the platforms from common files and drivers. Best regards, Hu Ziji -----Original Message----- From: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Sent: Monday, November 25, 2019 11:48 AM To: David Hu (Arm Technology China) <David.Hu(a)arm.com>; Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: [RFC] Re-organize the TF-M platform folder structure Hi David, Support the idea to support more different platforms and common drivers. One suggestion for your proposal, is it necessary to add the "target" folders? It looks like we can short the folder depth. What about this? Platform |-- ext | |--Partner ABC | | |-- *common drivers and files* | | |-- target_abc_1 | | | |-- target_abc_1.cmake | | |-- target_abc_2 | | | |-- Partner XYZ | | |-- *common drivers and files* | | |-- target_xyz_1 | | | |-- target_xyz_1.cmake | | |-- target_xyz_2 | |-- ... |--include Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Monday, November 25, 2019 10:33 AM To: Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi Andrei, Thanks a lot for the positive feedback. Adding another common layer for all the partners sounds similar to Andrej's proposal. In my very own opinion, currently CMSIS can cover the general arch features. The general multi-core mailbox code is kept in TF-M Core. But I won't be surprised if additional common features should be extracted and kept under platform folder. Apparently, we need more partners/platforms on TF-M to specify the requirements. I'd suggest that we can discuss the additional common part as another topic in a separated email thread. Best regards, Hu Ziji -----Original Message----- From: Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com> Sent: Saturday, November 23, 2019 3:49 AM To: David Hu (Arm Technology China) <David.Hu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: [RFC] Re-organize the TF-M platform folder structure Hi David, I support this idea as it is a quick and easy solution for the growing list of supported platforms. Perhaps, I would also add another common layer in platform/ext/target to keep platform code that can be reused by other partners in their platforms - for the multicore mailbox code, for example. Thanks, Andrei -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Tuesday, November 19, 2019 7:20 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi all, I'd like to propose to adjust the platform folder structure. Would you please check the details below and share your opinions? Any suggestion or feedback will be very helpful. In current platform folder structure, all the targets are listed together at the same level under `target` folder. Platform |-- ext |-- . |-- target_xxx.cmake |-- . |-- target_zzz.cmake |-- target |-- mps2 |-- musca_a |-- . A drawback is that, there are many duplicated files in those targets folders. It may become difficult to maintain the target support when targets, platforms, drivers and features continue growing. - A platform may have a series of variants. If each variant target folder has to contain a copy of platform drivers or library, it is difficult to align and maintain the duplicated drivers. - All targets belonging to the same platform contain the duplicated common operation files or configurations, such as HUK, NV counter and platform configurations. A small change has to be applied to multiple identical files. To solve the duplicated files management issue, I'd propose to insert partner folders under `target` and move the targets under the partner folder. The proposed structure looks like the following: Z` The ideas behind the proposal: - It is more close to the platform support structure in popular RTOSs. It can be more convenient for partners to port platform support to TF-M from existing projects. - Common drivers and operations implementations can be gathered into partner/platform specific folder. Thus each partner/platform folder doesn't have to hold a duplicated copy. - It is easier for partners to fully organize and maintain their platform folders with full permission. More layers can be added under a specific partner folder, such as diverse platforms. - Put the target specific cmake config file back into the target folder. It can make the `platform` folder much more clear. Best regards, Hu Ziji -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m 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. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m 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, 3 months

1
0
0 0

Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure

by Edison Ai (Arm Technology China)

Hi David, Support the idea to support more different platforms and common drivers. One suggestion for your proposal, is it necessary to add the "target" folders? It looks like we can short the folder depth. What about this? Platform |-- ext | |--Partner ABC | | |-- *common drivers and files* | | |-- target_abc_1 | | | |-- target_abc_1.cmake | | |-- target_abc_2 | | | |-- Partner XYZ | | |-- *common drivers and files* | | |-- target_xyz_1 | | | |-- target_xyz_1.cmake | | |-- target_xyz_2 | |-- ... |--include Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Monday, November 25, 2019 10:33 AM To: Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi Andrei, Thanks a lot for the positive feedback. Adding another common layer for all the partners sounds similar to Andrej's proposal. In my very own opinion, currently CMSIS can cover the general arch features. The general multi-core mailbox code is kept in TF-M Core. But I won't be surprised if additional common features should be extracted and kept under platform folder. Apparently, we need more partners/platforms on TF-M to specify the requirements. I'd suggest that we can discuss the additional common part as another topic in a separated email thread. Best regards, Hu Ziji -----Original Message----- From: Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com> Sent: Saturday, November 23, 2019 3:49 AM To: David Hu (Arm Technology China) <David.Hu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: [RFC] Re-organize the TF-M platform folder structure Hi David, I support this idea as it is a quick and easy solution for the growing list of supported platforms. Perhaps, I would also add another common layer in platform/ext/target to keep platform code that can be reused by other partners in their platforms - for the multicore mailbox code, for example. Thanks, Andrei -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Tuesday, November 19, 2019 7:20 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi all, I'd like to propose to adjust the platform folder structure. Would you please check the details below and share your opinions? Any suggestion or feedback will be very helpful. In current platform folder structure, all the targets are listed together at the same level under `target` folder. Platform |-- ext |-- . |-- target_xxx.cmake |-- . |-- target_zzz.cmake |-- target |-- mps2 |-- musca_a |-- . A drawback is that, there are many duplicated files in those targets folders. It may become difficult to maintain the target support when targets, platforms, drivers and features continue growing. - A platform may have a series of variants. If each variant target folder has to contain a copy of platform drivers or library, it is difficult to align and maintain the duplicated drivers. - All targets belonging to the same platform contain the duplicated common operation files or configurations, such as HUK, NV counter and platform configurations. A small change has to be applied to multiple identical files. To solve the duplicated files management issue, I'd propose to insert partner folders under `target` and move the targets under the partner folder. The proposed structure looks like the following: Platform |-- ext |-- target | |-- Partner ABC | |-- *common drivers and files* | |-- target_abc_1 | | |-- target_abc_1.cmake | |-- target_abc_2 | |-- Partner XYZ | |-- *common drivers and files* | |-- target_xyz_1 | | |-- target_xyz_1.cmake | |-- target_xyz_2 |-- ... The ideas behind the proposal: - It is more close to the platform support structure in popular RTOSs. It can be more convenient for partners to port platform support to TF-M from existing projects. - Common drivers and operations implementations can be gathered into partner/platform specific folder. Thus each partner/platform folder doesn't have to hold a duplicated copy. - It is easier for partners to fully organize and maintain their platform folders with full permission. More layers can be added under a specific partner folder, such as diverse platforms. - Put the target specific cmake config file back into the target folder. It can make the `platform` folder much more clear. Best regards, Hu Ziji -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m 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. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

2
1
0 0

Including board-specific libraries in TF-M

by Kevin Townsend

Hi, While working on upstreaming support for a new MCU in TF-M, I've bumped into a requirement to link against an external library that's required for the device init sequence. I may (or may not) be able to remove this dependency, but is there currently a cross-platform mechanism to link .a files (etc.) during the build process at the platform/ext/*.cmake level? It's possible to put something together for this one target ('target_link_libraries'???), but I was wondering if I'm missing an instance where this is handled at a higher level, similar to how the RTX library is handled in the same makefiles: if (DEFINED CMSIS_5_DIR) # Not all projects define CMSIS_5_DIR, only the ones that use it. set(RTX_LIB_PATH "${CMSIS_5_DIR}/CMSIS/RTOS2/RTX/Library/GCC/libRTX_V8MMN.a") endif() Best regards, Kevin

6 years, 3 months

1
0
0 0

Re: [TF-M] Python script to generate tf-m dependencies in JSON format

by Devaraj Ranganna

Hi, Thanks for your inputs. The original intention of the script was to not to modify the origin of the information i.e rst file as Minos quoted and also to avoid duplication of information. Considering all the new information, I think we should try to separate build and post-build dependencies (ex: srec_cat). This separation will allow us to handle all the build dependencies using "cmake" and then we can explore the possible option on how to handle post-build dependencies. @Minos, I believe all sw dependencies defined in https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… are already validated in cmake. Adding other library dependencies into it will make it complete. This way we don’t need mention library dependency in document anymore and still achieve single source of information. @George, I think first 3 question can be answered if we decide to go ahead with handling build dependencies with cmake. Thanks, Dev On 21/10/2019, 15:56, "TF-M on behalf of Gyorgy Szing via TF-M" <tf-m-bounces(a)lists.trustedfirmware.org on behalf of tf-m(a)lists.trustedfirmware.org> wrote: Hi, We need to keep an eye on some factors which the current prototype ignores. Some that come to my mind: 1. which component shall be the owner of sw dependency info? (Documentation, cmake, something else?). 2. how does the solution scale? (i.e. be able to handle platform specific dependencies). 3. how we handle build configuration specific dependencies? (i.e. if I don't build a service then some dependency is not needed). 4. As Minos mentioned some environment verification is already done by CMake. Is it worth to extract all dependency info (tooling + SW) into a dedicated place? /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Minos Galanakis via TF-M Sent: 21 October 2019 16:47 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Python script to generate tf-m dependencies in JSON format Hi, Making CMAKE able to output the dependencies it is expecting is the quickest path, but it is only able to resolve a subset of the requirements captured by the documenation. .<https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…> For example the cmake version itself, or tools like srec_cat used to produce MUSCA binaries. There are certain dependencies that are provided by other means ( package managers ) . So while I agree that it looks quite odd, it is hierarchically the origin of the information we are trying to capture. Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Kumar Gala via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 21 October 2019 15:25 To: Devaraj Ranganna <Devaraj.Ranganna(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] Python script to generate tf-m dependencies in JSON format This feels backwards, parsing rst to determine build steps, dependancies doesn’t feel correct. I think it would be better to codify the build steps in scripts of CMake, etc than reference those in the .rst instead. - k > On Oct 21, 2019, at 9:03 AM, Devaraj Ranganna via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi, > > Currently tf-m dependencies are only listed in documentation file (docs/user_guides/tfm_build_instruction.rst) and there is no option to programmatically retrieve it. In order to integrate tf-m into non-secure side RTOSes, it is very essential to be able build tf-m automatically without manual intervention (may be as part of CI). > > The tf-m CI build system uses fixed values for dependencies and it is the responsibility of developers who update the dependencies to update the documentation and the CI build system. > > If non-secure side RTOSes use fix values for tf-m dependencies then either build or regression tests may fail when tf-m updates dependencies. In order avoid this issue, I’m proposing the following > > > * Use a reStructuredText grid table to define dependencies > * Python script to produce a json file in the root directory when invoked as standalone script or to return a json string when imported into another python script > > I’ve created a patch set (https://review.trustedfirmware.org/c/trusted-firmware-m/+/2333) with above changes. I’d appreciate your inputs/feedback on this proposal. > > This will also ensure that dependencies are captured in one place (docs/user_guides/tfm_build_instruction.rst). > > Additionally, have another python script as “post-checkout” git hook which can parse dependencies in JSON format and clone them automatically when tf-m repository is cloned or when switching from master to feature branch and vice versa. > > 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. > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

2
5
0 0

Re: [TF-M] [EXTERNAL] RE: secure interrupt handlng in IPC mode

by Adrian Shaw

Page 43 of the PSA Firmware Framework states the following: 1. Even when using these techniques, the latency involved in scheduling a Secure Partition to handle interrupts might not be acceptable for certain types of peripheral. The SPM can implement its own independent device driver model, which provides improved response latency, however, this comes at the cost of portability and security. The SPM’s independent device driver model is not within the scope of this specification. So you are allowed (if you want to implement it in an SP). Best, Adrian On 19 Nov 2019, at 08:07, Edison Ai (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: Hi Alan, Thanks for your information. So I think there are 2 discussion here: 1. You had met unexpected behavior when a secure interrupt is configured with a lower priority than pendsv. As I understand, if you just move the pendsv in a higher priority, it should be ok. Just as I say in former mail that the pendsv handler will be processed every time, but it still can works. In this case, the 'd' point you list should not extend to SP. 2. You say that "the SP while it is processing the ISR". Do you mean you want to add a SP ISR? Right? please correct me if it is not. If so the current discussion should be if it is allowed to process ISR in SP: - If allow, "A NSPE interrupt is not allowed to preempt SPE ISR" could be understood as a NSPE interrupt is not allowed to preempt SP ISR. So I think this why you assume the SPE needs to be restored to the IDLE state. - If no. you assume will not reasonable. I think the answer should be NO. PSA FF gives us several APIs to process the interrupt: psa_wait, psa_get, psa_eoi based on the message in the IPC model. In this mechanism, ISR needs to send a signal to SP and let SP process data after scheduling. It is cleaner and security. Thanks, Edison -----Original Message----- From: DeMars, Alan <ademars(a)ti.com<mailto:ademars@ti.com>> Sent: Friday, November 15, 2019 4:48 AM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com<mailto:Edison.Ai@arm.com>> Cc: 'tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: RE: [EXTERNAL] RE: secure interrupt handlng in IPC mode I don't know that the SPE needs to be restored to its IDLE state prior to a thread pre-empting NS interrupt occurring. I just assumed that these 2 rules required it: a. All of the SPE interrupts must have higher priority than NSPE interrupts d. A NSPE interrupt is not allowed to preempt SPE ISR (I assumed that this rule applies to the SP while it is processing the ISR as well). Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Thursday, November 14, 2019 12:58 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd Subject: Re: [TF-M] [EXTERNAL] RE: secure interrupt handlng in IPC mode Hi Alan, I have one question, why the SPE needs restored to its IDLE state prior to a thread pre-empting NS interrupt occurring? About a secure interrupt is configured with a lower priority than pendsv, I do not think it is a good idea. The pendsv is used to trigger the scheduler to switch thread. The normal interrupt process should like this: Interrupt happen -> jump into related ISR -> do necessary process such as mask interrupt status, send even or signal to related SP. -> set pendsv to trigger scheduler -> jump out ISR -> scheduler to decide which thread to run. In these sequences, if there are many interrupts happen at the same time, and high priority interrupt will interrupt low priority interrupt. Each ISR will trigger pendsv. But only one pendsv hander function needs to be processed. If we set the pendsv with high priority. Each interrupt will trigger pendsv and the pendsv handler will be processed every time. It will be more complex and spend more CPU time. Sorry that I do not know what is your detail scenario, and it will be more clear and helpful if you can provide more information. Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Thursday, November 14, 2019 3:12 PM 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] [EXTERNAL] RE: secure interrupt handlng in IPC mode Hi Alan, I have created the cooperative scheduling doc link here for comment: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2466 BR /Ken -----Original Message----- From: DeMars, Alan <ademars(a)ti.com> Sent: Thursday, November 14, 2019 10:44 AM To: Mate Toth-Pal <Mate.Toth-Pal(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com>; Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Subject: Re: [EXTERNAL] RE: secure interrupt handlng in IPC mode Mate, Apart from the surprising behavior actually working to my benefit, my concern is the implications of violating the Cooperative Scheduling Rules I quoted below. The normal behavior (ie the SP running in thread mode with no exception priority when servicing a secure interrupt) seems to violate those rules. Is this a problem for the scheduler? Alan On Nov 13, 2019, at 5:08 AM, Mate Toth-Pal <Mate.Toth-Pal(a)arm.com> wrote: Hi Alan, That's a quite difficult question I think. At first look, it seems a to be a valid thinking that a secure partition that is handling an IRQ signal should be considered as an SPE ISR. However implementing this seems to be a nontrivial task. The code in the secure partitions is organised into a single thread, that executes a while loop, calls 'psa_wait()' in every iteration, and acts on the signals returned by it. The phenomenon we observed with your setup was the following: 1. When the Handler mode interrupt handler, that had lower priority than the PendSV reenabled interrupts after setting the signal, was interrupted by the PendSV handler. 2. PendSV handler scheduled the partition with the interrupt signal set, and did an exception return to thread mode. 3. The code of the Secure partition thread started executing, in Thread mode, but with the priority of the interrupt from the first point, as that interrupt handler was interrupted before it could do exception return to acknowledge the handling of the interrupt in the NVIC. 4. After the partition thread code called psa_wait again, the scheduler restored the context of the interrupt handler from the first point, that handler did an exception return, and everything is 'back to normal' Now, if I understand properly, your proposal is to make the conditions in point 3. to be mandatory for any scheduler implementation. To make this happen in TF-M, all the secure interrupts should have lower priority than the PendSV handler. This is necessary so that the above detailed behaviour is valid for all the interrupts. The problem with this is that the SPM has no control over which signal the code of the secure partition is going to execute. So in the current design a secure partition might decide to handle a service call signal (if there is any) instead of an IRQ signal, and that would be against our intention. We might be able to modify psa_wait to return only IRQ signals if there is any active, but that would be a violation of the PSA FF spec. Regards, Mate From: DeMars, Alan <ademars(a)ti.com> Sent: 12 November 2019 17:47 To: Mate Toth-Pal <Mate.Toth-Pal(a)arm.com> Cc: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Subject: RE: secure interrupt handlng in IPC mode You can CC the tf-m mailing list. From: Mate Toth-Pal [mailto:Mate.Toth-Pal@arm.com] Sent: Tuesday, November 12, 2019 8:02 AM To: DeMars, Alan Cc: Ken Liu (Arm Technology China) Subject: [EXTERNAL] RE: secure interrupt handlng in IPC mode Hi Alan Would it be OK to you if I cc the TF-M mailing list in my answer? Or if you would prefer that, I can move the 'Cooperative Scheduling Rules' document to the TF-M source (in the docs folder), and you can create a patch for it in gerrit. Thanks, Mate From: DeMars, Alan <mailto:ademars@ti.com> Sent: 11 November 2019 21:05 To: Mate Toth-Pal <mailto:Mate.Toth-Pal@arm.com> Cc: Ken Liu (Arm Technology China) <mailto:Ken.Liu@arm.com> Subject: secure interrupt handlng in IPC mode Hi Mate! I've been doing some thinking about the unexpected behavior we saw when a secure interrupt is configured with a lower priority than pendsv. I think the below statements in the Cooperative Scheduling Rules discussion: a. All of the SPE interrupts must have higher priority than NSPE interrupts d. A NSPE interrupt is not allowed to preempt SPE ISR must extend to the priority level of the SP as it services the interrupt while in thread mode. Otherwise the problem that these rules are meant to avoid can arise: the SPE is not completely restored to its IDLE state prior to a thread pre-empting NS interrupt occurring. So, rather than the behavior we witnessed being unexpected, I think it may have to be enforced. Is this correct thinking? Alan IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m 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, 3 months

2
1
0 0

Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure

by David Hu (Arm Technology China)

Hi Andrei, Thanks a lot for the positive feedback. Adding another common layer for all the partners sounds similar to Andrej's proposal. In my very own opinion, currently CMSIS can cover the general arch features. The general multi-core mailbox code is kept in TF-M Core. But I won't be surprised if additional common features should be extracted and kept under platform folder. Apparently, we need more partners/platforms on TF-M to specify the requirements. I'd suggest that we can discuss the additional common part as another topic in a separated email thread. Best regards, Hu Ziji -----Original Message----- From: Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com> Sent: Saturday, November 23, 2019 3:49 AM To: David Hu (Arm Technology China) <David.Hu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: [RFC] Re-organize the TF-M platform folder structure Hi David, I support this idea as it is a quick and easy solution for the growing list of supported platforms. Perhaps, I would also add another common layer in platform/ext/target to keep platform code that can be reused by other partners in their platforms - for the multicore mailbox code, for example. Thanks, Andrei -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Tuesday, November 19, 2019 7:20 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi all, I'd like to propose to adjust the platform folder structure. Would you please check the details below and share your opinions? Any suggestion or feedback will be very helpful. In current platform folder structure, all the targets are listed together at the same level under `target` folder. Platform |-- ext |-- . |-- target_xxx.cmake |-- . |-- target_zzz.cmake |-- target |-- mps2 |-- musca_a |-- . A drawback is that, there are many duplicated files in those targets folders. It may become difficult to maintain the target support when targets, platforms, drivers and features continue growing. - A platform may have a series of variants. If each variant target folder has to contain a copy of platform drivers or library, it is difficult to align and maintain the duplicated drivers. - All targets belonging to the same platform contain the duplicated common operation files or configurations, such as HUK, NV counter and platform configurations. A small change has to be applied to multiple identical files. To solve the duplicated files management issue, I'd propose to insert partner folders under `target` and move the targets under the partner folder. The proposed structure looks like the following: Platform |-- ext |-- target | |-- Partner ABC | |-- *common drivers and files* | |-- target_abc_1 | | |-- target_abc_1.cmake | |-- target_abc_2 | |-- Partner XYZ | |-- *common drivers and files* | |-- target_xyz_1 | | |-- target_xyz_1.cmake | |-- target_xyz_2 |-- ... The ideas behind the proposal: - It is more close to the platform support structure in popular RTOSs. It can be more convenient for partners to port platform support to TF-M from existing projects. - Common drivers and operations implementations can be gathered into partner/platform specific folder. Thus each partner/platform folder doesn't have to hold a duplicated copy. - It is easier for partners to fully organize and maintain their platform folders with full permission. More layers can be added under a specific partner folder, such as diverse platforms. - Put the target specific cmake config file back into the target folder. It can make the `platform` folder much more clear. Best regards, Hu Ziji -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m 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, 3 months

1
0
0 0

Add hooks for build artifacts custom post-processing

by Andrei Narkevitch

Hi All, I'd like to propose a small change that allows to implement custom build artifacts post processing. In our case, we need to convert tfm_s and tfm_ns binaries into a different file format and implement our custom signing. I expect that other partners eventually may have the same need for build customization. With this, user has an option to implement compiler_custom_post_build command in platform/ext/<platform>.cmake file, and put there all additional custom operations. If command is not implemented, it will be simply ignored. https://review.trustedfirmware.org/c/trusted-firmware-m/+/2588 thanks Andrei 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, 3 months

1
0
0 0

Fix for broken AN539 build

by Jamie Fox

Hi all, The build is currently broken for AN539 due to a missing include, so I pushed a quick patch to fix it: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2607 Would appreciate it if anyone with a couple of minutes could review it so that we can merge it quickly. Many thanks, Jamie

6 years, 3 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M