December 2023 - TF-M - lists.trustedfirmware.org

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, July 21, 7:00-8:00 UTC (East time zone). Please reply on this email with your proposals for agenda topics. Link to the forum: https://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT… Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

2 days, 16 hours

7
59
0 0

Technical Forum call - July 7

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, July 7, 15:00-16:00 UTC (West time zone). Please reply on this email with your proposals for agenda topics. Link to the forum: https://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz… Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

3 weeks, 4 days

10
62
0 0

Security Vulnerability Notice - Partial tag comparison when using Chacha20-Poly1305 on the PSA driver API interface in CryptoCell enabled platforms

by Antonio De Angelis

Hi Everyone, There is a new security vulnerability discovered on the PSA Driver API for CryptoCell enabled platforms, described as "Partial tag comparison when using Chacha20-Poly1305 on the PSA driver API interface in CryptoCell enabled platforms". Please find the security advisory specific to TF-M and patches that have been developed as per the TrustedFirmware.org security process [1] below : * TF-M Security advisory: TFMV-6: Add cc3xx_partial_tag_compare_on_chacha20_poly1305 advisory (I44bc426f) · Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/22995> * Patch to fix the issue has been already merged on master branch as commit https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/commit/?id=2e82… * TF-Mv1.8.1 will be released in the next days containing the same hotfix Please let us know if you have any comments. Best regards, /Antonio [1] https://developer.trustedfirmware.org/w/collaboration/security_center/report...<https://developer.trustedfirmware.org/w/collaboration/security_center/repor…>

3 months, 2 weeks

2
1
0 0

Re: Are MCUs without internal flash not supported by TF-M?

by Antonio De Angelis

Hi Torsten, you can have a look at the design document for ITS which describes encryption in ITS for a generic introduction: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/tfm/design_docs… A platform supports ITS_ENCRYPTION=ON if it provides an implementation of the HAL functions as follows: tfm_hal_its_aead_* For the exact list of Nordic platforms that support this option I suggest to have a look directly in the Nordic Connect SDK. Probably any platform based on the 5340 would be able to support this option, but there might be other platforms as well which you would be able to use through the SDK itself. Hope this helps. Thanks, Antonio ________________________________ From: Labs, Torsten via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Saturday, December 30, 2023 14:51 To: Antonio De Angelis <Antonio.DeAngelis(a)arm.com>; Lee, William <William.Lee(a)garmin.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Re: Are MCUs without internal flash not supported by TF-M? Hi antonio, Thanks for those interesting news. Do you know on which Nordic platform supports encrypted ITS with TFM? Regards Torsten ________________________________ Von: Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org> Gesendet: Saturday, December 30, 2023 9:31:10 AM An: Lee, William <William.Lee(a)garmin.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Betreff: [TF-M] Re: Are MCUs without internal flash not supported by TF-M? Hi William, The requirement on the storage is for it to be isolated, either physically or cryptographically, as you can read from the PSA security model [1]. TF-M initially supported only the isolated model in ITS (i.e. for internal flashes) but more recently it was added support for encrypted ITS, which I believe it can be used on one of the Nordic platforms already. Hope this helps. Thanks, Antonio [1] Platform Security Model - PSA Certified https://www.psacertified.org/app/uploads/2021/12/JSADEN014_PSA_Certified_SM… Sent from Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: Lee, William via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Friday, December 29, 2023 5:53:50 AM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Are MCUs without internal flash not supported by TF-M? Hello everyone, Happy New Year! Are MCUs without internal flash not supported by TF-M? From TF-M’s documents, I saw ITS(Internal Trusted Storage) is a PSA-ROT secure service and requires store data in internal flash. Does that mean TF-M not support hardware platforms that do not have internal flash? For example, RT500 does not have internal flash: https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontr… Thank you! Best regards William Lee

6 months, 4 weeks

1
0
0 0

Are MCUs without internal flash not supported by TF-M?

by Lee, William

Hello everyone, Happy New Year! Are MCUs without internal flash not supported by TF-M? From TF-M’s documents, I saw ITS(Internal Trusted Storage) is a PSA-ROT secure service and requires store data in internal flash. Does that mean TF-M not support hardware platforms that do not have internal flash? For example, RT500 does not have internal flash: https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontr… Thank you! Best regards William Lee

6 months, 4 weeks

3
2
0 0

Minor updates to the tf.org project maintenance

by Sandrine Bailleux

Hello TF-A and TF-M communities, I've done 2 minor updates to the generic tf.org project maintenance process, which TF-A and TF-M both use. Please see the pull request here: https://github.com/TrustedFirmware/tf_docs/pull/1 Please provide your feedback on the pull request, if any. Happy end-of-year celebrations to all! Best regards, Sandrine

7 months, 1 week

1
0
0 0

Arm v8 FPU questions

by Bohdan.Hunko＠infineon.com

Hi all, I have been working with FPU lately and I have a few questions regarding this topic: Looks like there are 4 use cases of FPU usage: FPU is used in Use case number SPE NSPE 1 - - 2 - + 3 + - 4 + + From https://tf-m-user-guide.trustedfirmware.org/integration_guide/tfm_fpu_suppo… my understanding is following: 1. If SPE and NSPE both does not use SPU (use case 1) then they both must be compiler with fp=soft? 2. consistent FP ABI types between SPE and NSPE must be used. So even if only one of SPE or NSPE (use cases 2 and 3) does not use FPU they both still must be compiler with fp=hard Also if both SPE and NSPE use PFU then they both must be compiler with fp=hard 3. Even if FPU is not used by NSPE, NSPE still MUST enable CP10 an CP11? - Is this correct? Is it possible to enable FPU for SPE but don't enable CP10 and CP11 in NSPE? So basically if either SPE or NSPE or both of them need to use FPU then both of them need to enable CP10 and CP11 and be compiled with fp=hard Is my understanding correct? Inline comments are welcome. 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>

7 months, 1 week

2
1
0 0

How to disable all interrupts on ARM V8?

by Bohdan.Hunko＠infineon.com

Hi all, From what I have seen, looks like __disable_irq() only disables non-secure interrupts when called from NSPE on ARM v8 arch. Am I correct? If so then how can I disable all interrupts (including secure interrupts) from NSPE? - We need this for critical section and other critical code. 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>

7 months, 2 weeks

2
1
0 0

Problems with integrating TF-M with RIOT OS

by Boeckmann, Lena

Hi everyone! I am currently integrating TF-M with an IoT OS (RIOT OS) and I have a few problems. I managed to build and link a secure TF-M binary and a non-secure RIOT binary and I can run some application code (print "hello world", turn LEDs on and off, etc) on the nRF9160dk. I can also use the crypto API and call psa_crypto_init. Now I have tried a few things and each of them leads to different problems, some of which I will describe in this mail hoping that someone can help me with this. I have done some debugging and have some ideas on what could be wrong, but I don't really understand how to fix the issues and don't really know how to proceed with either of them. Formatted Prints Somehow formatted prints are ignored. Calls to printf without formatting default to the stdio puts implementation and are printed without issues. Calls to printf with formatting use the implementation in tfm_sp_log_raw.c and are just ignored. They crashed at first, but I could fix that (RIOT has different implementations of the SVC ISR and I used the wrong one). Now they don't crash anymore, but are also not printed (no error output, application keeps running). Since this function is part of the secure firmware, my guess is that there's a problem with it being called from the NS world. But that should result in a SecureFault, shouldn't it? Does anyone have an idea what the issue could be? Secure memset called from NS image When calling psa_generate_key, the first step is a struct initialization: struct tfm_crypto_pack_iovec iov = { .function_id = TFM_CRYPTO_GENERATE_KEY_SID, }; This runs into a SecureFault. It turns out that during struct initialization, memset is called to zeroize the structure. This uses the memset implemented in secure_fw/shared/crt_memset.c and accesses secure RAM (between addresses 0x20015000 and 0x20016000). I found a workaround by moving the start address of NS RAM from 0x20016000 to 0x20020000. Memset now still accesses RAM before NS RAM, but does not run into a SecureFault anymore. This works for now, but I would like to find an actual fix for this. This only occurs when building with RIOT. When building the TF-M NS image and running crypto tests, memset accesses NS RAM, though I don't know if the same implementation is used. Unfortunately I don't get any debug symbols there. Could it be that a different memset implementation should be linked? Can I change it somehow? Can someone tell me which one is linked in the TF-M NS image? Crypto partition is NULL When using the workaround described above, calling psa_generate_key runs into tfm_core_panic. The stack trace here is: psa_call (tfm_psa_call.c) tfm_psa_call_pack (backend_sfn.c) tfm_spm_client_psa_call (psa_call_api.c) tfm_spm_is_ns_caller (spm_ipc.c) The problem is in tfm_spm_is_ns_caller, where struct partition_t *partition = GET_CURRENT_COMPONENT(); gets a NULL pointer. So somehow there is no crypto partition available. Of course I have enabled the crypto partition in config_base.cmake, as well as protected storage and internal trusted storage. I checked with a debugger and found out that during start up, multiple partitions are initialized and added to the global component list (stored in backend_sfn.c). Can I somehow check what types of partitions are initialized? Did anyone have a similar issue before or has any idea why the partition could be missing? Did I miss any extra steps I need to take? I know these are pretty much unrelated issues, but they are persistent and I am at a loss at how to fix them. I will take any hints and ideas, including pointers to where I can find relevant information in the docs (those have not been very helpful in these cases, but maybe I've overlooked something). Best regards, Lena

7 months, 2 weeks

2
2
0 0

Weird behavior of Clang linker

by Bohdan.Hunko＠infineon.com

Hi all, Our platform uses 4KBs alignment in linker files (as this is the requirement of our protection HW). For this reasons I have introduced tfm_s_linker_alignments.h. Everything works fine with GCC but we have a problem with Clang. The problem is that Clang requires LR_CODE to have same alignment as other sections inside of it. Following are the steps to reproduce the issue: 1. Set TFM_LINKER_DEFAULT_ALIGNMENT to 0x1000 in tfm_s_linker_alignments.h 2. Build AN521 with following command line cmake -S . -B build_an521 -DTFM_PLATFORM=arm/mps2/an521 -DTFM_TOOLCHAIN_FILE=./toolchain_ARMCLANG.cmake Expected result: Everything works fine Actual result: Error: L6244E: Load region LR_CODE address (0x10080400) not aligned on a 4096 byte boundary. This error is weird because there is no explicit alignment assigned to LR_CODE region. Would appreciate a help on this as it is a blocking issue for us. 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>

7 months, 2 weeks

3
3
0 0

2024

2023

2022

2021

2020

2019

2018

TF-M December 2023