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
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
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>
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>
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
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>
Hi,
Sorry 2nd link was broken. Here is the working version:
https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-09.html#tab…
Tamas Ban
From: Andersson, Joakim <Joakim.Andersson(a)nordicsemi.no>
Sent: 2022. május 9., hétfő 12:14
To: Tamas Ban <Tamas.Ban(a)arm.com>
Subject: RE: Attestation token new spec
Is te second link broken? I get a 404 error code.
-Joakim
From: Tamas Ban via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Sent: mandag 9. mai 2022 11:31
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] Attestation token new spec
Hi,
the initial attestation token implementation is aligned with this specification:
https://datatracker.ietf.org/doc/html/draft-tschofenig-rats-psa-token-05<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrack…>
This spec is still evolving and there is a newer version which changes the key values of the claims in the token:
https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-09.html#tab…<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.…>
This can cause combability issues between token issuer (device) and token verifier (some remote verification service).
This is an ABI change between token issuer and consumer.
The breaking effect would be manifest in unaccepted IAT tokens by the verifier.
On-device side I see these options to make the transition:
- A build-time option could be introduced which determines which range of key numbers to use. The default value would be the new range. To not let new users pick up the old values accidentally. Existing users can notice the incompatibility issue during the integration test and adjust their build command accordingly. However, the old range would be announced as deprecated in the next TF-M release, then will be removed in the next release after.
- Immediate switch over to the new range, without supporting the old range anymore. On the verification service side, an SW update can handle the transition and might be accepting both ranges for a while. I assume the verification service can be updated more easily than remote devices therefore better to handle the compatibility issue there.
- Keeping the support for both ranges for the long term and letting users choose by build time.
Please share your thoughts on:
- Are you aware that the attestation service is used in deployed devices where this transition can cause incompatibility?
- From the above list which option would you vote to support the transition?
Best regards,
Tamas Ban
Hi all,
I found that using FIH medium/high profile with gcc generates code that uses stack extensively. It happens because fih_int structure is marked as volatile.
Is there any reason why structure itself is marked as volatile? Why it's not enough to make val and msk volatile members of fih_int structure?
Best regards,
Roman.
Hi all,
In config/check_config.cmake there is a following code:
tfm_invalid_config((MCUBOOT_UPGRADE_STRATEGY STREQUAL " DIRECT_XIP " OR MCUBOOT_UPGRADE_STRATEGY STREQUAL "RAM_LOAD") AND TFM_PARTITION_FIRMWARE_UPDATE)
So looks like FWU is not supported when DIRECT_XIP or RAM_LOAD upgrade strategies are used.
But then in FWU code I see a lot of checks for DIRECT_XIP or RAM_LOAD, for example in fwu_bootloader_get_image_info:
#if !defined(MCUBOOT_DIRECT_XIP) && !defined(MCUBOOT_RAM_LOAD) && \
!defined(MCUBOOT_OVERWRITE_ONLY)
What is the point of these checks if it is impossible to compile FWU code with DIRECT_XIP Because of check in config/check_config.cmake?
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>
Hi all,
The current minimum CMake version specified in TF-M is 3.15. It is quite out-of-date.
I’d like to propose to increase minimum CMake version to 3.21.
CMake 3.21 can bring in some benefits, compared to CMake 3.15
* NEW behavior of several CMake policies, such as CMP0123 for Armclang.
* After build split, TF-M secure build installs several build scripts. When NS build includes those build scripts, `CMAKE_CURRENT_FUNCTION_LIST_FILE/DIR` can make it easier to handle source code paths.
CMake 3.21 was released 2 years ago. It should be stable enough now.
May I know if you have any feedback or different opinions?
Thank you.
Best regards,
Hu Ziji
