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