- TF-M - lists.trustedfirmware.org

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

by Anton Komlev

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 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] [EXTERNAL] Re: out of tree build

by Kevin Peng (Arm Technology China)

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

6 years, 3 months

1
0
0 0

Re: [TF-M] Coding guideline

by Abhishek Pandit

Hi Reinhard, We had a discussion in the TSC last week about coding standard. The general consensus was that there multiple possible standards that we can aim for but we need to decide our goal in order to decide the coding standard for the project. I believe Mark G is planning to look at the work ongoing in Zephyr project and provide some details to help us take the discussion forward for TF.org. The input below is helpful, we should take this into the unified effort for coding standard and tooling to enforce it. Thanks, Abhishek -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: 22 November 2019 07:59 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Coding guideline Hi all, I suggest to use industry standard coding rules. Here are the CMSIS coding rules: https://arm-software.github.io/CMSIS_5/General/html/index.html#CodingRules Simple, as we use MISRA. MISRA is an accepted set of coding standards, why invent something new? For wide acceptance of TF-M in automotive/industrial projects, you should publish also deviations like here: https://arm-software.github.io/CMSIS_5/RTOS2/html/misraCompliance5.html 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] Coding guideline

by Reinhard Keil

Hi all, I suggest to use industry standard coding rules. Here are the CMSIS coding rules: https://arm-software.github.io/CMSIS_5/General/html/index.html#CodingRules Simple, as we use MISRA. MISRA is an accepted set of coding standards, why invent something new? For wide acceptance of TF-M in automotive/industrial projects, you should publish also deviations like here: https://arm-software.github.io/CMSIS_5/RTOS2/html/misraCompliance5.html 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] Re: out of tree build

by DeMars, Alan

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

6 years, 3 months

2
2
0 0

Re: [TF-M] Call for review on header include update

by Abhishek Pandit

Hi Kevin, Yes my email was meant to be on the mailing list. Added back on. Thanks Abhishek -----Original Message----- From: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com> Sent: 21 November 2019 09:13 To: Abhishek Pandit <Abhishek.Pandit(a)arm.com> Subject: RE: Call for review on header include update Hi Abhishek, [I guess you are trying to reply to mailing list as well?] I think it's mostly about coding style. Most of the headers are included without any relative path in TF-M. So it's wired that lots of headers are included by a relative path, and relative to the project root make it even more unreasonable. The reason I didn't explain it in detail is that I didn't find any documents about this code style. Of course I had discussions with some team members and they are feeling the same. So I'd like to hear more feedbacks first. Best Regards, Kevin -----Original Message----- From: Abhishek Pandit <Abhishek.Pandit(a)arm.com> Sent: Thursday, November 21, 2019 4:54 PM To: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: Call for review on header include update Hi Kevin, Is there something that explains why this is required? Thanks Abhishek -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Peng (Arm Technology China) via TF-M Sent: 21 November 2019 08:38 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Call for review on header include update Hi, I've proposed some patches to update the header includes in TF-M: https://review.trustedfirmware.org/q/topic:%22include_path_update%22+(statu… The idea is to remove the relative paths to TF-M root and add the necessary paths to include search list. Any kinds of comments are welcome. Best Regards, Kevin -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 4 months

1
0
0 0

Gerrit dashboard for TF-M

by Soby Mathew

Hi, I have created a dashboard for the TF-M project on tf.org to better visualize outstanding patches and the state of patch review : https://review.trustedfirmware.org/#/projects/trusted-firmware-m,dashboards… (old Gerrit UI) https://review.trustedfirmware.org/p/trusted-firmware-m/+/dashboard/site:ma… (new UI) Best Regards Soby Mathew

6 years, 4 months

1
0
0 0

Call for review on header include update

by Kevin Peng (Arm Technology China)

Hi, I've proposed some patches to update the header includes in TF-M: https://review.trustedfirmware.org/q/topic:%22include_path_update%22+(statu… The idea is to remove the relative paths to TF-M root and add the necessary paths to include search list. Any kinds of comments are welcome. Best Regards, Kevin

6 years, 4 months

1
0
0 0

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

by Andrej Butok

Hi David, Let's go further. The main goal of the proposal should be to have the all TFM portable code in one place as much as possible - so the top folder is named as "port". New proposed structure: port |-- platform | | | |-- Partner ABC | | |-- common | | |-- target_abc_1 | | |-- target_abc_2 | | | |-- Partner XYZ | | |-- common | | |-- target_xyz_1 | | |-- target_xyz_2 | |-- ... | -- arch | -- include Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Wednesday, November 20, 2019 4:20 AM 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 4 months

2
1
0 0

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

by Ken Liu (Arm Technology China)

Hi David, The concept itself looks ok for me. So that the scope of vendor would be much clearer. And I think some structure change out of platform folder needs to happen to cooperate with this change, hope to see the detailed analysis result of the changes to be made. Thanks. /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Wednesday, November 20, 2019 11:20 AM 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

6 years, 4 months

1
0
0 0

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

by David Hu (Arm Technology China)

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

6 years, 4 months

1
0
0 0

Re: [TF-M] Coding guideline

by Ken Liu (Arm Technology China)

Hi Tamas, The guidelines look good. I would suggest distinguishing these rules between `original tfm created sources` and `3rd party` sources because tfm is now involving some 3rd party projects and we should keep their original taste as much as we could. /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kumar Gala via TF-M Sent: Tuesday, November 19, 2019 11:22 PM To: Kevin Townsend <kevin.townsend(a)linaro.org> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Coding guideline I’ve been curious if something like https://lgtm.com/ could be used to have checks for code guidelines. - k > On Nov 19, 2019, at 8:22 AM, Kevin Townsend via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Tamas, > > Just to add to the conversation, something that the Zephyr project > added to make enforcing the coding guidelines easier was a config file for uncrustify. > > https://docs.zephyrproject.org/latest/contribute/index.html#uncrustify > > The Zephyr config file itself can be seen here: > https://github.com/zephyrproject-rtos/zephyr/blob/master/.uncrustify.c > fg > > The advantage here is that most text editors can be configured to > automatically apply these rules and avoid common white space or other issues. > > I've generally found this very useful generating PRs and just ensuring > I didn't make any obvious errors when I commit files or changes. > > Best regards, > Kevin > > > On Mon, 18 Nov 2019 at 17:31, Tamas Ban via TF-M > <tf-m(a)lists.trustedfirmware.org> 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… >> >> 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 > -- > 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, 4 months

1
0
0 0

CC312 (crypto HW accelerator) integration on Musca-B1

by Tamas Ban

Hi, Musca-B1 board is the target of PSA Level 2 certification. As part of this process we integrated the CC312 crypto HW accelerator with TF-M. The following major changes was done: * Replacement of mbedTLS library to mbed-crypto in MCUBoot. * Integration of CryptoCell-runtime-library to TF-M build system. * Default behaviour of Musca-B1 is unchanged, it use SW only crypto and relying only on mbed-crypto. HW accelerated crypto can be turned on with CMake command line switch: -DCRYPTO_HW_ACCELERATOR=ON * When HW crypto acceleration is enabled then CryptoCell-runtime-library and CC312 HW perform the crypto operations instead of mbed-crypto (mbedTLS). The library provides an mbedTLS compliant API, therefore it requires minimal modification in the code base. * Creating a crypto key provisioning tool to program the TF-M related crypto keys to OTP memory (HUK, ROTPK, attest priv. key). Here we took a sort-cut and currently linked this tool to MCUBoot on demand. CMake command line switch: -DCRYPTO_HW_ACCELERATOR_OTP_STATE=PROVISIONING * Porting of platform layer in Musca-B1 folder to rely on CC312 and OTP memory. CMake command line switch: -DCRYPTO_HW_ACCELERATOR_OTP_STATE=ENABLED * Extends initial attestation API to provide a public API to retrieve the public part of the attestation key. The top of the patch-set: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2539/ We would like to review and merge the changes by 27th of November! Reviewers are welcome! Tamas Ban

6 years, 4 months

1
0
0 0

Re: [TF-M] Coding guideline

by Kumar Gala

I’ve been curious if something like https://lgtm.com/ could be used to have checks for code guidelines. - k > On Nov 19, 2019, at 8:22 AM, Kevin Townsend via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Tamas, > > Just to add to the conversation, something that the Zephyr project added to make > enforcing the coding guidelines easier was a config file for uncrustify. > > https://docs.zephyrproject.org/latest/contribute/index.html#uncrustify > > The Zephyr config file itself can be seen here: > https://github.com/zephyrproject-rtos/zephyr/blob/master/.uncrustify.cfg > > The advantage here is that most text editors can be configured to automatically > apply these rules and avoid common white space or other issues. > > I've generally found this very useful generating PRs and just ensuring > I didn't make > any obvious errors when I commit files or changes. > > Best regards, > Kevin > > > On Mon, 18 Nov 2019 at 17:31, Tamas Ban via TF-M > <tf-m(a)lists.trustedfirmware.org> 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… >> >> 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 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 4 months

1
0
0 0

Re: [TF-M] Coding guideline

by Kevin Townsend

Hi Tamas, Just to add to the conversation, something that the Zephyr project added to make enforcing the coding guidelines easier was a config file for uncrustify. https://docs.zephyrproject.org/latest/contribute/index.html#uncrustify The Zephyr config file itself can be seen here: https://github.com/zephyrproject-rtos/zephyr/blob/master/.uncrustify.cfg The advantage here is that most text editors can be configured to automatically apply these rules and avoid common white space or other issues. I've generally found this very useful generating PRs and just ensuring I didn't make any obvious errors when I commit files or changes. Best regards, Kevin On Mon, 18 Nov 2019 at 17:31, Tamas Ban via TF-M <tf-m(a)lists.trustedfirmware.org> 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… > > 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, 4 months

1
0
0 0

T398/T413, uploaded

by Thomas Törnblom

I have just uploaded the first of a set of changes to allow building TF-M with the IAR toolchain. https://review.trustedfirmware.org/c/trusted-firmware-m/+/2560 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, 4 months

1
0
0 0

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

by DeMars, Alan

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 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> 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 Cc: nd <nd(a)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

6 years, 4 months

2
1
0 0

Re: [TF-M] Commonly accepted default documentation layout

by Christopher Brand

I think you're right that we need some rules like this, and the list below looks reasonable to me. The list should probably be a document in its own right... Chris > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Minos > Galanakis via TF-M > Sent: Thursday, November 14, 2019 3:14 AM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [TF-M] Commonly accepted default documentation layout > > Hi > > With our documentation growing, and more people contributing to it, it is > quite essential to start a discussion on some basic commonly accepted rules > about the format of choice. > > Restructured text allows you to achieve similar looking results using multiple > approaches, but this makes it harder for tools like Sphinx to render properly, > since the rendering template can be applied on per project basis, not on a > per file basis. > I took the liberty of investigating the existing documentation, and mostly > looking for top level headers which can be done by using either > > > > #################### > > This is a top-level header > > #################### > > # Reference docs: > # design_documents/tfm_its_service.rst > # design_documents/secure_boot_hw_key_integration.rst > > # Reference docs: > # user_guides/tfm_secure_boot.rst > # user_guides/tfm_user_guide.rst > > > > > > or > > > ==================== > This is a top level header > ==================== > > # Reference docs: > # design_documents/tfm_its_service.rst > # design_documents/secure_boot_hw_key_integration.rst > > > > > Since we are looking for the path of least resistance, I would like to propose > that we follow the format the majority of document uses.This is the format > used in > `user_guides/tfm_user_guide.rst<https://git.trustedfirmware.org/trusted- > firmware-m.git/plain/docs/user_guides/tfm_user_guide.rst>` . > > When writing a document and coming across a requirement that has not > been defined yet, we should be aiming for compliance with official Python > guidelines<https://devguide.python.org/documenting/#style-guide> which > is the most commonly used notation. > > The following rules should be considered: > > > 1. H1 document title headers should be expressed by # with over-line (rows > on top and bottom) of the text > 2. Only ONE H1 header should allowed per document, ideally placed on top > of the page. > 3. H2 headers should be expressed by * with over-line > 4. H2 header's text should be UNIQUE in per document basis > 5. H3 headers should be expressed by a row of '=' > 6. H4 headers should be expressed by a row of '-' > 7. H3 and H4 headers have no limitation about naming. They can have > similar names on the same document, if they have different parents. > 8. H5 headers should be expressed by a row of '^' > 9. H5 headers will be rendered in document body but not in menus on the > navigation bar. > 10. Do not go deeper than 5 level of heading > 11. When writing guide, which are expected to be able to be readable by > command line tools, it would be best practice to add long complicated tables, > and UML diagrams in the bottom of the page and using internal > references(auto-label). See the current version of the > `/user_guides/tfm_sw_requirement.rst<https://git.trustedfirmware.org/tru > sted-firmware-m.git/plain/docs/user_guides/tfm_sw_requirement.rst>` > and the proposed patch<https://review.trustedfirmware.org/c/trusted- > firmware-m/+/2456> > > Please let me know if you have any questions/objection or proposals or new > rules you would like to be considered. > > > Thanks, > Minos > -- > 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, 4 months

1
0
0 0

New platform in TF-M: Musca-S1

by Mate Toth-Pal

Hi All, TF-M support for a new platform Musca-S1 is on review: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2452/ We are planning to merge the patch this week. Comments are welcome on the review. Regards, Mate

6 years, 4 months

1
0
0 0

Commonly accepted default documentation layout

by Minos Galanakis

Hi With our documentation growing, and more people contributing to it, it is quite essential to start a discussion on some basic commonly accepted rules about the format of choice. Restructured text allows you to achieve similar looking results using multiple approaches, but this makes it harder for tools like Sphinx to render properly, since the rendering template can be applied on per project basis, not on a per file basis. I took the liberty of investigating the existing documentation, and mostly looking for top level headers which can be done by using either #################### This is a top-level header #################### # Reference docs: # design_documents/tfm_its_service.rst # design_documents/secure_boot_hw_key_integration.rst # Reference docs: # user_guides/tfm_secure_boot.rst # user_guides/tfm_user_guide.rst or ==================== This is a top level header ==================== # Reference docs: # design_documents/tfm_its_service.rst # design_documents/secure_boot_hw_key_integration.rst Since we are looking for the path of least resistance, I would like to propose that we follow the format the majority of document uses.This is the format used in `user_guides/tfm_user_guide.rst<https://git.trustedfirmware.org/trusted-firmware-m.git/plain/docs/user_guid…>` . When writing a document and coming across a requirement that has not been defined yet, we should be aiming for compliance with official Python guidelines<https://devguide.python.org/documenting/#style-guide> which is the most commonly used notation. The following rules should be considered: 1. H1 document title headers should be expressed by # with over-line (rows on top and bottom) of the text 2. Only ONE H1 header should allowed per document, ideally placed on top of the page. 3. H2 headers should be expressed by * with over-line 4. H2 header's text should be UNIQUE in per document basis 5. H3 headers should be expressed by a row of '=' 6. H4 headers should be expressed by a row of '-' 7. H3 and H4 headers have no limitation about naming. They can have similar names on the same document, if they have different parents. 8. H5 headers should be expressed by a row of '^' 9. H5 headers will be rendered in document body but not in menus on the navigation bar. 10. Do not go deeper than 5 level of heading 11. When writing guide, which are expected to be able to be readable by command line tools, it would be best practice to add long complicated tables, and UML diagrams in the bottom of the page and using internal references(auto-label). See the current version of the `/user_guides/tfm_sw_requirement.rst<https://git.trustedfirmware.org/trusted-firmware-m.git/plain/docs/user_guid…>` and the proposed patch<https://review.trustedfirmware.org/c/trusted-firmware-m/+/2456> Please let me know if you have any questions/objection or proposals or new rules you would like to be considered. Thanks, Minos

6 years, 4 months

1
0
0 0

The svcall switch-case vs function table

by Ken Liu (Arm Technology China)

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

6 years, 4 months

1
0
0 0

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

by Edison Ai (Arm Technology China)

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> 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 Cc: nd <nd(a)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

6 years, 4 months

1
0
0 0

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

by Mate Toth-Pal

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.

6 years, 4 months

3
2
0 0

Moving design documents from wiki into source folder with rst format

by Ken Liu (Arm Technology China)

Hi, There are some design documents created earlier is put at wiki. Since they are useful and going to be updated later, we need to move them into source folder with rst format. I have created an issue link for this: https://developer.trustedfirmware.org/T579 The list is here (from link: https://developer.trustedfirmware.org/w/tf_m/): Code Generation With Jinja2 (ongoing) Cooperative Scheduling Rules (ongoing) Inter-Processes Communication Non-secure Client Management (ongoing) Non-Secure Interrupt Handling (ongoing) Secure Partition Interrupt Handling (ongoing) Secure Storage Service Service IPC compatibility - Attestation Service IPC compatibility - SST Trusted Boot Trusted Firmware-m Isolation Level 2 Twin-cpu Uniform Secure Service Signature (ongoing) Some are picked up, the rest are welcome for picking up or comment! Please check the T579 for progress and provide comments in your interested topic - if you found there are some place needs to be updated in these 'old' docs, it is a good chance to update them during the moving. Thanks. /Ken

6 years, 4 months

1
0
0 0

Re: [TF-M] out of tree build

by Kevin Peng (Arm Technology China)

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

6 years, 4 months

1
1
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M