- TF-M - lists.trustedfirmware.org

Re: Backwards compatibility of Protected Storage implementation (TF-M 1.8.1 -> 2.1.1)

by Miika Karanki

Hi Anton and Chris, Thank you for your replies. I have TFM_NS_MANAGE_NSID set to off. That does not prevent client_id translation to happen. `tfm_nspm_get_current_client_id` seems to do translation unconditionally here: https://git.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m.git…. But as said, setting client_id_limit in code to -1 helps. Maybe there could be additional configuration #define whether to do translation when TFM_NS_MANAGE_NSID is off. Transition approach to convert the old PS data format to new one on the flash when reading data in new format fails sounds reasonable assuming there's no security problems involved in retrying to read the objects using the old format after a failure. Probably not. It anyways sounds better than supporting the old one "forever". At least to me, being able to do that transition would require a bit of learning what exactly was the old and what is the new layout. If there's some material in addition to source code, I'd be happy to check that. -Miika ke 27.11.2024 klo 23.01 Chris.Brand--- via TF-M ( tf-m(a)lists.trustedfirmware.org) kirjoitti: > Hi Miika, > > > > Unfortunately there have been a couple of changes to the way that PS data > is stored in flash. I hope that we are getting better at considering > backwards compatibility. In general I think that whenever we do introduce a > change like this, we need to ensure that data stored with the old layout > can still be read by newer code. > > > > I believe the patch that you’ve identified was part of the work to make PS > encryption optional. Looking at it now, I don’t see that the layout was a > necessary part of that work. Unfortunately, we’re now in a position where > there could be PS data stored on devices in this new format, so just > reverting that part of that patch would cause other problems. > > > > The bad news is that there’s another stored format change post-v2.1.1. The > good news is that we did think about existing data and introduced a build > option to read the old format. > > > > One solution to your problem would be similar to > https://github.com/TrustedFirmware-M/trusted-firmware-m/commit/e8d48d78c166… > - a build option to support reading the old format, with stores then using > the new format. Another option would be to introduce the 1.8.1 format as an > alternative implementation i.e. a second struct inside union ps_crypto_t > and provide the 1.8.1 code as well as the current code (this would mean > picking a storage format at build time and using it forever). > > > > Regarding the client_id. You’re correct that the client_id is used as a > kind of access control (the client_id and UID together identify the stored > object). Yes, there was a major change to the way that client_ids are used, > with the mapping being added. Do you have TFM_NS_MANAGE_NSID set to ON? I > believe that if it is set to OFF then -1 is used inside TF-M to represent > all non-secure clients, which sounds like it may be what you need. > > > > Chris >

11 months

3
2
0 0

Coding style update

by Antonio De Angelis

Hi all, just to point out that the coding guidelines are being updated to reflect feedback received over the years about the point of variable declaration. The majority of the code already follows this style, changing the guidelines to avoid further confusion. …/coding_guide.rst · Gerrit Code Review<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/33807/1/docs…> Please let us know if any feedback. Thanks, Antonio

11 months

1
0
0 0

mbedtls 2.25 and 3.6

by Michael Khoyilar

Hi Team I am investigating the move from MbedTLS 2.25 to 3.6, however, our client uses the 2.25 currently (looks like they prefer to stay with it) and I need to provide convincing proof to move to 3.6 considering the upgrade issues that might arise. Any suggestions here that is convincing proof to do the migration to 3.6? I would appreciate your comments. Thanks Michael

11 months

2
1
0 0

Backwards compatibility of Protected Storage implementation (TF-M 1.8.1 -> 2.1.1)

by Miika Karanki

Hi, I am working on an update from TF-M 1.8.1 to TF-M 2.1.1 on a board that uses encrypted Protected Storage. The board used is stm32 b_u585i_iot02a, NSPE side using Zephyr OS. I want to support field updates as well for devices already having Protected Storage objects created from NSPE. In my case, Protected Storage is created and used by TF-M 1.8.1, and I want it to remain functional after upgrading to TF-M 2.1.1. PS_CRYPTO_AEAD_ALG is set to (default) PSA_ALG_GCM. I have faced two issues with the uplift: 1. It seems commit ffd13c3 ( https://github.com/TrustedFirmware-M/trusted-firmware-m/commit/ffd13c31d5e6…) has changed the layout how Protected Storage objects are stored into flash. With TF-M 2.1.1 and old PS data, PS init fails (or gets recreated if PS_CREATE_FLASH_LAYOUT, which I don't want since then all the existing objects would get erased). If I revert the commit (and https://git.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m.git… as not to have conflicts), then the PS initialization can pass and objects are decrypted successfully. I have not been able to understand this thoroughly, but at least change in `union ps_crypto_t` struct member order is changing padding (sizeof 48 -> 40), and that in turn seems to shift at least additional data by 8 bytes via `#define PS_NON_AUTH_OBJ_TABLE_SIZE sizeof(union ps_crypto_t)`. Is this compatibility issue "a bug" in 2.1.1 or expected by design? 2. PS objects in 1.8.1 were storing client id to the object table entry to implement access control (?). With 1.8.1, the client id that got stored was -1. With 2.1.1, likely due to the Mailbox NS Agent Design Update ( https://tf-m-user-guide.trustedfirmware.org/design_docs/dual-cpu/mailbox_ns…), non-secure requests to get an object seems to pass client ID -0x3c000000 to the Protected Storage implementation. That is, client id -1 seems to be transformed to `client_id_limit`. Due to this, `psa_ps_get_info()` fails to get an object that has been previously made with 1.8.1 FW. I am able to get reading of old stored objects working by changing `client_id_limit` from value -0x3c000000 to -1 which changes to use 1-to-1 mapping when using client_id=-1. But I am unsure if this change causes some unwanted side effects. Is this the correct way to gain backwards compatibility? And if it is, would it make sense to pick https://git.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m.git… into 2.1.x branch and add a configuration flag for the 1-to-1 mapping support without code change for backwards compatibility? Thanks, Miika

11 months, 1 week

3
2
0 0

tf-m-tests for Floating point unit

by Zhang, Hao

Hi TF-M Maintainers, I am trying to build tf-m regression tests with fpu tests on for an521 and musca_s1 (I manually enable allow fpu tests for musca_s1) from Zephyr's west build. I did that by 1. set(CONFIG_TFM_ENABLE_FP ON) in config.cmake 2. set(TEST_NS_FPU ON) in tfm_test_config.cmake But both build fails with ~/zephyr-sdk-0.16.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: secure_fw/partitions/partitions/service_5/libtfm_app_rot_partition_fpu_service.a(tfm_fpu_service_test.o): in function `fpu_service_check_fp_register': ~/work/zephyrproject_adi/modules/tee/tf-m/tf-m-tests/tests_reg/test/secure_fw/suites/fpu/service/tfm_fpu_service_test.c:48: undefined reference to `dump_fp_callee' ~/zephyr-sdk-0.16.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: ~/work/zephyrproject_adi/modules/tee/tf-m/tf-m-tests/tests_reg/test/secure_fw/suites/fpu/service/tfm_fpu_service_test.c:39: undefined reference to `dump_fp_callee' ~/zephyr-sdk-0.16.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: ~/work/zephyrproject_adi/modules/tee/tf-m/tf-m-tests/tests_reg/test/secure_fw/suites/fpu/service/tfm_fpu_service_test.c:42: undefined reference to `populate_callee_fp_regs' ~/zephyr-sdk-0.16.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: secure_fw/partitions/partitions/service_5/libtfm_app_rot_partition_fpu_service.a(tfm_fpu_service_test.o): in function `fpu_service_check_fp_register_after_ns_inturrept': ~/work/zephyrproject_adi/modules/tee/tf-m/tf-m-tests/tests_reg/test/secure_fw/suites/fpu/service/tfm_fpu_service_test.c:92: undefined reference to `fp_func_jump_template'. I modified line 16-19 of https://github.com/zephyrproject-rtos/tf-m-tests/blob/a1a178d8c1f3c75763511… to below target_sources(tfm_app_rot_partition_fpu_service PRIVATE tfm_fpu_service_test.c ../fpu_tests_common.c ) Then, it starts building successfully. Is there anything particular I am missing. Thank you! My tf-m tests version is 502ea90105ee18f20c78f710e2ba2ded0fc0756e (Merge pull request #11 from tomi-font/update_2.1.1)for https://github.com/zephyrproject-rtos/tf-m-tests. Best regards, Hao

11 months, 2 weeks

2
1
0 0

FPU use with TF-M

by Jain, Saurabh

Hi We’re developing a platform using TF-M and would like to get some clarity on using FPU on Secure and Non-Secure side. The idea is to let NS application decide if it wants to use FPU. Currently, we are enabling CONFIG_TFM_ENABLE_FP which means we’re setting CPACR.CP10, CPACR.CP11 and enabling NSACR.CP10, NSACR.CP11. With this configuration: 1. Is it okay if SE perform some FP operation which would set CONTROL.FPCA and return to NSE (CPACR_NS.CP10 and CPACR_NS.CP11 are not set) while CONTROL.FPCA is still set? 2. With the above configuration, if NSE wants to use FPU, it simply needs to enable CPACR_NS.CP10 and CPACR_NS.CP11. Is this correct? 3. If SE doesn’t require FPU, we could simply enable CONFIG_TFM_ENABLE_CP10CP11 (CONFIG_TFM_ENABLE_FP is OFF) and NS app would still be able access FPU after enabling CPACR_NS bits? 4. There is a hard requirement for the -mfloat-abi to be consistent for S, NS and all the static libraries used? Thank you in advance! Best Saurabh Jain

11 months, 2 weeks

2
1
0 0

FreeRTOS OTA PAL PSA status

by Bohdan.Hunko＠infineon.com

Hi all, I have found this interesting repo repo https://github.com/Linaro/freertos-ota-pal-psa I was wondering whether this is official PSA FW UPDATE API support for FreeRTOS, and is it still supported/maintained? 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>

11 months, 2 weeks

3
3
0 0

TF-M Small Profile with Initial Attestation - Related Query

by Srinivasan, Jayashree

Hello, I have been trying to test the initial attestation feature using the regression build for a platform that we are developing. TF-M small profile has been configured, which enables symmetric key-based attestation. On running the regression tests, the TFM_NS_ATTEST_TEST_2001 testcase fails. On further debugging, I found that the static buffer that mbedtls uses for its allocation is not sufficient ( CRYPTO_ENGINE_BUF_SIZE = 0x400 in small profile). When I increase the buffer size to 0x500, the testcase passes. Therefore, I wanted to know if this change needs to be adopted upstream or if I might be overlooking something on my end. Any leads in this regard would be helpful. Thanks, Jayashree

11 months, 3 weeks

2
2
0 0

ARM PPC Driver invocation

by Michael Khoyilar

Hi Team, Thanks for you helps. This this time I want to know how does PPC functions will be called from application to set a possible feature? The question is how PPC functions are exposed to outside world? I know we have a common ARM API in under platform/ext/driver/Driver_PPC.h I am mapping my PPCs to this API, however wondering how they might be called that refer to my specific PPCs ? I am not using the ARM naming for my PPCs drivers, for example not using the name Driver_AHB_PPCEXP0 (using the name Driver_APB_PPCBASE0). Thank you again. Michael

11 months, 3 weeks

2
1
0 0

Use of ROM address - flash_layout.h

by Michael Khoyilar

Hi all, I am getting to know the TF-M, yet I do not understand the following comment and code where ROM (Read Only) is mentioned and its address used to store Code Data (flash_layout.h)!! Can someone help me understand this better? Thanks BR Michael /* Use flash memory to store Code data */ #define S_ROM_ALIAS_BASE (0x10000000) #define NS_ROM_ALIAS_BASE (0x00000000)

12 months

3
3
0 0

TF-M v2.1.1 release

by Anton Komlev

Hello, We are starting releasing TF-Mv2.1.1 targeted for PSA certification and LTS support. TF-Mv2.1.1-RC1<https://review.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m/…> tag is placed on all repositories. Let me remind that the code is not frozen, and development can be continued on the main branch as described in TF-M Release Process<https://tf-m-user-guide.trustedfirmware.org/releases/release_process.html#r…>. Thanks, Anton

1 year

1
2
0 0

Query on Storing OTP-Provisioned Values in ITS during Service Initialization

by Jain, Saurabh

Hello We have some platform-specific values provisioned in OTP that we need to retrieve and store in ITS (with encryption enabled) during initialization. We could do something similar to template file crypto_nv_seed.c, where the tfm_plat_crypto_provision_entropy_seed function is invoked from tfm_crypto_engine_init within secure_fw/partitions/crypto/crypto_init.c. However, we have a few questions: 1. Adding something similar in tfm_its_init won’t work as psa_its_* would again call into ITS via SPM which could be a problem? Also there is no hook in its_init to add platform specific routines as well? Is this correct? 2. Since crypto_init.c is part of secure_fw/, we’re uncertain about adding new platform-specific routines directly in tfm_crypto_engine_init. If this is not advisable, could you suggest an ideal place for implementing this functionality? 3. Regarding the SFN model, our understanding is that SPM initializes all partitions (and their respective services) before transitioning control to the NS side. Could you confirm if this is correct? We want to make sure that the provisioned values are stored in ITS before receiving request from NS client. Thank you for your guidance! Saurabh

1 year

2
2
0 0

Open CI is currently down

by Antonio De Angelis

Open CI infrastructure has been down since this morning and currently still not working. Will post updates to the mailing list once they are available. Thanks, Antonio

1 year

1
1
0 0

ITS Encryption

by Jain, Saurabh

Hi All I am quite new to TF-M and would like some insight into the query below. I appreciate any help you can provide. We're adding encryption support for ITS and for nonce requirement, we're thinking of accessing TRNG which is part of the crypto partition. Now, we're aware of the possible cyclic dependency issue with the IPC model but since we're using the SFN model, will it be okay to access crypto service(TRNG) from ITS? In other words, would cyclic dependency be a concern in SFN model provided there are no limitations on hardware? Thanks in advance. Saurabh

1 year

3
3
0 0

Notice of platform deprecation: TC2

by Jackson Cooper-Driver

Hi all, A heads up that the Total Compute 2022 (TC2) platform is due to be deprecated. If there is no objection, I will go ahead and remove TC2 from the TF-M codebase a month from now (25/11/24). Thank you. Thanks, Jackson

1 year

1
0
0 0

increased interrupt latency when calling the PSA PS API

by Fontanilles, Tomi

Hi all, I'm currently looking into an issue reported internally where the maximum latency for a zero-latency, priority 0 interrupt dramatically increases during a call to the PSA Protected Storage (PS) API. The maximum interrupt latency goes up ~10-fold, or even some more at times (it varies), and this is not acceptable to code running on the NS side for normal operation. It's as simple as calling psa_ps_set(1, 4, buf, PSA_STORAGE_FLAG_NONE) once. During that call (which I am told was also seen to be unreasonably long: 600ms for 4 bytes, 1s for 1000 bytes), the maximum interrupt latency goes up. It (the maximum) seems to not vary too much even if increasing the size of stored assets (tested up to 4000 bytes), though it can get up to 20 times higher than the normal interrupt latency. Also, other functions were tested (psa_generate_random(), psa_hash_compute()). Those don't provoke an increased interrupt latency. Maybe it's only about the PS, or maybe some other calls can provoke that as well. Does someone have an explanation for that? And even more importantly, can that interrupt latency be reduced, ideally down to normal levels? Thanks in advance. Tomi

1 year

2
5
0 0

Set PSA_2_0_0 as default attest profile and removal of PSA_IOT_PROFILE_1

by Tamas Ban

Hi, We are going to set the PSA_2_0_0 profile as the default for the initial attestation service. This will impact which claims are included in the token and their key values. More details are here: https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-24.html Changes on review: https://review.trustedfirmware.org/q/topic:%22attest_profile_update%22 As a follow-up action, the PSA_IOT_PROFILE_1 is being deprecated. We are planning to remove it from the code base as well. To figure out the timing of this we would like to collect some data: * If you are using the PSA_IOT_PROFILE_1 please let us know what would be a feasible time for you to switch over the PSA_2_0_0 profile. Thanks! Best regards, Tamas Ban

1 year

3
2
0 0

Discussion on TF-M Copyright notices update

by Anton Komlev

Hello, I would like to open discussion on TF-M copyright notice unification following other projects in TrustedFirware.org<https://www.trustedfirmware.org/> which already adopted Linux Foundation copyrights<https://www.linuxfoundation.org/blog/blog/copyright-notices-in-open-source-…>. With the change TF-M copyright notice will be unified to: Copyright (c) XXXX[-YYYY], The TrustedFirmware-M Contributors. All rights reserved. The change to the contribution process is proposed here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/31664 Please share your thoughts on the subject. I plan to bring this topic to the tech forum agenda on Thursday. Please join the discussion. Thanks, Anton

1 year

1
1
0 0

PSA Certification for TF-M

by Zhang, Hao

Hi TF-M committee, I have a question regarding PSA certification. Am I understanding correctly that if a platform wants to be ported to TF-M and the product wants to pass PSA certified, the TF-M version needs to come from a certain LTS tag release (e.g. TF-M v2.1.0<https://github.com/TrustedFirmware-M/trusted-firmware-m/tree/TF-Mv2.1.0> with commit 0c4c99b<https://github.com/TrustedFirmware-M/trusted-firmware-m/commit/0c4c99ba33b3…> that was pushed 5 months ago). However, Zephyr v3.7.0 is using TF-M version<https://github.com/zephyrproject-rtos/zephyr/blob/v3.7.0/west.yml#L330C17-L…> that is updated after TF-M v2.1.0. Does that means efforts need to be done to manually modify west.yml in Zephyr to roll back to the tag release of v2.1.0 for PSA certification? Thank you very much, Best, [https://opengraph.githubassets.com/f92ee5eaaedaf25d7ae17b5e8fc073a1573b0f31…]<https://github.com/zephyrproject-rtos/zephyr/blob/v3.7.0/west.yml#L330C17-L…> zephyr/west.yml at v3.7.0 · zephyrproject-rtos/zephyr<https://github.com/zephyrproject-rtos/zephyr/blob/v3.7.0/west.yml#L330C17-L…> Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures. - zephyrproject-rtos/zephyr github.com [https://opengraph.githubassets.com/685e753ecccd8431b5e0c4ed32fb794a49e2bcb3…]<https://github.com/TrustedFirmware-M/trusted-firmware-m/tree/TF-Mv2.1.0> GitHub - TrustedFirmware-M/trusted-firmware-m at TF-Mv2.1.0<https://github.com/TrustedFirmware-M/trusted-firmware-m/tree/TF-Mv2.1.0> Read-only mirror for Trusted Firmware-M. Contribute to TrustedFirmware-M/trusted-firmware-m development by creating an account on GitHub. github.com Best regards, Hao

1 year

3
6
0 0

Security vulnerability notice - Unchecked user-supplied pointer via mailbox messages may cause write of arbitrary address

by Anton Komlev

Hello, This email is a notification of a new security vulnerability reported to TF-M by Infineon Technologies AG, in collaboration with: Tobias Scharnowski, Simon Wörner and Johannes Willbold from fuzzware.io. Unchecked user-supplied pointer via mailbox messages may cause write of arbitrary address. Please find the security advisory attached. The fix has been merged on the latest main branch tfm_spe_mailbox: Do not write-back on input vectors checks failure<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/31512> We're preparing a hotfix release v2.1.1 to include fixes for this vulnerability and bugs reported till that date via TF-M issue tracker: https://github.com/TrustedFirmware-M/trusted-firmware-m/issues?q=is%3Aissue Thanks and best regards Author

1 year, 1 month

1
0
0 0

QEMU usage

by Matthew Dalzell

Hi everyone, It has come to our attention that QEMU is no longer able to run the regression tests in a timely manner, and before we go ahead and outright disable them, we would like to know if anyone is using QEMU for their platform testing. If so, please reply to this message and we can have further discussion on the point. Thanks, Matt

1 year, 1 month

2
1
0 0

Re: Looking for suggestions about make Mbed TLS APIs non-secure callable APIs on armv8m

by Shebu Varghese Kuriakose

+ TF-M mailing list From: David Horstmann via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: Tuesday, September 24, 2024 5:14 PM To: mbed-tls(a)lists.trustedfirmware.org; Lee, William <William.Lee(a)garmin.com> Subject: [mbed-tls] Re: Looking for suggestions about make Mbed TLS APIs non-secure callable APIs on armv8m Hi William, Since Mbed TLS is a cross-platform library, we don't deal directly with TrustZone-M. However, if I have understood correctly, I think your usecase is solved by the Trusted Firmware M (TF-M) project[1], which is an implementation of secure firmware that provides cryptography services via non-secure-callable APIs. TF-M uses Mbed TLS internally and implements the PSA Certified Cryptography API[2]. The Crypto Service Integration Guide[3] in the documentation should be a good starting point for what you are trying to do. I hope that helps, David Horstmann Mbed TLS developer [1] https://www.trustedfirmware.org/projects/tf-m [2] https://www.psacertified.org/getting-certified/crypto-api-compliance/ [3] https://trustedfirmware-m.readthedocs.io/en/latest/integration_guide/servic… [https://www.trustedfirmware.org/images/social-media-image.png]<https://www.trustedfirmware.org/projects/tf-m> TrustedFirmware-M (TF-M)<https://www.trustedfirmware.org/projects/tf-m> TrustedFirmware-M (TF-M) implements the Secure Processing Environment (SPE) for Armv8-M, Armv8.1-M architectures or dual-core platforms. www.trustedfirmware.org<http://www.trustedfirmware.org> ________________________________ From: Lee, William via mbed-tls <mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>> Sent: 24 September 2024 15:08 To: mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> <mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>> Subject: [mbed-tls] Looking for suggestions about make Mbed TLS APIs non-secure callable APIs on armv8m Hi Mbed TLS, I am looking for some suggestions about make some (or all) Mbed TLS APIs non-secure callable APIs on armv8m. The background is that I am going to have a secure firmware that provides encryption services by building part (or whole) of Mbed TLS into that firmware and make those original mbedtls_x APIs non-secure callable, so the existing non-secure firmware could link those non-secure callable APIs and use them. Some of my thoughts: (1) The easiest way to do it I can think of is just add the attribute "cmse_nonsecure_call" to those APIs' declaration (or use a macro to wrap the attribute for conditional build to not impact others don't want it), but I do not think this modification could be accepted by upstream 🙂. (2) So my another thought is duplicate all header files and put them under another folder, assuming it is my-include folder, then I can do whatever I want to my-include folder, but there is also a problem I can think of: a merge/compare burden between include and my-include folder after I have updated Mbed TLS. I really appreciate other suggestions! Thanks, William

1 year, 1 month

2
1
0 0

Re: [Technical Loop] PSA Crypto API with PUFcc on the TF-M platform

by Mark Chen

Hi all, I am working on integrating our IP(PUFcc) into TF-Mv2.1.0, with the PUFcc located at address 0x51700000. The PUFcc can be access on bl2 stage, however, it cannot be access on booting tf-m stage. The exception log as below: [cid:image002.png@01DAEFC7.96FE4EB0]FATAL ERROR: HardFault Here is some context for the exception: EXC_RETURN (LR): 0xFFFFFFF1 Exception came from secure FW in handler mode. xPSR: 0x00000003 MSP: 0x31000B18 PSP: 0x31000BF8 MSP_NS: 0xFFFFFFFC PSP_NS: 0xFFFFFFFC Exception frame at: 0x31000B18 R0: 0x31000B60 R1: 0x00000000 R2: 0x0000001B R3: 0x00000002 R12: 0x00000000 LR: 0x38009EF7 PC: 0x3800AB02 xPSR: 0x6100000B Callee saved register state: R4: 0xFFFFFFF9 R5: 0x31000B60 R6: 0x00000002 R7: 0x00000002 R8: 0x38030F24 R9: 0x0000001B R10: 0x00000011 R11: 0x38030F11 CFSR: 0x00008200 BFSR: 0x00000082 BFAR: 0x00000004 MMFSR: 0x00000000 MMFAR: Not Valid UFSR: 0x00000000 HFSR: 0x40000000 SFSR: 0x00000000 SFAR: Not Valid The diff patch as below: [cid:image003.png@01DAEFC7.96FE4EB0]--- a/secure_fw/spm/core/main.c +++ b/secure_fw/spm/core/main.c @@ -56,6 +56,9 @@ static fih_int tfm_core_init(void) */ SPMLOG_INFMSG("\033[1;34mBooting TF-M "VERSION_FULLSTR"\033[0m\r\n"); + uint32_t* p_s = (uint32_t *)0x51700000; + printf("p_s = %08x\n", (uint32_t)*p_s); Could you provide any suggestions on this issue? Best regards, Mark Chen Research & Development Division II PUFsecurity Corporation Tel: 886-3-5601010 ext. 3110 Fax: 886-3-5601177 Email: mark(a)pufsecurity.com<mailto:mark@pufsecurity.com> [cid:image001.png@01DAEFC5.FD4AE270] From: Andy Chen <andychen(a)pufsecurity.com<mailto:andychen@pufsecurity.com>> Sent: Thursday, August 1, 2024 12:12 AM To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>> Cc: Randy Liu <randyliu(a)pufsecurity.com<mailto:randyliu@pufsecurity.com>>; Victor Huang <victor(a)pufsecurity.com<mailto:victor@pufsecurity.com>>; Neil Chen <neilchen(a)pufsecurity.com<mailto:neilchen@pufsecurity.com>>; Antonio De Angelis <Antonio.DeAngelis(a)arm.com<mailto:Antonio.DeAngelis@arm.com>>; Shebu Varghese Kuriakose <Shebu.VargheseKuriakose(a)arm.com<mailto:Shebu.VargheseKuriakose@arm.com>> Subject: Re: [Technical Loop] PSA Crypto API with PUFcc on the TF-M platform Hi Anton, Thank you and enjoy your time!!! Best, Andy ________________________________ 寄件者: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>> 寄件日期: Wednesday, July 31, 2024 11:34:48 PM 收件者: Andy Chen <andychen(a)pufsecurity.com<mailto:andychen@pufsecurity.com>> 副本: Randy Liu <randyliu(a)pufsecurity.com<mailto:randyliu@pufsecurity.com>>; Victor Huang <victor(a)pufsecurity.com<mailto:victor@pufsecurity.com>>; Neil Chen <neilchen(a)pufsecurity.com<mailto:neilchen@pufsecurity.com>>; Antonio De Angelis <Antonio.DeAngelis(a)arm.com<mailto:Antonio.DeAngelis@arm.com>>; Shebu Varghese Kuriakose <Shebu.VargheseKuriakose(a)arm.com<mailto:Shebu.VargheseKuriakose@arm.com>> 主旨: RE: [Technical Loop] PSA Crypto API with PUFcc on the TF-M platform HI Andy, Great to hear good news. I will be in annual leave from tomorrow, Aug 1st, but Antonio (coped) could help you and can redirect the possible questions to appropriate team members. With the occasion, I would appreciate if your team evaluates and follows TF-M documentation and gives us feedback on possible confusion or missing information. Best regards, Anton From: Andy Chen <andychen(a)pufsecurity.com<mailto:andychen@pufsecurity.com>> Sent: Wednesday, July 31, 2024 3:26 PM To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>> Cc: Randy Liu <randyliu(a)pufsecurity.com<mailto:randyliu@pufsecurity.com>>; Victor Huang <victor(a)pufsecurity.com<mailto:victor@pufsecurity.com>>; Neil Chen <neilchen(a)pufsecurity.com<mailto:neilchen@pufsecurity.com>> Subject: [Technical Loop] PSA Crypto API with PUFcc on the TF-M platform #Set a new mail loop Hi Anton, We set a kick-off meeting of "PSA Crypto API with PUFcc on the TF-M platform" this week. • TF-M v2.1.0 • PSA Crypto API - v1.2.1 • PSA Certified APIs Architecture Test Suite - v1.6 • MPS3 with AN552 Randy, Victor, and Neil are members of this project. We would have many issues when developing that need your help to solve it. Please feel free to add your teams. Let's make the project successful. Thank you very much. Have a Nice Day, Andy [cid:image001.png@01DAEFC5.FD4AE270] 熵碼科技股份有限公司 Tel: 886-3-5601010 #2119 Email: andychen(a)pufsecurity.com<mailto:andychen@pufsecurity.com> Website: https://www.pufsecurity.com/ -------- Disclaimer: This e-mail is from PUFsecurity Corporation. This e-mail may contain privileged and confidential information. It is intended for the named recipient(s) only. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient may violate applicable laws. If you are not an intended recipient, please notify us immediately (by reply e-mail) and delete this e-mail from your system. Our postal address is 8F-1, No. 5, Tai-Yuan 1st St., Jhubei City, Hsinchu County 302082, Taiwan.-------- -------- Disclaimer: This e-mail is from PUFsecurity Corporation. This e-mail may contain privileged and confidential information. It is intended for the named recipient(s) only. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient may violate applicable laws. If you are not an intended recipient, please notify us immediately (by reply e-mail) and delete this e-mail from your system. Our postal address is 8F-1, No. 5, Tai-Yuan 1st St., Jhubei City, Hsinchu County 302082, Taiwan.-------- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -------- Disclaimer: This e-mail is from PUFsecurity Corporation. This e-mail may contain privileged and confidential information. It is intended for the named recipient(s) only. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient may violate applicable laws. If you are not an intended recipient, please notify us immediately (by reply e-mail) and delete this e-mail from your system. Our postal address is 8F-1, No. 5, Tai-Yuan 1st St., Jhubei City, Hsinchu County 302082, Taiwan.-------- -------- Disclaimer: This e-mail is from PUFsecurity Corporation. This e-mail may contain privileged and confidential information. It is intended for the named recipient(s) only. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient may violate applicable laws. If you are not an intended recipient, please notify us immediately (by reply e-mail) and delete this e-mail from your system. Our postal address is 8F-1, No. 5, Tai-Yuan 1st St., Jhubei City, Hsinchu County 302082, Taiwan.-------- -------- Disclaimer: This e-mail is from PUFsecurity Corporation. This e-mail may contain privileged and confidential information. It is intended for the named recipient(s) only. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient may violate applicable laws. If you are not an intended recipient, please notify us immediately (by reply e-mail) and delete this e-mail from your system. Our postal address is 8F-1, No. 5, Tai-Yuan 1st St., Jhubei City, Hsinchu County 302082, Taiwan.--------

1 year, 2 months

3
2
0 0

ARMCLANG generates ELF with armv3m architecture

by Roman.Mazurak＠infineon.com

Hello, We noticed that build of TF-M for CM33 platform generates ELF file for which architecture is armv3m. Step to reproduce: 1. Build TF-M secure image for CM33 platform with armclang (used 6.19). 2. Use arm-none-eabi-objdump provided with arm-gnu-toolchain-11.3.rel1-mingw-w64-i686-arm-none-eabi to print headers: * arm-none-eabi-objdump -x tfm_s.axf You will see following output: tfm_s.axf architecture: armv3m, flags 0x00000012: EXEC_P, HAS_SYMS While fromelf (from armclang) prints following: ======================================================================== ** ELF Header Information File Name: tfm_s.axf Machine class: ELFCLASS32 (32-bit) Data encoding: ELFDATA2LSB (Little endian) Header version: EV_CURRENT (Current version) Operating System ABI: none ABI Version: 0 File Type: ET_EXEC (Executable) (2) Machine: EM_ARM (ARM) Image Entry point: 0x16004319 Flags: EF_ARM_HASENTRY + EF_ARM_ABI_FLOAT_HARD (0x05000402) ARM ELF revision: 5 (ABI version 2) Is't expected? Because we have problems with debugging images generated by armclang in eclipse with gdb. Regards, Roman.

1 year, 2 months

2
1
0 0

Improved linker files supporting TF-M isolation L1-3

by Jamie Fox

Hi all, I have pushed for review a change to improve the TF-M linker scripts / scatter files: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/30316 There are two ideas behind the change: * Merge the isolation level 3 features from the tfm_isolation_l3 linker files into tfm_common_s, so that one linker file can support all TF-M isolation levels. * Group the memory by its desired memory protection attribute as far as possible, so that as much of the memory map as possible can be covered by MPU regions to restrict the attributes to no more than needed. The main advantage of this is to reduce how much of the memory is executable. There are more details in the commit message. Since it could be a disruptive change, the new linker files are added in addition to the existing tfm_common_s.sct/ld/icf and tfm_isolation_l3.sct/ld/icf ones and only platforms that are already using the common tfm_hal_isolation_v8m.c are switched over for now. But the idea is that platforms can gradually migrate and eventually the existing linker files can be removed. Kind regards, Jamie

1 year, 2 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M