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