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.
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
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
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
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
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
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/+/1836https://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
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.
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
