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.
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
>
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>
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.
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>
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.
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
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.
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.
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.
