- TF-M - lists.trustedfirmware.org

CMAKE library dependency trace tool for TF-M

by Jianliang Shen

Hi all, I'd like to introduce a CMAKE library dependency trace tool to you. This python script can * Search a specific library's dependent libraries and to-be-linked libraries in a list of repo paths. * Draw a diagram to show the link relationship. * Give some other information about: * Include paths * Source files * Compile definitions The main feature of diagram is similar with [CMakeGraphVizOptions]<https://cmake.org/cmake/help/latest/module/CMakeGraphVizOptions.html#cmakeg…>, the differences are: * The new tool can focus on certain library with specific trace depth like 1, 2 and n. * The new tool is not runtime, it is a static search and can search all libraries whose runtime build may be silenced. * The new tool makes the diagram more colourful to be more readable. With this tool, I hope you can get and check the structure of CMAKE library more quickly when developing the code and libraries. I have proposed a patch in tf-m-tools repo: [library dependency trace tool]<https://review.trustedfirmware.org/c/TF-M/tf-m-tools/+/12019>. This tool may not be convenient for everyone of you so here I beg for your feedbacks to make it better. Thanks. Best Regards Jianliang Shen

4 years

1
0
0 0

[ATTENTION] SPM logic is under significant updating before End of Oct

by Ken Liu

Hi, To support FFM 1.1 features (SFN mainly), the SPM logic is under significant updating till End of Oct, please: - If you are doing release-targeted development, please based on the released tags. - If you are developing with the latest master branch, please report bugs met. Our plan is to collect all bugs and fix them after this update, before the next release. - Keen to receive your fixes and contributions. It would be very nice if you can do these. All patches would go as a usual process, hence it should work for most of the configurations, except those not covered by the automation test. The platform related interfaces are not changing, hence no worry for platform owners. Thanks! /Ken

4 years

1
0
0 0

Re: [TF-M] Sending events from TF-M to non-secure world?

by Li, Jun R

Hi Ken, Thanks for the nice suggestions! I was thinking of using an interrupt from TF-M to NS world as well but that needs some hardware support, which should be fine since I'm still designing the device. Maybe there is a software interrupt solution? Our application needs to put a biometric service inside TF-M and its enrollment process needs to send out some intermediate events to give the user some feedbacks. This is why I'm asking this question. I think TF-M can use an input buffer from NS world to store the new events and notify the NS world with the interrupt to fetch the new events. Sounds good? Regards, Jun On 10/19/21, 00:23, "TF-M on behalf of tf-m-request(a)lists.trustedfirmware.org" <tf-m-bounces(a)lists.trustedfirmware.org on behalf of tf-m-request(a)lists.trustedfirmware.org> wrote: Send TF-M mailing list submissions to tf-m(a)lists.trustedfirmware.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.trustedfirmware.org/mailman/listinfo/tf-m or, via email, send a message with subject or body 'help' to tf-m-request(a)lists.trustedfirmware.org You can reach the person managing the list at tf-m-owner(a)lists.trustedfirmware.org When replying, please edit your Subject line so it is more specific than "Re: Contents of TF-M digest..." Today's Topics: 1. Re: Sending events from TF-M to non-secure world? (Ken Liu) 2. Inline asm syntax unified and symbol reference in IAR toolchain (Ken Liu) ---------------------------------------------------------------------- Message: 1 Date: Tue, 19 Oct 2021 02:06:35 +0000 From: Ken Liu <Ken.Liu(a)arm.com> To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Sending events from TF-M to non-secure world? Message-ID: <DB9PR08MB67613655A2ACA207C751C791F5BD9(a)DB9PR08MB6761.eurprd08.prod.outlook.com> Content-Type: text/plain; charset="utf-8" Hi Jun, Basically, the service accessing model is a client-service model, hence the service won't call back to the client which makes the client a 'service'. Service can get client info by passed-in parameters and other SPM controlled channels. Assuming you are using a Trustzone based hardware, the hardware provides the capability that calling back to NSPE, but it is not encouraged inside TF-M because it breaks the simplified model proposed by FF-M and difficulties the secure threat analysis - a simple case is that the secure context is blocked because it is waiting for NS returns. If you do need to perform such operations, implement an interrupt based asynchronous mechanism is safer than software callbacks. The most queried requirement we have met is someone querying if the execution can be delivered back to NSPE when secure IDLE is going to happen. Not sure if you are facing the similar, is it okay to share more details? BR /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Li, Jun R via TF-M Sent: Tuesday, October 19, 2021 12:20 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Sending events from TF-M to non-secure world? Hi, Anyone has idea how a service inside a secure partition can send out some events to the non-secure world? Does callback still work over IPC? It seems non-secure world can connect to a SP but not easy to do the other way. Appreciate any comments or suggestions! Jun Intel Corporation @ SC, CA -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.trustedfirmware.org/pipermail/tf-m/attachments/20211019/1ff875…>

4 years

2
1
0 0

Re: [TF-M] Enablement of external bl2 builds

by Bohdan.Hunko＠infineon.com

Hi Sherry, So I actually checked issue from last mail ‘When building TFM with CRYPTO_HW_ACCELERATOR=ON and BL2=OFF I am getting this error:’ and turns out everything is fine in master branch, that error is only present in my local branch due to changes I have made. I am glad we have one bug less 😊 Sorry for wrong report. Best regards, Bohdan Hunko Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com> From: Hunko Bohdan (CSUKR CSS ICW SW FW) Sent: 01 October 2021 12:49 To: Hunko Bohdan (CSUKR CSS ICW SW FW) <Bohdan.Hunko(a)infineon.com>; Sherry.Zhang2(a)arm.com; Brand Chris (CSCA CSS ICW SW PSW 1) <Chris.Brand(a)infineon.com>; Kytsun Hennadiy (CSUKR CSS ICW SW FW) <Hennadiy.Kytsun(a)infineon.com>; Mazurak Roman (CSUKR CSS ICW SW FW) <Roman.Mazurak(a)infineon.com>; Tkachov Kostiantyn (CSUKR CSS ICW SW FW) <Kostiantyn.Tkachov(a)infineon.com> Cc: nd(a)arm.com Subject: RE: Enablement of external bl2 builds Hi all, One more thing on this topic. There is one more issue with building TFM without BL2. When building TFM with CRYPTO_HW_ACCELERATOR=ON and BL2=OFF I am getting this error: CMake Error at platform/ext/accelerator/CMakeLists.txt:11 (add_library): No SOURCES given to target: bl2_crypto_hw So I think this is one more thing that needs to be fixed. Best regards, Bohdan Hunko Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Bohdan Hunko via TF-M Sent: 30 September 2021 17:34 To: Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Brand Chris (CSCA CSS ICW SW PSW 1) <Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com>>; Kytsun Hennadiy (CSUKR CSS ICW SW FW) <Hennadiy.Kytsun(a)infineon.com<mailto:Hennadiy.Kytsun@infineon.com>>; Mazurak Roman (CSUKR CSS ICW SW FW) <Roman.Mazurak(a)infineon.com<mailto:Roman.Mazurak@infineon.com>>; Tkachov Kostiantyn (CSUKR CSS ICW SW FW) <Kostiantyn.Tkachov(a)infineon.com<mailto:Kostiantyn.Tkachov@infineon.com>> Cc: nd(a)arm.com<mailto:nd@arm.com> Subject: Re: [TF-M] Enablement of external bl2 builds Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informati…>. Hi Sherry, Thanks for patching MCUBOOT_IMAGE_NUMBER issue. It was one of the issues we faced with. I also agree that mcuboot_config.h should be taken from our BL2 repo. So no changes needed there. About porting files (tfm/bl2 folder). We are planning to use existing porting files. But as you said currently they are not included into the build because BL2=0. So this needs to be fixed to include these porting files when TFM_PARTITION_FIRMWARE_UPDATE is ON. One minor issue we have is BOOT_DATA_AVAILABLE currently it is only defined if BL2=1 and MCUBOOT_MEASURED_BOOT=1. See this line of code<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…>. I think we can either change that line of code or we can defile BOOT_DATA_AVAILABLE in our platform files using add_definitions(-DBOOT_DATA_AVAILABLE). First way is a bit harder but I thinks it fits better into TFM architecture. Second way is easier but it seems more like workaround than like solution. Do you have any suggestions about this problem? We are not blocked by these issues, so no worries here. Best regards Bohdan Hunko Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com> From: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>> Sent: 30 September 2021 11:38 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Tkachov Kostiantyn (CSUKR CSS ICW SW FW) <Kostiantyn.Tkachov(a)infineon.com<mailto:Kostiantyn.Tkachov@infineon.com>>; Mazurak Roman (CSUKR CSS ICW SW FW) <Roman.Mazurak(a)infineon.com<mailto:Roman.Mazurak@infineon.com>>; Kytsun Hennadiy (CSUKR CSS ICW SW FW) <Hennadiy.Kytsun(a)infineon.com<mailto:Hennadiy.Kytsun@infineon.com>>; Hunko Bohdan (CSUKR CSS ICW SW FW) <Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: Enablement of external bl2 builds Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informati…>. Hi Bohdan, I tried to build TF-M with FWU service without BL2 with the following command(FWU enabled with shared data while no BL2): cmake -S . -B cmake_build -DTFM_PLATFORM=arm/musca_b1/sse_200 -DCRYPTO_HW_ACCELERATOR=OFF -DPLATFORM_DUMMY_NV_SEED=ON -DBL2=0 -DMCUBOOT_PATH=../mcuboot The following issues I met: 1. Build time error by that ` MCUBOOT_IMAGE_NUMBER ` is passed as an empty macro into the flash_layout.h I have created a patch to fix it. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11729 1. Build error in ` bootutil_public.c `. The mcuboot_config.h which is generated automatically when the BL2=ON is not found. Also the files( in tf-m/bl2 folder) about porting MCUboot into TF-M is not found by the build system as BL2=0. For the config file, I think, it should be imported from your specific MCUboot repo as it is generated when BL2 image is built. For the MCUboot porting files, are you using the files under tf-m/bl2 folder or using your specific porting files? The FWU service needs the porting source files. See code at https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…. Are your blocked by these two issues? Can you share the detailed issue you met if there is more? Regards, Sherry From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Bohdan Hunko via TF-M Sent: Tuesday, September 28, 2021 6:44 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: Kostiantyn.Tkachov(a)infineon.com<mailto:Kostiantyn.Tkachov@infineon.com>; Roman.Mazurak(a)infineon.com<mailto:Roman.Mazurak@infineon.com>; Hennadiy.Kytsun(a)infineon.com<mailto:Hennadiy.Kytsun@infineon.com> Subject: [TF-M] Enablement of external bl2 builds Hi everyone, When adding support for new platform we ran into an issue with BL2 variable. In our architecture we have Bootloader based on MCUboot (aka BL2) but we are not planning to build it with TF-M. Bootloader would be separate repo and be built separately. So we need the way to build TF-M with FWU service and shared data definitions when BL2=OFF. I was trying to add support for this but was not able to do this because build structure is quite complicated. Does anyone have ideas or suggestions about the way we can implement this feature? Best regards, Bohdan Hunko Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>

4 years

2
3
0 0

Deprecation of ARM/MPS2/fvp_sse300 platform

by Anton Komlev

Hi Everyone, I would like to propose the deprecation of arm/mps2/fvp_sse300 platform because the main platform for Corstone-300 is MPS3, available in arm/mps3/an547 and we would like to reduce the number of the platforms to maintain. Following the deprecation process, https://tf-m-user-guide.trustedfirmware.org/platform/ext/platform_deprecati… this proposal is open for discussion at least for 4 weeks before the platform will be marked as deprecated and removed from TF-M unless any objection received. Thanks and Best regards, Anton Komlev

4 years

1
1
0 0

Announcement: documentation build is separated from the main.

by Anton Komlev

Hello, >From now on, documentation has no interference with the main build and runs as an independent CMake project. This reduces CMake configuration phase and not requires doc tools for the normal development anymore. There are no changes for building the binaries, but documentation build shall start in the docs folder cmake -S docs -B build_docs cmake --build build_docs More details are here: https://tf-m-user-guide.trustedfirmware.org/docs/technical_references/instr… Thanks, Anton

4 years

1
0
0 0

Sending events from TF-M to non-secure world?

by Li, Jun R

Hi, Anyone has idea how a service inside a secure partition can send out some events to the non-secure world? Does callback still work over IPC? It seems non-secure world can connect to a SP but not easy to do the other way. Appreciate any comments or suggestions! Jun Intel Corporation @ SC, CA

4 years

2
1
0 0

PSA Arch attestation test failure

by Chris.Brand＠infineon.com

Hi, We're seeing a failure in the PSA Arch attestation test, specifically: TEST: 601 | DESCRIPTION: Testing attestation initial attestation APIs | UT: psa_initial_attestation [Info] Executing tests from non-secure [Check 1] Test psa_initial_attestation_get_token with Challenge 32 [Check 2] Test psa_initial_attestation_get_token with Challenge 48 Failed at Checkpoint: 1 Actual: -138 Expected: 0 TEST RESULT: FAILED (Error Code=0x1) The failure is seen on PSoC, but only the gcc Release build (armclang and the other three gcc builds are all fine. Haven't tested IAR), which makes it tricky to debug. PSoC uses the common attest HAL code, though, so I imagine the issue may also be present on other platforms. Bisecting the problem leads to commit 09d71ffd40368b978d428744ad7ba0d3963f8d1d ("Platform: Use OTP as backing for attestation data"). -138 is PSA_ERROR_BUFFER_TOO_SMALL. I'm running gcc-arm-none-eabi-7-2018-q2-update, in case that matters. Chris Brand Cypress Semiconductor (Canada), Inc. Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com>

4 years

3
6
0 0

Automatic code formatting

by Bøe, Sebastian

Hi, does anyone have a .clang-format file, or another technology for automatic code formatting to the TF-M coding standard?

4 years

2
2
0 0

Platform specific test out-of-tree build

by Jianliang Shen

Hi all, Thanks for Chris Brand's enhancement suggestion about platform-specific tests. I'm enabling out-of-tree build mode of platform specific test suites with tf-m-tests. Currently I have proposed the following changes: * [TF-M patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11296>] * [tf-m-tests patch<https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/11297>] My proposal supplies a flexible interface for partners to out-of-tree build local tests. With this new feature, * Partners can perform local test quickly during development to improve test efficiency * Partners can maintain local test code outside tf-m-tests repo in case of confidential information or IP issues. I also put an out-of-tree example test source code into tf-m-extras repo and a document in TF-M repo: * [tf-m-extras patch<https://review.trustedfirmware.org/c/TF-M/tf-m-extras/+/11323>] * [TF-M patch doc<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11336>] This example indicates that platform-specific tests can be integrated with tf-m-tests, without following tf-m-tests structure or definitions. The document introduces the usage and coding guide of this new feature. PS: If partners would like to upstream platform specific test code, we will be glad to create a specific folder under tf-m-tests repo as Chris Brand suggested. I'd be grateful if you can take a look at the patch sets above. Any suggestion or comment is welcome. Best Regards Jianliang Shen

4 years

1
2
0 0

Re: [TF-M] Adding platform specific functions to Crypto Service.

by Roman.Mazurak＠infineon.com

Hi Fabian, Yes, our team is thinking about adding feature to the Crypto service API, which are not cryptographic in nature. This is one of the possible solution in our design to avoid additional data processing layer between cryptographic clients and crypto accelerator. Our crypto accelerator also provides additional features which will be used by other secure partitions in TF-M but it doesn’t support handling of crypto and non-crypto requests at the same time. It’s not a problem for CC312 which is used for crypto services and OTP in the latest commit. As far as I understand CC312 allows to use crypto operations and OTP related functions at the same time without additional synchronization. So, the reference design is not very helpful in our situation. So, implementation of additional service is not the best solution. It will extend processing time for each cryptographic requests. The other option is to implement synchronization by using mutex. I think mutex is preferable approach, but this feature is also not support by TF-M yet 😊 There is the discussion which I started for mutex : https://lists.trustedfirmware.org/pipermail/tf-m/2021-October/001914.html Thanks, Roman. From: Fabian Schmidt <fabian.schmidt(a)nxp.com> Sent: Tuesday, October 12, 2021 13:47 To: Shebu.VargheseKuriakose(a)arm.com; David.Hu(a)arm.com; Mazurak Roman (CSUKR CSS ICW SW FW) <Roman.Mazurak(a)infineon.com>; mbed-tls(a)lists.trustedfirmware.org Cc: nd(a)arm.com Subject: RE: [TF-M] Adding platform specific functions to Crypto Service. Hi Roman, My understanding is that you would like to add features to the Crypto service API, but the features which you would like to add are not cryptographic in nature. Have you considered creating your own service for those features, instead of modifying the Crypto service? Or is there anything makes this not a viable option? If you are thinking about adding hardware acceleration for some Crypto features, that’s indeed covered in Shebu’s link. Greetings, Fabian Schmidt From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shebu Varghese Kuriakose via TF-M Sent: Dienstag, 12. Oktober 2021 11:46 To: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>>; Roman.Mazurak(a)infineon.com<mailto:Roman.Mazurak@infineon.com>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [EXT] Re: [TF-M] Adding platform specific functions to Crypto Service. Caution: EXT Email Hi Roman, I also might not have understood the question completely. As you mention crypto HAL API, here is the specification which defines a standardized mechanism for PSA Crypto implementations to interface with Secure elements and crypto accelerators - https://github.com/ARMmbed/mbedtls/blob/development/docs/proposed/psa-drive…<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> Also adding mbed-tls mailing list as the thread is crypto related.. Regards, Shebu From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of David Hu via TF-M Sent: Tuesday, October 12, 2021 4:18 AM To: Roman.Mazurak(a)infineon.com<mailto:Roman.Mazurak@infineon.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] Adding platform specific functions to Crypto Service. Hi Roman, Are you asking about adding platform specific HAL API to implement PSA Crypto API function? Please correct me if I misunderstand your question. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Roman Mazurak via TF-M Sent: Monday, October 11, 2021 9:45 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Adding platform specific functions to Crypto Service. Hi all, We would like to add a number of platform specific functions to Crypto Service API. Is it ok if such functions will not be related to cryptographic service, but such approach allows us to optimize platform design? Is there any initiative to create a Crypto Service HAL API to extend Crypto with custom functions? Best regards, Roman.

4 years

2
2
0 0

TF-M Cadence change proposal

by Anton Komlev

Hello, Following the Tech Forum today I am duplicating the proposal of TF-M cadence change from 4 to 6 months here. This will generate 2 releases a year, planed for the end or March and the end of October starting from v1.6.0. The upcoming release v1.5.0 will stay on planned date. Please share your comments and concerns on the topic. Thanks, Anton

4 years

1
0
0 0

PSA API crypto test breakage

by Chris.Brand＠infineon.com

Commit 42e77b561fcfe19819ff1e63cb7c0b672ee8ba41 ("Crypto: Remove TF-M Crypto service key handle array") seems to break PSA Arch Crypto test 218 (on PSoC64, with gcc, at least). After this commit, the test reports Failed at Checkpoint: 7 Actual: -137 Expected: -136 (so actual is PSA_ERROR_BAD_STATE and expected is PSA_ERROR_INVALID_HANDLE). That same test passes with the previous commit. Chris Brand Cypress Semiconductor (Canada), Inc. Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com>

4 years

2
2
0 0

FWU mark TFM image as accepted

by Bohdan.Hunko＠infineon.com

Hi everyone, When studying FWU service I have noticed that there is a function psa_status_t psa_fwu_accept(psa_image_id_t image_id) It is used to mark image as accepted, and it works by writing magic number to image trailer. This function can be used to mark NS or S application as accepted. The first question is: who is responsible for making a call to mark TFM image as accepted ? Is this responsibility of NS application? The second thing I see is write access problem. TFM can receive a call to mark TFM image as accepted, so this means that TFM must have permission to write in its own primary slot. Doesn't this create a possibility for security violation? I can imagine that in ideal world TFM would only have Read and Execute mission for its own primary slot. The only thing that should be able to write to TFM primary slot should be bootloader (it need this functionality to swap images). No one else should be able to write into TFM primary slot. Am I missing something? Best regards, Bohdan Hunko Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>

4 years

4
3
0 0

Technical Forum call - Oct 14

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, Oct 14, 7:00-8:00 UTC (Asia 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

4 years

1
1
0 0

Mutex in SPE

by Roman.Mazurak＠infineon.com

Hi all, We need a mutex to protect access to a shared resource within Platform RoT Services. Is there any plan to add implementation of mutex in TF-M? Maybe it should be a platform specific implementation? Thanks, Roman.

4 years

2
1
0 0

TF Open CI FYI

by Don Harbin

Hi all, In a discussion with Anton, it was realized that all contributors may not be aware of some of the information available regarding Open CI. If interested in digging deeper and understanding here are some helpful links. - The Open CI "mini-website" can be found here <https://www.trustedfirmware.org/projects/open-ci/>. - Note in the intro paragraph a hotlink to the *Open CI Lava farm* showing the hardware platforms in the lab, recent test results, etc. Note it requires a login to see all the information - Also of value is a detailed *users guide* that provides an overview of Open CI. You can click on the "docs" icon or just go here <https://tf-ci-users-guide.readthedocs.io/en/latest/>. It's a living document and contributions are encouraged. :) - This page also shares how to get further involved and the location of the code. Best regards, Don

4 years

1
0
0 0

Adding platform specific functions to Crypto Service.

by Roman.Mazurak＠infineon.com

Hi all, We would like to add a number of platform specific functions to Crypto Service API. Is it ok if such functions will not be related to cryptographic service, but such approach allows us to optimize platform design? Is there any initiative to create a Crypto Service HAL API to extend Crypto with custom functions? Best regards, Roman.

4 years

3
2
0 0

Enable a peripheral interrupt to an App RoT

by Cristiano Rodrigues

Hi everyone, I am developing an App RoT for STM32L552 and testing the recent integrated FLIH interrupt feature, but I am missing something in the step of "Initializing the Interrupts" and "Integrating the Interrupt Handling Function". As is described in Secure Interrupt Integration Guide <https://tf-m-user-guide.trustedfirmware.org/docs/integration_guide/tfm_secu…>, to enable an interrupt it is needed: 1. Binding the interrupt to a Secure Partition. 2. Granting the Secure Partition access permissions to the device of the interrupt. 3. Initializing the interrupt. 4. Integrating the interrupt handling function Step *1 *and *2, * think that is "checked": - by adding this code to the partition manifest file. "mmio_regions": [ { "name": "TFM_PERIPHERAL_TIMER7", "permission": "READ-WRITE" } ], "irqs": [ { "source": "TFM_TIMER7_IRQ", "name": "TFM_TIMER7_IRQ", "handling": "FLIH", } - By defining the macro with platform peripheral structure in *patform/ext/target/stm/common/stm32l5xx/boards/tfm_peripherals_def.h* extern struct platform_data_t timer7 #define TFM_PERIPHERAL_TIMER7 &timer7 - *By assign the peripheral address in platform\ext\target\stm\common\stm32l5xx\secure\target_cfg.c* struct platform_data_t timer7 = { __TIMER7_BASE, __TIMER7_BASE + 0x3FF, -1, -1 }; - By adding the peripheral name to “partition_named_mmio_list[]” in the file *patform/ext/target/stm/common/stm32l5xx/boards/mmio_defs.h* const uintptr_t partition_named_mmio_list[] = { (uintptr_t)TFM_PERIPHERAL_TIMER0, (uintptr_t)TFM_PERIPHERAL_STD_UART, (uintptr_t) TFM_PERIPHERAL_TIMER7, }; - And add to my partition code, the irq function, and the function to configure the timer psa_flih_result_t tfm_timer7_irq_flih(void) { .... } static void flih_test_case_1(psa_msg_t *msg) { psa_irq_enable(TFM_TIMER7_IRQ_SIGNAL); timer_start(); ....... timer_stop(); psa_irq_disable(TFM_TIMER7_IRQ_SIGNAL); psa_reply(msg->handle, PSA_SUCCESS); } My problem, I think, is with the other two steps, *3 *and *4. *The TF-M documentation is not clear in these two steps. In step *3, *as is said in the documentation it is needed: i) to configure the interrupt priority; ii) to ensure that the interrupt targets the Secure State. iii) and save the interrupt information. So I suppose it goes something like this: struct irq_t { void *p_pt; struct irq_load_info_t *p_ildi; } save_tfm_timer7_irq_info; enum tfm_hal_status_t tfm_timer7_irq_init(void *p_pt, struct irq_load_info_t *p_ildi) { //targetting the interrupt to S state NVIC_ClearTargetState(TIM7_IRQn); NVIC_SetPriority(TIM7_IRQn, 1); NVIC_EnableIRQ(TIM7_IRQn); //Saving the Interrupt Information save_tfm_timer7_irq_info.p_pt = p_pt; save_tfm_timer7_irq_info.p_ildi = p_ildi; return TFM_HAL_SUCCESS; } *But in which file should I put this function? And where should I call this function??* And in step *4, *I also do not understand how can I meet this requirement -> "Platforms should call this entry function in the interrupt handlers defined in Vector Table with the saved information for each interrupt." Being the function in question -> *void spm_handle_interrupt(void *p_pt, struct irq_load_info_t *p_ildi).* *Which file can I do this in? And how should I do this step?* Cheers, Cristiano Rodrigues

4 years

2
1
0 0

Boot shared data TLV length

by Bohdan.Hunko＠infineon.com

Hi everyone, IAS docs have this<https://tf-m-user-guide.trustedfirmware.org/docs/integration_guide/services…> note that says: There is a size field tlv_len which has different definitions in the upstream MCUboot repository and in its TF-M forked version: * Upstream MCUboot: Covers only the length of data but not the header size. * TF-M MCUboot: Covers the size of the entry header and the data together. This difference is handled by TF-M code based on which bootloader is used along with TF-M runtime. I was wondering where in code is this difference handled? When calculating next TLV entry address attest_core.c line 213<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…> takes into account SHARED_DATA_ENTRY_HEADER_SIZE: tlv_curr = (*tlv_ptr) + SHARED_DATA_ENTRY_HEADER_SIZE + tlv_entry.tlv_len; So tlv_entry.tlv_len then must cover only length of entry (without header). This way corresponds to: "Upstream MCUboot: Covers only the length of data but not the header size" I was not able to find anything related to "TF-M MCUboot: Covers the size of the entry header and the data together". Is this difference handled in TF-M fork of MCUboot or is it just outdated IAS doc? Best regards, Bohdan Hunko Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>

4 years

2
1
0 0

Problem with PSoC armclang build

by Chris.Brand＠infineon.com

Hi, We've been investigating a problem with the armclang builds for PSoC. The symptoms are that the board just repeatedly reboots. We've narrowed it down to commit 300c68da11 "SPM: Use Main Stack for initialization". This commit is fine with the gcc toolchain but doesn't seem right for armclang (we haven't yet looked at IAR). Still digging into the issue, but I figured it might be helpful to give it more publicity. Chris Brand Cypress Semiconductor (Canada), Inc. Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com>

4 years

2
3
0 0

nxp/lpcxpresso55s69 builds broken

by Thomas Törnblom

While verifying that my Musca B1/S1 fixes for IAR did not break other targets I ran into building problems for the nxp/lpcxpresso55s69 for both gnuarm and iararm. I've tested with the following cmake line: cmake -GNinja -S .. -B . -DTFM_PLATFORM=nxp/lpcxpresso55s69 "-DTFM_TOOLCHAIN_FILE=..\toolchain_GNUARM.cmake" -DTEST_NS=ON -DTEST_S=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo -DTFM_PSA_API=ON -DBL2=OFF Fails with: d:/apps/gnuarm/10-2020-q4-major/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld.exe: C:\Users\thomasto\Projects\tf-m12\trusted-firmware-m\gnuarm/../secure_fw/spm/ffm/psa_api.c:890: undefined reference to `tfm_hal_irq_disable' I notice that tfm_hal_irq_disable() is guarded by: #if TFM_LVL == 3 in .../nxp/common/tfm_hal_isolation.c, while the other targets does not have this guard. What isthe reason for that? Trying to set that with cmake causes other failures. commit 8444011d works commit 4051016f fails I tried bisecting between these two commits, but the builds run into other build failures so I gave up on that. Is his a known issue? I have successfully built and run regression tests on musca b1, musca s1, psoc64 and I have built, but not run an519, an521, an524 Cheers, 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>

4 years, 1 month

2
2
0 0

[PLATFORM ATTENTION REQUIRED] Partition interrupt binding patches have been merged

by Ken Liu

Dear platform owners, Theses interrupt binding patch(es) are merged: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11474 As the most part of the change happen in platform, please report platform integration if you met. Sorry I had thought the notification mail has been sent during the PR stage but it did not, hence it is not broadcasted in time. Current there are build errors reported on nxp/nordic platforms, and this patch should fix the problem: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11741 Also, Ci reported arch-test build fail, hence the fix for arch-test is here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11742 Feel free to put comments and I will update them later, or just update the patch if it is quick for you, add your name into the author in commit message. You also can create standalone patches if you change is not covered by mentioned patches. Thanks. /Ken

4 years, 1 month

1
0
0 0

Enablement of external bl2 builds

by Bohdan.Hunko＠infineon.com

Hi everyone, When adding support for new platform we ran into an issue with BL2 variable. In our architecture we have Bootloader based on MCUboot (aka BL2) but we are not planning to build it with TF-M. Bootloader would be separate repo and be built separately. So we need the way to build TF-M with FWU service and shared data definitions when BL2=OFF. I was trying to add support for this but was not able to do this because build structure is quite complicated. Does anyone have ideas or suggestions about the way we can implement this feature? Best regards, Bohdan Hunko Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>

4 years, 1 month

3
3
0 0

Technical Forum call - Sep 30

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, Sep 30, 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

4 years, 1 month

1
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M