- TF-M - lists.trustedfirmware.org

Feature branch 'feature-isolation-level3' is created for related patches merging

by Ken Liu

Hi, A new branch created for two repos 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m', this feature branch is for isolation related patches merging. The POC patches would come in following days, first platform would be AN521. If you want to try this branch, please: IMPORTANT: Checkout 'feature-isoaltion-level3' branch for both 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m'. BR /Ken

5 years, 6 months

1
0
0 0

Re: [TF-M] TF-M build system update heads-up

by Anton Komlev

Hi Chris, Could you try this: cmake --build cmake_build -- install Please note, when I copied your command the minus sign “-” was incorrect – probably a dash or hyphen sign. Need double check the doc. Hope it helps, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: 08 September 2020 19:48 To: Christopher Brand <chris.brand(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M build system update heads-up Hi, Sorry to hear that. When you manage to find out the culprit please drop an email to the list. I am really curious. /George From: Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>> Sent: 08 September 2020 19:08 To: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: TF-M build system update heads-up Thanks, Gyorgy. I did indeed have the double dash (pretty sure I just copied and pasted from the doc). I guess my email client decided to “fix it in the mail message. Chris From: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>> Sent: Saturday, September 5, 2020 5:42 AM To: Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Chris, You need two dashes before install. Options with a single dash are processed by cmake. Options after a double dash (--) are passed over to the build tool (in this case gnumake). (See the cmake documentation [1].) So: cmake -B cmake_build -- install is the correct command. [cid:image001.png@01D68623.8624BBE0] I attached an image above to work around potential readability issues of some font sets. I hope it gets trough. [1] https://cmake.org/cmake/help/v3.0/manual/cmake.1.html /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Christopher Brand via TF-M Sent: 05 September 2020 00:26 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] TF-M build system update heads-up Thanks, Anton. I tried again today, and got further – the first cmake command seems to succeed, but the second failed. I used git fetch "https://review.trustedfirmware.org/TF-M/trusted-firmware-m" refs/changes/72/5472/1 && git checkout FETCH_HEAD to get the tree, followed by cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=debug and then cmake -B cmake_build – install This error seems like something trivial: CMake Error: The source directory “…/trusted-firmware-m/install" does not exist. Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: Thursday, September 3, 2020 11:35 AM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Chris, Thanks for trying. Please specify the build type explicitly: -DCMAKE_BUILD_TYPE=debug It shall be defaulted to “MinSizeRel", but something went wrong. Will be fixed asap. Good luck, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Christopher Brand via TF-M Sent: 03 September 2020 19:10 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] TF-M build system update heads-up I tried to build PSoC64 with the new build system a couple of days ago, and wasn’t successful. Following docs/getting_started/tfm_build_instruction.rst (the “Example: building TF-M for AN521 platform using GCC:” section), I ran cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake That failed : CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:107 (if): if given arguments: "STREQUAL" "DEBUG" "OR" "STREQUAL" "Debug" "OR" "STREQUAL" "debug" Unknown arguments specified Looking at that file it seemed that the default for CMAKE_BUILD_TYPE wasn’t being applied, so I tried this command: cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=MinSizeRel That got further, but failed with: CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:115 (target_include_directories): Cannot specify include directories for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:120 (target_compile_definitions): Cannot specify compile definitions for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:130 (target_sources): Cannot specify sources for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:135 (target_link_libraries): Cannot specify link libraries for target "mbedcrypto_crypto_service" which is not built by this project. At that point, I gave up. Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: Thursday, September 3, 2020 10:04 AM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello, As I mentioned in the Open Tech Forum today – we are close to merge the new build system to the master branch. Plan to start doing that at the beginning of the next week. It might cause code freeze for several days and minor problems in corner cases after that. The intention is to clean it out before the next release in November. All changes to merge are in feature-ux-buildsystem branch at the moment. Please signal if it conflicts with your plans. Regards, Anton 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. 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. 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.

5 years, 6 months

1
0
0 0

Re: [TF-M] TF-M build system update heads-up

by Gyorgy Szing

Hi Chris, You need two dashes before install. Options with a single dash are processed by cmake. Options after a double dash (--) are passed over to the build tool (in this case gnumake). (See the cmake documentation [1].) So: cmake -B cmake_build -- install is the correct command. [cid:image001.png@01D68392.B953F780] I attached an image above to work around potential readability issues of some font sets. I hope it gets trough. [1] https://cmake.org/cmake/help/v3.0/manual/cmake.1.html /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: 05 September 2020 00:26 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] TF-M build system update heads-up Thanks, Anton. I tried again today, and got further – the first cmake command seems to succeed, but the second failed. I used git fetch "https://review.trustedfirmware.org/TF-M/trusted-firmware-m" refs/changes/72/5472/1 && git checkout FETCH_HEAD to get the tree, followed by cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=debug and then cmake -B cmake_build – install This error seems like something trivial: CMake Error: The source directory “…/trusted-firmware-m/install" does not exist. Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: Thursday, September 3, 2020 11:35 AM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Chris, Thanks for trying. Please specify the build type explicitly: -DCMAKE_BUILD_TYPE=debug It shall be defaulted to “MinSizeRel", but something went wrong. Will be fixed asap. Good luck, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Christopher Brand via TF-M Sent: 03 September 2020 19:10 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] TF-M build system update heads-up I tried to build PSoC64 with the new build system a couple of days ago, and wasn’t successful. Following docs/getting_started/tfm_build_instruction.rst (the “Example: building TF-M for AN521 platform using GCC:” section), I ran cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake That failed : CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:107 (if): if given arguments: "STREQUAL" "DEBUG" "OR" "STREQUAL" "Debug" "OR" "STREQUAL" "debug" Unknown arguments specified Looking at that file it seemed that the default for CMAKE_BUILD_TYPE wasn’t being applied, so I tried this command: cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=MinSizeRel That got further, but failed with: CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:115 (target_include_directories): Cannot specify include directories for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:120 (target_compile_definitions): Cannot specify compile definitions for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:130 (target_sources): Cannot specify sources for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:135 (target_link_libraries): Cannot specify link libraries for target "mbedcrypto_crypto_service" which is not built by this project. At that point, I gave up. Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: Thursday, September 3, 2020 10:04 AM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello, As I mentioned in the Open Tech Forum today – we are close to merge the new build system to the master branch. Plan to start doing that at the beginning of the next week. It might cause code freeze for several days and minor problems in corner cases after that. The intention is to clean it out before the next release in November. All changes to merge are in feature-ux-buildsystem branch at the moment. Please signal if it conflicts with your plans. Regards, Anton 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. 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.

5 years, 6 months

2
2
0 0

Re: [TF-M] TF-M build system update heads-up

by Christopher Brand

Thanks, Anton. I tried again today, and got further - the first cmake command seems to succeed, but the second failed. I used git fetch "https://review.trustedfirmware.org/TF-M/trusted-firmware-m" refs/changes/72/5472/1 && git checkout FETCH_HEAD to get the tree, followed by cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=debug and then cmake -B cmake_build - install This error seems like something trivial: CMake Error: The source directory ".../trusted-firmware-m/install" does not exist. Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Thursday, September 3, 2020 11:35 AM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Chris, Thanks for trying. Please specify the build type explicitly: -DCMAKE_BUILD_TYPE=debug It shall be defaulted to "MinSizeRel", but something went wrong. Will be fixed asap. Good luck, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Christopher Brand via TF-M Sent: 03 September 2020 19:10 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] TF-M build system update heads-up I tried to build PSoC64 with the new build system a couple of days ago, and wasn't successful. Following docs/getting_started/tfm_build_instruction.rst (the "Example: building TF-M for AN521 platform using GCC:" section), I ran cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake That failed : CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:107 (if): if given arguments: "STREQUAL" "DEBUG" "OR" "STREQUAL" "Debug" "OR" "STREQUAL" "debug" Unknown arguments specified Looking at that file it seemed that the default for CMAKE_BUILD_TYPE wasn't being applied, so I tried this command: cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=MinSizeRel That got further, but failed with: CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:115 (target_include_directories): Cannot specify include directories for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:120 (target_compile_definitions): Cannot specify compile definitions for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:130 (target_sources): Cannot specify sources for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:135 (target_link_libraries): Cannot specify link libraries for target "mbedcrypto_crypto_service" which is not built by this project. At that point, I gave up. Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: Thursday, September 3, 2020 10:04 AM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello, As I mentioned in the Open Tech Forum today - we are close to merge the new build system to the master branch. Plan to start doing that at the beginning of the next week. It might cause code freeze for several days and minor problems in corner cases after that. The intention is to clean it out before the next release in November. All changes to merge are in feature-ux-buildsystem branch at the moment. Please signal if it conflicts with your plans. Regards, Anton 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. 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.

5 years, 6 months

1
0
0 0

Re: [TF-M] Changes to configure FPU at the architectural level in TF-M

by Robert Rostohar

Hi Soby, Hi Ken, Thanks for your replies. As mentioned before, majority of device vendors already provide system files (CMSIS standard) which configure also FPU. Take a look for example at the system file provided for STM32L5xx device family (part of STM32CubeL5 FW): https://github.com/STMicroelectronics/STM32CubeL5/blob/master/Drivers/CMSIS… Porting TF-M to a new device should be even simpler when such files can be used directly (or with as less modifications as possible). I'm not just looking at the few platforms that are directly supported within TF-M repo but rather how to reduce efforts to enable TF-M on any CMSIS-Core compliant device. Note: If current system files provided by vendors do not properly configure security features then this should be highlighted. Best regards, Robert From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby Mathew via TF-M Sent: Wednesday 2 September 2020 16:00 To: Ken Liu <Ken.Liu(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Changes to configure FPU at the architectural level in TF-M Hi Robert, The current architecture abstraction depends on the some CMSIS standard macros (like __FPU_USED) to be defined and if there are vendor tools which can generate the same system file, as long as they are using the standard macros, the architecture abstraction should work alright if the generated file can be included. As Ken says, this makes architecture initialization uniform across platforms and provides the right settings to be applied for security. It also reduces the platform porting effort for new platforms. Hence the move in such a direction. If we allow a mechanism to allow the platform provided system file to be used rather than the default system file, will that suffice your requirement ? Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 02 September 2020 11:11 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Changes to configure FPU at the architectural level in TF-M Hi Robert, Thanks for the comment, just want to double check if the guidelines for vendors who providing platform sources to a secure software covers the recommendations here: https://lists.trustedfirmware.org/pipermail/tf-m/2020-June/001007.html As far as we can see not all existing platforms set the registers required in the above recommendation (In Jamie's second patch), so we are trying to provide an architecture-abstraction. Meanwhile, we would notify the platform owner checking the platform-specific setting. After all platform vendor confirmed the setting of FPU we can leave this back to platform setting as you suggested - but secure firmware core logic still needs to check if platform set the FPU setting correctly. @Soby @Jamie, please update if I missed something. BR /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Robert Rostohar via TF-M Sent: Wednesday, September 2, 2020 5:30 PM To: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Changes to configure FPU at the architectural level in TF-M Hi Jamie, I have concerns with moving FPU configuration from platform to architecture-abstraction layer. FPU configuration is typically configured within system configuration files that are standardized in CMSIS and provided by device vendors. Some vendors provide also tools that auto-generate the system file based on user configuration (ex: STM32CubeMX). Therefore it would be better to leave the FPU configuration to the platform rather than moving it into architecture-abstraction. Best regards, Robert From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Jamie Fox via TF-M Sent: Friday 28 August 2020 19:53 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] Changes to configure FPU at the architectural level in TF-M Hi all, There is a change open for review that adds configuration of FPU-related registers to the architecture-abstraction layer in TF-M, and removes this same configuration from platform support files. The reasoning for this is that these registers are defined by the Arm architecture, so FPU config can be unified for all platforms with the same architecture. For Armv8-M, this also includes configuration to ensure that information is not leaked in FPU registers to NSPE when the SPE uses the FPU, and to permit the NSPE to access the FPU. By default, TF-M will still be built without the FPU used in the SPE. You can review the changes at: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5405 Arch: Add function to configure coprocessors https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5406 Platform: Remove platform-specific FPU config It would be especially helpful if platform owners could check that they are happy with FPU config being moved out of the platform support files. Kind regards, Jamie

5 years, 6 months

2
3
0 0

TF-M fault injection mitigation

by Tamas Ban

Hi, If you found yesterday the HW fault injection mitigation topic interesting and it raised your attention then you can find detailed info about it here: https://www.cl.cam.ac.uk/~rja14/Papers/whatyouc.pdf https://www.riscure.com/uploads/2018/11/201708_Riscure_Whitepaper_Side_Chan… The PRs to MCUBoot are here: https://github.com/JuulLabs-OSS/mcuboot/pull/776 https://github.com/JuulLabs-OSS/mcuboot/pull/789 Tamas

5 years, 6 months

1
0
0 0

Re: [TF-M] TF-M build system update heads-up

by Anton Komlev

Hi Chris, Thanks for trying. Please specify the build type explicitly: -DCMAKE_BUILD_TYPE=debug It shall be defaulted to "MinSizeRel", but something went wrong. Will be fixed asap. Good luck, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: 03 September 2020 19:10 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] TF-M build system update heads-up I tried to build PSoC64 with the new build system a couple of days ago, and wasn't successful. Following docs/getting_started/tfm_build_instruction.rst (the "Example: building TF-M for AN521 platform using GCC:" section), I ran cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake That failed : CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:107 (if): if given arguments: "STREQUAL" "DEBUG" "OR" "STREQUAL" "Debug" "OR" "STREQUAL" "debug" Unknown arguments specified Looking at that file it seemed that the default for CMAKE_BUILD_TYPE wasn't being applied, so I tried this command: cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=MinSizeRel That got further, but failed with: CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:115 (target_include_directories): Cannot specify include directories for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:120 (target_compile_definitions): Cannot specify compile definitions for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:130 (target_sources): Cannot specify sources for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:135 (target_link_libraries): Cannot specify link libraries for target "mbedcrypto_crypto_service" which is not built by this project. At that point, I gave up. Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: Thursday, September 3, 2020 10:04 AM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello, As I mentioned in the Open Tech Forum today - we are close to merge the new build system to the master branch. Plan to start doing that at the beginning of the next week. It might cause code freeze for several days and minor problems in corner cases after that. The intention is to clean it out before the next release in November. All changes to merge are in feature-ux-buildsystem branch at the moment. Please signal if it conflicts with your plans. Regards, Anton 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.

5 years, 6 months

1
0
0 0

Re: [TF-M] TF-M build system update heads-up

by Christopher Brand

I tried to build PSoC64 with the new build system a couple of days ago, and wasn't successful. Following docs/getting_started/tfm_build_instruction.rst (the "Example: building TF-M for AN521 platform using GCC:" section), I ran cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake That failed : CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:107 (if): if given arguments: "STREQUAL" "DEBUG" "OR" "STREQUAL" "Debug" "OR" "STREQUAL" "debug" Unknown arguments specified Looking at that file it seemed that the default for CMAKE_BUILD_TYPE wasn't being applied, so I tried this command: cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=MinSizeRel That got further, but failed with: CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:115 (target_include_directories): Cannot specify include directories for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:120 (target_compile_definitions): Cannot specify compile definitions for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:130 (target_sources): Cannot specify sources for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:135 (target_link_libraries): Cannot specify link libraries for target "mbedcrypto_crypto_service" which is not built by this project. At that point, I gave up. Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Thursday, September 3, 2020 10:04 AM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello, As I mentioned in the Open Tech Forum today - we are close to merge the new build system to the master branch. Plan to start doing that at the beginning of the next week. It might cause code freeze for several days and minor problems in corner cases after that. The intention is to clean it out before the next release in November. All changes to merge are in feature-ux-buildsystem branch at the moment. Please signal if it conflicts with your plans. Regards, Anton 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.

5 years, 6 months

1
0
0 0

TF-M build system update heads-up

by Anton Komlev

Hello, As I mentioned in the Open Tech Forum today - we are close to merge the new build system to the master branch. Plan to start doing that at the beginning of the next week. It might cause code freeze for several days and minor problems in corner cases after that. The intention is to clean it out before the next release in November. All changes to merge are in feature-ux-buildsystem branch at the moment. Please signal if it conflicts with your plans. Regards, Anton

5 years, 6 months

1
0
0 0

New build system with IAR

by Thomas Törnblom

I've started looking at the new build system, and it looks like a nice improvement. I have a problem, that likely has a simple solution, although I'm not sure which. I've looked at the AN521 target, and the preload.cmake file is included very early from the root CMakeLists.txt The first line of preload.cmake is: --- set(CMAKE_SYSTEM_PROCESSOR cortex-m33+nodsp) --- For IAR that line should be: --- set(CMAKE_SYSTEM_PROCESSOR Cortex-M33.no_dsp) --- I need to discriminate between the toolchains already there, but I haven't figured out what the best way would be to do that. Not much is setup at this moment in the run. Ideas? 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>

5 years, 6 months

1
1
0 0

Re: [TF-M] Simpler integration into other projects

by Anton Komlev

Hi Øyvind, Thank you for the proposal. Believe all agreed that NS side shall be separated from S side and be OS independent. There were multiple efforts recently toward this direction like repo split and build system refactoring. I think currently we almost achieve it. Assume you have seen that new build system allows creates S, NS, BL targets independently. Could you specify the remaining dependencies, you concern? Thanks, Anton -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Rønningstad, Øyvind via TF-M Sent: 02 September 2020 13:31 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Simpler integration into other projects Hi list I have a proposal to make it easier to integrate TF-M into other existing projects, e.g. RTOSes such as Zephyr. I'm using Zephyr as an example, but I mean that it should apply to any external project that wants to integrate TF-M. I'm assuming the project wants to use the secure FW as is, so no change is needed there. However, in the NS FW we want to integrate the NS callable (PSA) API into native Zephyr applications, but the NS ("app") part of TF-M has some OS dependencies that interfere with this. My proposal is that the TF-M build system creates OS-independent NS libs that can be linked directly into the native Zephyr app. Ideally, the Zephyr build system should need to only do the following: - Call TF-M build system. - Retrieve S binaries (and optionally mcuboot binary). - Link NS lib(s) into project app. - Add include directories to NS callable API. Additionally, the RTOS will likely need to make an OS wrapper to support the OS functions needed. Please tell me your thoughts. I'm not an expert in Cmake and libs, so please also tell me if the above is infeasible in any way. I think making such integrations as simple as possible will be very beneficial, not just when doing the initial integration, but continuously, since changes in TF-M will eventually require tweaks in the integration. Best regards, Øyvind Rønningstad -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

1
0
0 0

Re: [TF-M] CI Checkpatch

by Soby Mathew

Thanks Gyorgy for your inputs. My only concern with git hooks is that they are triggered when patches are pushed for review whereas checkpatch is something needs to be frequently run for non-trivial patchsets. The other issue is I am not sure whether we can pass different arguments to githooks whereas build system integration allows that (for example check the entire tree vs only the changed lines). Also having it part of regular build allows easier integration with work flow. Hence many OSS projects integrate this into regular build for this reason. But as you say, perhaps the first solution is to download the script and run locally and I don't have a strong opinion against git hooks either. Whatever works best can be used. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: 02 September 2020 15:25 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] CI Checkpatch Hi, My two cents on the topic. Sort term Sort term it is possible to clone the ci-scripts repository and to run the check-patch script locally (https://git.trustedfirmware.org/ci/tf-m-ci-scripts.git/tree/run-checkpatch.…) . The script has some in-line documentation. Long term I think this is an automation topic which may have a connection to the build system, but the right place for a solution in not there. When it comes to automation the best is to differentiate two use cases: 1. Centralized. This is where the automation happens on a server, and the main purpose is to keep authentic records about quality, or to drive delivery (i.e. push documents to hosting provider.) For this we have Jenkins. 2. De-centralized. This is when the automation is executed on the developers machine. How the user interacts with this system can be an implementation detail. The same scripts could be executed by git hooks, manually, or by the build system. I think the best solution would be to use git-hooks for decentralized automation, as this is there already, and has a well defined and standard interface towards the developer. The main problem with git hooks is, git as a policy leaves hook management as the responsibility of the developer, and there is no built-in way to deploy hooks to the developers machine. (This is due to security considerations.) As a solution to this issue multiple "hook frameworks" have been developed. I suggest investigating these and to build a decentralize automation solution on top of one of them. Ideally the same scripts executed by Jenkins could be executed by the framework too. Some contenders (and the language thy are developed with): * https://github.com/icefox/git-hooks - bash * https://github.com/git-hooks/git-hooks -golang * https://github.com/gnustavo/Git-Hooks - perl Of course there are many more. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Soby Mathew via TF-M Sent: 02 September 2020 15:18 To: Karl Zhang <Karl.Zhang(a)arm.com<mailto:Karl.Zhang@arm.com>>; Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] CI Checkpatch Hi, Just my view on this, One of the things that will be helpful is to have is the checkpatch script imported into the project and have a `make checkpatch` build target. This will help to pipe clean check-patch errors from developer side before pushing patch for review. We could also make it a git hook but then I feel it is less convenient than having a regular build target. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Karl Zhang via TF-M Sent: 02 September 2020 01:56 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] CI Checkpatch Hi Chris, The CI job was trigged from https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/3521, you could find a list of all jobs and status of each job on Gerrit page that triggered by that job, job list example can be found at the end of this email. Another way is from the link you mentioned, that is a pipeline of how CI jobs start from one stage to another stage, if you click on the node of each stage, "Triggered Builds" will list the related job and you can check the details of it. The Open CI for TF-M is under development of Linaro, development plan and status can be found from https://developer.trustedfirmware.org/w/collaboration/openci/ , it is not stable at this moment that we are continuously addressing on. There is no latest document for detail introduction of current Open CI yet. Open CI - developer.trustedfirmware.org<https://developer.trustedfirmware.org/w/collaboration/openci/> Milestone Deliverables Target Completion Status; M1: Planning, Handover and Deployment SOW and project plan Hand over from OCE to Developer Services developer.trustedfirmware.org For the checkpatch job, it is a part of the static check stage, the error from this stage won't impact the final CI score, we need more investigation before active all static checks. The CI jobs were not able to trigger manually. There is a request to Linaro for the requirement that already working on, hope it can be deployed to the public Open CI soon. Job list example on Gerrit after CI job: Passed: 4, Failed: 18, Not done: 0 AN519_GNUARM_ConfigRegressionIPCTfmLevel2_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29147/> -1 AN519_GNUARM_ConfigRegressionIPC_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29146/> -1 AN519_GNUARM_ConfigRegressionProfileS_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29152/> -1 AN519_GNUARM_ConfigRegression_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29144/> -1 .... checkpatch<http://ci.trustedfirmware.org/job/tf-m-checkpatch/472/> -1 cppcheck<http://ci.trustedfirmware.org/job/tf-m-cppcheck/472/> 1 lava_boot<http://ci.trustedfirmware.org/job/tf-m-build-and-test/474/> 1 lava_test<http://ci.trustedfirmware.org/job/tf-m-build-and-test/474/> 1 psoc64_GNUARM_ConfigRegressionIPCTfmLevel2_Release_NOBL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29157/> -1 psoc64_GNUARM_ConfigRegressionIPC_Release_NOBL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29154/> -1 tf-m-build<http://ci.trustedfirmware.org/job/tf-m-build-and-test/479/> -1 tf-m-build-docs<http://ci.trustedfirmware.org/job/tf-m-build-docs/647/> 1 Thanks, Karl Zhang ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Tuesday, September 1, 2020 12:35 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] CI Checkpatch So I see the CI system runs checkpatch, but I don't see any mention of checkpatch under the "docs" directory, or in any of the gerrit reviews, or even on the mailing list. The output in the CI system, as far as I can see, is not particularly useful (I followed the link posted on my review to https://ci.trustedfirmware.org/blue/organizations/jenkins/tf-m-static/detai… but could find anything indicating what issue was actually found). Is there any documentation on how we can run checkptach manually? Or on how to see what the CI version is actually complaining about? Should I just be ignoring the CI checkpatch errors? Thanks, Chris Brand Sr Prin Software Engr, MCD: WIRELESS Cypress Semiconductor Corp. An Infineon Technologies Company #320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com> 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.

5 years, 6 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - September 3

by Anton Komlev

Hello, The agenda for this forum: 1. Hardware fault injection mitigation 2. Secure Partition Addition Demonstration See you, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 26 August 2020 13:52 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - September 3 Hello, The next Technical Forum is planned on Thursday, September 3 at 15:00-16:00 UTC (US time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton Komlev

5 years, 6 months

1
0
0 0

Re: [TF-M] CI Checkpatch

by Gyorgy Szing

Hi, My two cents on the topic. Sort term Sort term it is possible to clone the ci-scripts repository and to run the check-patch script locally (https://git.trustedfirmware.org/ci/tf-m-ci-scripts.git/tree/run-checkpatch.…) . The script has some in-line documentation. Long term I think this is an automation topic which may have a connection to the build system, but the right place for a solution in not there. When it comes to automation the best is to differentiate two use cases: 1. Centralized. This is where the automation happens on a server, and the main purpose is to keep authentic records about quality, or to drive delivery (i.e. push documents to hosting provider.) For this we have Jenkins. 2. De-centralized. This is when the automation is executed on the developers machine. How the user interacts with this system can be an implementation detail. The same scripts could be executed by git hooks, manually, or by the build system. I think the best solution would be to use git-hooks for decentralized automation, as this is there already, and has a well defined and standard interface towards the developer. The main problem with git hooks is, git as a policy leaves hook management as the responsibility of the developer, and there is no built-in way to deploy hooks to the developers machine. (This is due to security considerations.) As a solution to this issue multiple "hook frameworks" have been developed. I suggest investigating these and to build a decentralize automation solution on top of one of them. Ideally the same scripts executed by Jenkins could be executed by the framework too. Some contenders (and the language thy are developed with): * https://github.com/icefox/git-hooks - bash * https://github.com/git-hooks/git-hooks -golang * https://github.com/gnustavo/Git-Hooks - perl Of course there are many more. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby Mathew via TF-M Sent: 02 September 2020 15:18 To: Karl Zhang <Karl.Zhang(a)arm.com>; Christopher Brand <chris.brand(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] CI Checkpatch Hi, Just my view on this, One of the things that will be helpful is to have is the checkpatch script imported into the project and have a `make checkpatch` build target. This will help to pipe clean check-patch errors from developer side before pushing patch for review. We could also make it a git hook but then I feel it is less convenient than having a regular build target. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Karl Zhang via TF-M Sent: 02 September 2020 01:56 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] CI Checkpatch Hi Chris, The CI job was trigged from https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/3521, you could find a list of all jobs and status of each job on Gerrit page that triggered by that job, job list example can be found at the end of this email. Another way is from the link you mentioned, that is a pipeline of how CI jobs start from one stage to another stage, if you click on the node of each stage, "Triggered Builds" will list the related job and you can check the details of it. The Open CI for TF-M is under development of Linaro, development plan and status can be found from https://developer.trustedfirmware.org/w/collaboration/openci/ , it is not stable at this moment that we are continuously addressing on. There is no latest document for detail introduction of current Open CI yet. Open CI - developer.trustedfirmware.org<https://developer.trustedfirmware.org/w/collaboration/openci/> Milestone Deliverables Target Completion Status; M1: Planning, Handover and Deployment SOW and project plan Hand over from OCE to Developer Services developer.trustedfirmware.org For the checkpatch job, it is a part of the static check stage, the error from this stage won't impact the final CI score, we need more investigation before active all static checks. The CI jobs were not able to trigger manually. There is a request to Linaro for the requirement that already working on, hope it can be deployed to the public Open CI soon. Job list example on Gerrit after CI job: Passed: 4, Failed: 18, Not done: 0 AN519_GNUARM_ConfigRegressionIPCTfmLevel2_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29147/> -1 AN519_GNUARM_ConfigRegressionIPC_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29146/> -1 AN519_GNUARM_ConfigRegressionProfileS_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29152/> -1 AN519_GNUARM_ConfigRegression_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29144/> -1 .... checkpatch<http://ci.trustedfirmware.org/job/tf-m-checkpatch/472/> -1 cppcheck<http://ci.trustedfirmware.org/job/tf-m-cppcheck/472/> 1 lava_boot<http://ci.trustedfirmware.org/job/tf-m-build-and-test/474/> 1 lava_test<http://ci.trustedfirmware.org/job/tf-m-build-and-test/474/> 1 psoc64_GNUARM_ConfigRegressionIPCTfmLevel2_Release_NOBL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29157/> -1 psoc64_GNUARM_ConfigRegressionIPC_Release_NOBL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29154/> -1 tf-m-build<http://ci.trustedfirmware.org/job/tf-m-build-and-test/479/> -1 tf-m-build-docs<http://ci.trustedfirmware.org/job/tf-m-build-docs/647/> 1 Thanks, Karl Zhang ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Tuesday, September 1, 2020 12:35 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] CI Checkpatch So I see the CI system runs checkpatch, but I don't see any mention of checkpatch under the "docs" directory, or in any of the gerrit reviews, or even on the mailing list. The output in the CI system, as far as I can see, is not particularly useful (I followed the link posted on my review to https://ci.trustedfirmware.org/blue/organizations/jenkins/tf-m-static/detai… but could find anything indicating what issue was actually found). Is there any documentation on how we can run checkptach manually? Or on how to see what the CI version is actually complaining about? Should I just be ignoring the CI checkpatch errors? Thanks, Chris Brand Sr Prin Software Engr, MCD: WIRELESS Cypress Semiconductor Corp. An Infineon Technologies Company #320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com> 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.

5 years, 6 months

1
0
0 0

Re: [TF-M] Changes to configure FPU at the architectural level in TF-M

by Soby Mathew

Hi Robert, The current architecture abstraction depends on the some CMSIS standard macros (like __FPU_USED) to be defined and if there are vendor tools which can generate the same system file, as long as they are using the standard macros, the architecture abstraction should work alright if the generated file can be included. As Ken says, this makes architecture initialization uniform across platforms and provides the right settings to be applied for security. It also reduces the platform porting effort for new platforms. Hence the move in such a direction. If we allow a mechanism to allow the platform provided system file to be used rather than the default system file, will that suffice your requirement ? Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 02 September 2020 11:11 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Changes to configure FPU at the architectural level in TF-M Hi Robert, Thanks for the comment, just want to double check if the guidelines for vendors who providing platform sources to a secure software covers the recommendations here: https://lists.trustedfirmware.org/pipermail/tf-m/2020-June/001007.html As far as we can see not all existing platforms set the registers required in the above recommendation (In Jamie's second patch), so we are trying to provide an architecture-abstraction. Meanwhile, we would notify the platform owner checking the platform-specific setting. After all platform vendor confirmed the setting of FPU we can leave this back to platform setting as you suggested - but secure firmware core logic still needs to check if platform set the FPU setting correctly. @Soby @Jamie, please update if I missed something. BR /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Robert Rostohar via TF-M Sent: Wednesday, September 2, 2020 5:30 PM To: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Changes to configure FPU at the architectural level in TF-M Hi Jamie, I have concerns with moving FPU configuration from platform to architecture-abstraction layer. FPU configuration is typically configured within system configuration files that are standardized in CMSIS and provided by device vendors. Some vendors provide also tools that auto-generate the system file based on user configuration (ex: STM32CubeMX). Therefore it would be better to leave the FPU configuration to the platform rather than moving it into architecture-abstraction. Best regards, Robert From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Jamie Fox via TF-M Sent: Friday 28 August 2020 19:53 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] Changes to configure FPU at the architectural level in TF-M Hi all, There is a change open for review that adds configuration of FPU-related registers to the architecture-abstraction layer in TF-M, and removes this same configuration from platform support files. The reasoning for this is that these registers are defined by the Arm architecture, so FPU config can be unified for all platforms with the same architecture. For Armv8-M, this also includes configuration to ensure that information is not leaked in FPU registers to NSPE when the SPE uses the FPU, and to permit the NSPE to access the FPU. By default, TF-M will still be built without the FPU used in the SPE. You can review the changes at: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5405 Arch: Add function to configure coprocessors https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5406 Platform: Remove platform-specific FPU config It would be especially helpful if platform owners could check that they are happy with FPU config being moved out of the platform support files. Kind regards, Jamie

5 years, 6 months

1
0
0 0

Re: [TF-M] CI Checkpatch

by Soby Mathew

Hi, Just my view on this, One of the things that will be helpful is to have is the checkpatch script imported into the project and have a `make checkpatch` build target. This will help to pipe clean check-patch errors from developer side before pushing patch for review. We could also make it a git hook but then I feel it is less convenient than having a regular build target. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Karl Zhang via TF-M Sent: 02 September 2020 01:56 To: tf-m(a)lists.trustedfirmware.org; Christopher Brand <chris.brand(a)cypress.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] CI Checkpatch Hi Chris, The CI job was trigged from https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/3521, you could find a list of all jobs and status of each job on Gerrit page that triggered by that job, job list example can be found at the end of this email. Another way is from the link you mentioned, that is a pipeline of how CI jobs start from one stage to another stage, if you click on the node of each stage, "Triggered Builds" will list the related job and you can check the details of it. The Open CI for TF-M is under development of Linaro, development plan and status can be found from https://developer.trustedfirmware.org/w/collaboration/openci/ , it is not stable at this moment that we are continuously addressing on. There is no latest document for detail introduction of current Open CI yet. Open CI - developer.trustedfirmware.org<https://developer.trustedfirmware.org/w/collaboration/openci/> Milestone Deliverables Target Completion Status; M1: Planning, Handover and Deployment SOW and project plan Hand over from OCE to Developer Services developer.trustedfirmware.org For the checkpatch job, it is a part of the static check stage, the error from this stage won't impact the final CI score, we need more investigation before active all static checks. The CI jobs were not able to trigger manually. There is a request to Linaro for the requirement that already working on, hope it can be deployed to the public Open CI soon. Job list example on Gerrit after CI job: Passed: 4, Failed: 18, Not done: 0 AN519_GNUARM_ConfigRegressionIPCTfmLevel2_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29147/> -1 AN519_GNUARM_ConfigRegressionIPC_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29146/> -1 AN519_GNUARM_ConfigRegressionProfileS_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29152/> -1 AN519_GNUARM_ConfigRegression_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29144/> -1 .... checkpatch<http://ci.trustedfirmware.org/job/tf-m-checkpatch/472/> -1 cppcheck<http://ci.trustedfirmware.org/job/tf-m-cppcheck/472/> 1 lava_boot<http://ci.trustedfirmware.org/job/tf-m-build-and-test/474/> 1 lava_test<http://ci.trustedfirmware.org/job/tf-m-build-and-test/474/> 1 psoc64_GNUARM_ConfigRegressionIPCTfmLevel2_Release_NOBL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29157/> -1 psoc64_GNUARM_ConfigRegressionIPC_Release_NOBL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29154/> -1 tf-m-build<http://ci.trustedfirmware.org/job/tf-m-build-and-test/479/> -1 tf-m-build-docs<http://ci.trustedfirmware.org/job/tf-m-build-docs/647/> 1 Thanks, Karl Zhang ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Tuesday, September 1, 2020 12:35 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] CI Checkpatch So I see the CI system runs checkpatch, but I don't see any mention of checkpatch under the "docs" directory, or in any of the gerrit reviews, or even on the mailing list. The output in the CI system, as far as I can see, is not particularly useful (I followed the link posted on my review to https://ci.trustedfirmware.org/blue/organizations/jenkins/tf-m-static/detai… but could find anything indicating what issue was actually found). Is there any documentation on how we can run checkptach manually? Or on how to see what the CI version is actually complaining about? Should I just be ignoring the CI checkpatch errors? Thanks, Chris Brand Sr Prin Software Engr, MCD: WIRELESS Cypress Semiconductor Corp. An Infineon Technologies Company #320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com> 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.

5 years, 6 months

1
0
0 0

Re: [TF-M] psa_key_id_t type mismatch --- HardFault

by David Hu

Hi Alamy, In my very own opinion, `psk_key_id_t` defined as structure seems to be Mbed Crypto/MbedTLS own definition and should be transparent to applications calling `psa_open_key()`, as described in https://github.com/ARMmbed/mbedtls/blob/v2.23.0/include/psa/crypto_platform…. TF-M provides standard PSA APIs and therefore the `psa_key_id_t` in `psa_open_key()` is `uint32_t` as defined in PSA Cryptography API v1 Beta 3. The `uint32_t` `psa_key_id_t` is defined in `interface/include/psa/crypto_types.h` and included by TF-M Crypto interface files. Then when TF-M Crypto service invokes Mbed Crypto/MbedTLS APIs to fulfill the `psa_open_key()`, it includes Mbed Crypto/MbedTLS specific header file, in which `psa_key_id_t` is defined as a structure to support multiple client. For example, `crypto_key.c` constructs a `psa_key_id_t` structure and pass it to Mbed Crypto/MbedTLS `psa_open_key()` implementation. (https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…) It requires @Jamie Fox<mailto:Jamie.Fox@arm.com> and @Soby Mathew<mailto:Soby.Mathew@arm.com> help to provide a comprehensive answer. 😉 Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Alamy Liu via TF-M Sent: Tuesday, September 1, 2020 1:23 AM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] psa_key_id_t type mismatch --- HardFault Sorry all, this is a FALSE alarm. Although some codes still include the local header file (uint32_t), none of them use psa_key_id_t at all. Maybe the code should be more clean, but there is no run-time problem! Sorry if it causes problems, Alamy On Mon, Aug 31, 2020 at 8:38 AM Alamy Liu <alamy.liu(a)gmail.com<mailto:alamy.liu@gmail.com>> wrote: Dear all, While I was working on the PSoC64 platform, I hit the psa_key_id_t type mismatch problem. The patch - 98ab441e096f enables MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER Which in terms to use the psa_key_id_t structure (psa_key_file_id_t) in <mbed-crypto/mbedtls>/include/psa/crypto_platform.h Interestingly, psa_key_id_t is also defined in <tf-m>/interface/include/psa/crypto_types.h, as a uint32_t. So, I do the following testing I could compile the master HEAD no problem 66ee5c8861 (HEAD, origin/master, origin/HEAD) Tools: update iat-verifier README and samples I assume the psa_key_id_t should be a structure (from mbed-crypto/mbedtls), I applied the patch below --- a/interface/include/psa/crypto_types.h +++ b/interface/include/psa/crypto_types.h @@ -211,6 +211,8 @@ typedef uint8_t psa_key_persistence_t; */ typedef uint32_t psa_key_location_t; +#if !defined(MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER) +#error Should not compile this /** Encoding of identifiers of persistent keys. * * - Applications may freely choose key identifiers in the range @@ -222,6 +224,7 @@ typedef uint32_t psa_key_location_t; */ typedef uint32_t psa_key_id_t; #define PSA_KEY_ID_INIT 0 +#endif Then, I notice that there are still many files that use uint32_t psa_key_id_t in the TF-M source tree. a) It's good (lucky?) that TF-M seems to cut it cleanly so it doesn't run into problems (well, it happens on PSoC64, or I won't notice it). b) It's bad that psa_key_id_t in TF-M has two different types. I'm not going to argue what's correct/wrong. Maybe this kind of coding could be a feature in the future. I just go with it. But I found no information to define the boundary of the two types under the <tf-m>/docs/ directory. I would like to know where the boundary is, in TF-M. In other words, Which part of the code should use the structure definition from mbedtls/mbed-crypto; which part of the code should use uint32_t ? In my work, the problem happens when it passes psa_key_id_t as a parameter, the parent & child functions see it differently (HardFault, in my case, memory violation to other parameters). e.g.: func_a.c (structure), func_b.c (uint32_t). func_b.h ---- the type changes when it's included by func_a.c and/or func_b.c Regards, Alamy

5 years, 6 months

2
1
0 0

Simpler integration into other projects

by Rønningstad, Øyvind

Hi list I have a proposal to make it easier to integrate TF-M into other existing projects, e.g. RTOSes such as Zephyr. I'm using Zephyr as an example, but I mean that it should apply to any external project that wants to integrate TF-M. I'm assuming the project wants to use the secure FW as is, so no change is needed there. However, in the NS FW we want to integrate the NS callable (PSA) API into native Zephyr applications, but the NS ("app") part of TF-M has some OS dependencies that interfere with this. My proposal is that the TF-M build system creates OS-independent NS libs that can be linked directly into the native Zephyr app. Ideally, the Zephyr build system should need to only do the following: - Call TF-M build system. - Retrieve S binaries (and optionally mcuboot binary). - Link NS lib(s) into project app. - Add include directories to NS callable API. Additionally, the RTOS will likely need to make an OS wrapper to support the OS functions needed. Please tell me your thoughts. I'm not an expert in Cmake and libs, so please also tell me if the above is infeasible in any way. I think making such integrations as simple as possible will be very beneficial, not just when doing the initial integration, but continuously, since changes in TF-M will eventually require tweaks in the integration. Best regards, Øyvind Rønningstad

5 years, 6 months

1
0
0 0

Re: [TF-M] Changes to configure FPU at the architectural level in TF-M

by Ken Liu

Hi Robert, Thanks for the comment, just want to double check if the guidelines for vendors who providing platform sources to a secure software covers the recommendations here: https://lists.trustedfirmware.org/pipermail/tf-m/2020-June/001007.html As far as we can see not all existing platforms set the registers required in the above recommendation (In Jamie's second patch), so we are trying to provide an architecture-abstraction. Meanwhile, we would notify the platform owner checking the platform-specific setting. After all platform vendor confirmed the setting of FPU we can leave this back to platform setting as you suggested - but secure firmware core logic still needs to check if platform set the FPU setting correctly. @Soby @Jamie, please update if I missed something. BR /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Robert Rostohar via TF-M Sent: Wednesday, September 2, 2020 5:30 PM To: Jamie Fox <Jamie.Fox(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Changes to configure FPU at the architectural level in TF-M Hi Jamie, I have concerns with moving FPU configuration from platform to architecture-abstraction layer. FPU configuration is typically configured within system configuration files that are standardized in CMSIS and provided by device vendors. Some vendors provide also tools that auto-generate the system file based on user configuration (ex: STM32CubeMX). Therefore it would be better to leave the FPU configuration to the platform rather than moving it into architecture-abstraction. Best regards, Robert From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Jamie Fox via TF-M Sent: Friday 28 August 2020 19:53 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] Changes to configure FPU at the architectural level in TF-M Hi all, There is a change open for review that adds configuration of FPU-related registers to the architecture-abstraction layer in TF-M, and removes this same configuration from platform support files. The reasoning for this is that these registers are defined by the Arm architecture, so FPU config can be unified for all platforms with the same architecture. For Armv8-M, this also includes configuration to ensure that information is not leaked in FPU registers to NSPE when the SPE uses the FPU, and to permit the NSPE to access the FPU. By default, TF-M will still be built without the FPU used in the SPE. You can review the changes at: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5405 Arch: Add function to configure coprocessors https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5406 Platform: Remove platform-specific FPU config It would be especially helpful if platform owners could check that they are happy with FPU config being moved out of the platform support files. Kind regards, Jamie

5 years, 6 months

1
0
0 0

Re: [TF-M] Changes to configure FPU at the architectural level in TF-M

by Robert Rostohar

Hi Jamie, I have concerns with moving FPU configuration from platform to architecture-abstraction layer. FPU configuration is typically configured within system configuration files that are standardized in CMSIS and provided by device vendors. Some vendors provide also tools that auto-generate the system file based on user configuration (ex: STM32CubeMX). Therefore it would be better to leave the FPU configuration to the platform rather than moving it into architecture-abstraction. Best regards, Robert From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Jamie Fox via TF-M Sent: Friday 28 August 2020 19:53 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Changes to configure FPU at the architectural level in TF-M Hi all, There is a change open for review that adds configuration of FPU-related registers to the architecture-abstraction layer in TF-M, and removes this same configuration from platform support files. The reasoning for this is that these registers are defined by the Arm architecture, so FPU config can be unified for all platforms with the same architecture. For Armv8-M, this also includes configuration to ensure that information is not leaked in FPU registers to NSPE when the SPE uses the FPU, and to permit the NSPE to access the FPU. By default, TF-M will still be built without the FPU used in the SPE. You can review the changes at: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5405 Arch: Add function to configure coprocessors https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5406 Platform: Remove platform-specific FPU config It would be especially helpful if platform owners could check that they are happy with FPU config being moved out of the platform support files. Kind regards, Jamie

5 years, 6 months

1
0
0 0

Re: [TF-M] CI Checkpatch

by Karl Zhang

Hi Chris, The CI job was trigged from https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/3521, you could find a list of all jobs and status of each job on Gerrit page that triggered by that job, job list example can be found at the end of this email. Another way is from the link you mentioned, that is a pipeline of how CI jobs start from one stage to another stage, if you click on the node of each stage, "Triggered Builds" will list the related job and you can check the details of it. The Open CI for TF-M is under development of Linaro, development plan and status can be found from https://developer.trustedfirmware.org/w/collaboration/openci/ , it is not stable at this moment that we are continuously addressing on. There is no latest document for detail introduction of current Open CI yet. Open CI - developer.trustedfirmware.org<https://developer.trustedfirmware.org/w/collaboration/openci/> Milestone Deliverables Target Completion Status; M1: Planning, Handover and Deployment SOW and project plan Hand over from OCE to Developer Services developer.trustedfirmware.org For the checkpatch job, it is a part of the static check stage, the error from this stage won't impact the final CI score, we need more investigation before active all static checks. The CI jobs were not able to trigger manually. There is a request to Linaro for the requirement that already working on, hope it can be deployed to the public Open CI soon. Job list example on Gerrit after CI job: Passed: 4, Failed: 18, Not done: 0 AN519_GNUARM_ConfigRegressionIPCTfmLevel2_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29147/> -1 AN519_GNUARM_ConfigRegressionIPC_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29146/> -1 AN519_GNUARM_ConfigRegressionProfileS_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29152/> -1 AN519_GNUARM_ConfigRegression_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29144/> -1 .... checkpatch<http://ci.trustedfirmware.org/job/tf-m-checkpatch/472/> -1 cppcheck<http://ci.trustedfirmware.org/job/tf-m-cppcheck/472/> 1 lava_boot<http://ci.trustedfirmware.org/job/tf-m-build-and-test/474/> 1 lava_test<http://ci.trustedfirmware.org/job/tf-m-build-and-test/474/> 1 psoc64_GNUARM_ConfigRegressionIPCTfmLevel2_Release_NOBL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29157/> -1 psoc64_GNUARM_ConfigRegressionIPC_Release_NOBL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29154/> -1 tf-m-build<http://ci.trustedfirmware.org/job/tf-m-build-and-test/479/> -1 tf-m-build-docs<http://ci.trustedfirmware.org/job/tf-m-build-docs/647/> 1 Thanks, Karl Zhang ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Tuesday, September 1, 2020 12:35 AM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] CI Checkpatch So I see the CI system runs checkpatch, but I don’t see any mention of checkpatch under the “docs” directory, or in any of the gerrit reviews, or even on the mailing list. The output in the CI system, as far as I can see, is not particularly useful (I followed the link posted on my review to https://ci.trustedfirmware.org/blue/organizations/jenkins/tf-m-static/detai… but could find anything indicating what issue was actually found). Is there any documentation on how we can run checkptach manually? Or on how to see what the CI version is actually complaining about? Should I just be ignoring the CI checkpatch errors? Thanks, Chris Brand Sr Prin Software Engr, MCD: WIRELESS Cypress Semiconductor Corp. An Infineon Technologies Company #320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com> 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.

5 years, 6 months

1
0
0 0

[RFC] The code review guideline

by Ken Liu

Hi, We are creating one document to describe the code review guidelines: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5372 The goal of this document is to introduce the source management level concepts to be followed while reviewing a code – which try to simplify the contribution (but burdens the reviewers? 😉). Difference to the `coding style`: * It focuses more on the source placement, interface definition and including, etc. As this document is keeping evolving in a period, the plan is we merge a simple version as start and adding more contents by new patches, so please give enough comments if you have, and don’t forget the concept: we want to make things rational and simple. Thanks. /Ken

5 years, 6 months

1
0
0 0

psa_key_id_t type mismatch --- HardFault

by Alamy Liu

Dear all, While I was working on the PSoC64 platform, I hit the *psa_key_id_t* type mismatch problem. The patch - *98ab441e096f *enables *MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER* Which in terms to use the *psa_key_id_t* *structure* (psa_key_file_id_t) in <mbed-crypto/mbedtls>/include/psa/*crypto_platform.h* Interestingly, psa_key_id_t is also defined in <tf-m>/interface/include/psa/ *crypto_types.h*, as a uint32_t. So, I do the following testing I could compile the master HEAD no problem *66ee5c8861* (HEAD, origin/master, origin/HEAD) Tools: update iat-verifier README and samples I assume the psa_key_id_t should be a *structure* (from mbed-crypto/mbedtls), I applied the patch below --- a/interface/include/psa/crypto_types.h +++ b/interface/include/psa/crypto_types.h @@ -211,6 +211,8 @@ typedef uint8_t psa_key_persistence_t; */ typedef uint32_t psa_key_location_t;+#if !defined(MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER)+#error Should not compile this /** Encoding of identifiers of persistent keys. * * - Applications may freely choose key identifiers in the range @@ -222,6 +224,7 @@ typedef uint32_t psa_key_location_t; */ typedef uint32_t psa_key_id_t; #define PSA_KEY_ID_INIT 0+#endif Then, I notice that there are still many files that use *uint32_t* psa_key_id_t in the TF-M source tree. a) It's good (lucky?) that TF-M seems to cut it cleanly so it doesn't run into problems (well, it happens on PSoC64, or I won't notice it). b) It's bad that psa_key_id_t in TF-M has two different types. I'm not going to argue what's correct/wrong. Maybe this kind of coding could be a feature in the future. I just go with it. But I found no information to define the boundary of the two types under the <tf-m>/docs/ directory. I would like to know where the boundary is, in TF-M. In other words, *Which part of the code should use the structure definition from mbedtls/mbed-crypto; which part of the code should use uint32_t ?* In my work, the problem happens when it passes psa_key_id_t as a parameter, the parent & child functions see it differently (HardFault, in my case, memory violation to other parameters). e.g.: func_a.c (structure), func_b.c (uint32_t). func_b.h ---- the type changes when it's included by func_a.c and/or func_b.c Regards, Alamy

5 years, 6 months

1
1
0 0

CI Checkpatch

by Christopher Brand

So I see the CI system runs checkpatch, but I don't see any mention of checkpatch under the "docs" directory, or in any of the gerrit reviews, or even on the mailing list. The output in the CI system, as far as I can see, is not particularly useful (I followed the link posted on my review to https://ci.trustedfirmware.org/blue/organizations/jenkins/tf-m-static/detai… but could find anything indicating what issue was actually found). Is there any documentation on how we can run checkptach manually? Or on how to see what the CI version is actually complaining about? Should I just be ignoring the CI checkpatch errors? Thanks, Chris Brand Sr Prin Software Engr, MCD: WIRELESS Cypress Semiconductor Corp. An Infineon Technologies Company #320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com> 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.

5 years, 6 months

1
0
0 0

Changes to configure FPU at the architectural level in TF-M

by Jamie Fox

Hi all, There is a change open for review that adds configuration of FPU-related registers to the architecture-abstraction layer in TF-M, and removes this same configuration from platform support files. The reasoning for this is that these registers are defined by the Arm architecture, so FPU config can be unified for all platforms with the same architecture. For Armv8-M, this also includes configuration to ensure that information is not leaked in FPU registers to NSPE when the SPE uses the FPU, and to permit the NSPE to access the FPU. By default, TF-M will still be built without the FPU used in the SPE. You can review the changes at: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5405 Arch: Add function to configure coprocessors https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5406 Platform: Remove platform-specific FPU config It would be especially helpful if platform owners could check that they are happy with FPU config being moved out of the platform support files. Kind regards, Jamie

5 years, 6 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M