Hi all,
I am trying to build docs with following commands:
cmake -S docs -B ./build_docs
cmake --build build_docs/ -- tfm_docs_userguide_pdf
But I get following error
resolving references...
failed
Warning, treated as error:
RSVG converter command 'rsvg-convert' cannot be run. Check the rsvg_converter_bin setting
When I remove -W (warnings are errors) option from
COMMAND "${SPHINX_EXECUTABLE}" -W -b html -j 1 -c ${SPHINXCFG_CONFIG_PATH} ${SPHINXCFG_SOURCE_PATH} "${SPHINXCFG_OUTPUT_PATH}/html"
In docs/CMakeLists.txt then docs builds fine.
Is this -W option intentional? Should this issue be fixed or -W removed?
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,
Per https://datatracker.ietf.org/doc/html/draft-tschofenig-rats-psa-token-07 (which is latest spec I can find for profile 1 token):
The Certification Reference claim is used to link the class of chip and PSA RoT of the attesting device to an associated entry in the PSA Certification database. It MUST be represented as a thirteen-digit [EAN-13<https://www.gs1.org/standards/barcodes/ean-upc>].¶<https://datatracker.ietf.org/doc/html/draft-tschofenig-rats-psa-token-07#se…>
Linking to the PSA Certification entry can still be achieved if this claim is not present in the token by making an association at a Verifier between the reference value and other token claim values - for example, the Implementation ID.¶<https://datatracker.ietf.org/doc/html/draft-tschofenig-rats-psa-token-07#se…>
psa-certification-reference-type = text .regexp "[0-9]{13}"
psa-certification-reference = (
? psa-certification-reference-key =>
psa-certification-reference-type
)
But in the tf-m-tools repo:
iat-verifier\iatverifier\psa_iot_profile1_token_claims.py it checks for PSA 2.0 profile HW version which is EAN-13 + 5.
class HardwareVersionClaim(AttestationClaim):
"""Class representing a PSA Attestation Token Hardware version claim"""
def verify(self, token_item):
self._check_type('HARDWARE_VERSION', token_item.value, str)
value_len = len(token_item.value)
expected_len = 19 # 'EAN13-Version' 13 + 1 + 5. e.g.:0604565272829-10010
if len(token_item.value) != expected_len:
msg = 'Invalid HARDWARE_VERSION length; must be {} characters, found {} characters'
self.verifier.error(msg.format(expected_len, value_len))
for idx, character in enumerate(token_item.value):
if character not in string.digits:
if idx != 13 or character not in '-':
msg = 'Invalid character {} at position {}'
self.verifier.error(msg.format(character, idx+1))
It seems like this was changed 3yrs ago:
SHA-1: 8ac8d17d15353c7f7933ae8065646946ae47f993
* Fix HW Version claim expected length
www.psacertified.org issuing HW versions of format '[0-9]{13}-[0-9]{5}'.
It is called 'certification reference':
https://www.psacertified.org/certified-products/
Signed-off-by: Tamas Ban <tamas.ban(a)arm.com>
Change-Id: I0417e1ce76896f1128864676f29a4314b3fd1fb8
When I run "check_iat" script, I get these errors:
./scripts/check_iat -k public_key.pem -K -p -t PSA-IoT-Profile1-token cc27xx.cbor
ERROR:iat-verifiers:Invalid HARDWARE_VERSION length; must be 19 characters, found 13 characters
ERROR:iat-verifiers:Invalid character i at position 1
ERROR:iat-verifiers:Invalid character r at position 2
ERROR:iat-verifiers:Invalid character m at position 3
ERROR:iat-verifiers:Invalid character w at position 4
ERROR:iat-verifiers:Invalid character a at position 5
ERROR:iat-verifiers:Invalid character r at position 6
ERROR:iat-verifiers:Invalid character e at position 7
ERROR:iat-verifiers:Invalid character . at position 8
ERROR:iat-verifiers:Invalid character o at position 9
ERROR:iat-verifiers:Invalid character r at position 10
ERROR:iat-verifiers:Invalid character g at position 11
ERROR:iat-verifiers:Invalid character at position 12
ERROR:iat-verifiers:Invalid character at position 13
Is the verifier tool incorrect or should I be following "EAN13-Version' 13 + 1 + 5" even for profile 1 token?
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
12500 TI Blvd, MS F-4000
Dallas, TX 75243
214-479-4076
Hi team,
Can you help me with this statement that "Currently, the TF-M Secure Storage service implements PSA Protected Storage version 1.0-beta2. There is not yet an implementation of PSA Internal Trusted Storage in TF-M."
Our SoC does NOT have internal flash, but we have OTP where we keep the confidential data. Can you help how to handle this ITS situation. I wonder if PSA level-2 certification requires ITS? Thanks
BR
Michael
Hi Antonio,
I figured it out. I wasn’t including secure_fw/partitions/crypto/tfm_mbedcrypto_include.h properly so attestation was linking directly to the PSA Crypto function implementation instead of the client interface. I’m surprised it did not complain about a symbol collision without having the mbedcrypto__ prefix. The PSA crypto API implementation source files were “PRIVATE” so I’m not sure how attestation was able to link to them at all.
Regards,
Brian
From: Antonio De Angelis <Antonio.DeAngelis(a)arm.com>
Sent: Thursday, May 8, 2025 9:42 AM
To: Quach, Brian <brian(a)ti.com>; Mudit Sharma <Mudit.Sharma(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Subject: Re: [EXTERNAL] Re: [TF-M] Attestation calls to PSA Crypto
Hi Brian, we can't reproduce exactly that mixture easily but I don't think that should affect how the partition code gets linked to the interface code. Regardless of the type of partition (SFN/IPC) the linking of the interfaces should remain
ZjQcmQRYFpfptBannerStart
This message was sent from outside of Texas Instruments.
Do not click links or open attachments unless you recognize the source of this email and know the content is safe.
Report Suspicious <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/G3vK!tvdkk1ajei0aJagkHNPjPb…>
ZjQcmQRYFpfptBannerEnd
Hi Brian,
we can't reproduce exactly that mixture easily but I don't think that should affect how the partition code gets linked to the interface code. Regardless of the type of partition (SFN/IPC) the linking of the interfaces should remain the same, i.e. your setup should not be able to link at all directly with the crypto library that provides the PSA Crypto APIs.
Thanks, Antonio
________________________________
From: Quach, Brian
Sent: Thursday, May 08, 2025 15:29
To: Mudit Sharma; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: Antonio De Angelis
Subject: RE: [EXTERNAL] Re: [TF-M] Attestation calls to PSA Crypto
Hi Mudit,
Thanks for checking. Is the build you tested using the same mix of SFN and IPC as I was?
Regards,
Brian
From: Mudit Sharma <mudit.sharma(a)arm.com<mailto:mudit.sharma@arm.com>>
Sent: Thursday, May 8, 2025 5:21 AM
To: Quach, Brian <brian(a)ti.com<mailto:brian@ti.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: Antonio.DeAngelis(a)arm.com<mailto:Antonio.DeAngelis@arm.com>
Subject: [EXTERNAL] Re: [TF-M] Attestation calls to PSA Crypto
Hi Brian, We built secure world TF-M test for AN521 platform: ``` cmake -S spe -B build_spe -DTFM_PLATFORM=arm/mps2/an521 \ -DCONFIG_TFM_SOURCE_PATH="$TFM_SOURCE_DIR" \ -DCMAKE_BUILD_TYPE=Debug \ -DTEST_S=ON -DTEST_NS=OFF ``` We ran this test
ZjQcmQRYFpfptBannerStart
This message was sent from outside of Texas Instruments.
Do not click links or open attachments unless you recognize the source of this email and know the content is safe.
Report Suspicious <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/G3vK!uXdq_RaPN01xCsXEHfkD30…>
ZjQcmQRYFpfptBannerEnd
Hi Brian,
We built secure world TF-M test for AN521 platform:
```
cmake -S spe -B build_spe -DTFM_PLATFORM=arm/mps2/an521 \
-DCONFIG_TFM_SOURCE_PATH="$TFM_SOURCE_DIR" \
-DCMAKE_BUILD_TYPE=Debug \
-DTEST_S=ON -DTEST_NS=OFF
```
We ran this test on a FVP model and stepped through
`tfm_attest_test_1001`. Please find attached a screenshot of the call stack.
Function in `attest_core` (in the Attestation partition) invokes
function in the `tfm_crypto_api`. This request is routed by the Secure
Partition Manager (SPM) into the Crypto partition via `psa_call()`.
On 5/6/25 00:33, Quach, Brian wrote:
>
> Is my configuration valid? How should it work?
>
Any time you call a function across partitions, regardless of isolation
level, the SPM forwards it to the target partition using `psa_call()`
>
Best regards,
Mudit Sharma
Hi,
Assuming Isolation Level 1 and IPC backend, I'm using Attestation partition with SFN model with stateless handle and a custom Crypto partition using IPC model with stateless handle. My custom Crypto partition includes a PSA crypto wrapper which defines all the PSA Crypto APIs to use HW crypto. We used IPC since we want to be able to support isolation level 2-3 in the future.
When the Attestation partition make calls to PSA Crypto (psa_hash_setup for example), should it use a psa_call() to the Crypto Partition? That is what I had expected since the crypto partition is IPC model but I'm seeing it call the PSA crypto code directly. Also, it appears to provide client side psa_hash_operation_t directly to the psa_hash_setup which is expecting the full operation struct.
Is my configuration valid? How should it work?
[ 52%] Building C object secure_fw/partitions/partitions/_1/crypto_sp/CMakeFiles/ti_tfm_psa_rot_partition_crypto.dir/home/brian/gits/secure_drivers/source/third_party/psa_crypto/psa_crypto_wrapper.o
[ 53%] Building C object secure_fw/partitions/partitions/_1/crypto_sp/CMakeFiles/ti_tfm_psa_rot_partition_crypto.dir/__/__/__/__/__/generated/secure_fw/partitions/ti_crypto/auto_generated/intermedia_crypto_sp.o
[ 53%] Building C object secure_fw/partitions/partitions/_1/crypto_sp/CMakeFiles/ti_tfm_psa_rot_partition_crypto.dir/home/brian/gits/spe/source/third_party/tfm/platform/ext/common/syscalls_stub.o
[ 54%] Linking C static library libti_tfm_psa_rot_partition_crypto.a
[ 54%] Built target ti_tfm_psa_rot_partition_crypto
[ 54%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/tfm_attest.o
[ 55%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/tfm_attest_req_mngr.o
[ 55%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/attest_core.o
[ 56%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/attest_boot_data.o
[ 56%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/attest_asymmetric_key.o
[ 57%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/attest_token_encode.o
[ 57%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/generated/secure_fw/partitions/initial_attestation/auto_generated/intermedia_tfm_initial_attestation.o
[ 58%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/lib/ext/t_cose/src/t_cose_sign1_sign.o
[ 58%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/lib/ext/t_cose/src/t_cose_sign1_verify.o
[ 59%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/lib/ext/t_cose/src/t_cose_util.o
[ 59%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/lib/ext/t_cose/src/t_cose_parameters.o
[ 60%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.o
[ 60%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/platform/ext/common/syscalls_stub.o
[ 61%] Linking C static library libtfm_psa_rot_partition_attestation.a
[ 61%] Built target tfm_psa_rot_partition_attestation
[ 61%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/__/__/__/__/platform/ext/common/syscalls_stub.o
[ 62%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/crt_memcmp.o
[ 62%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/crt_memmove.o
[ 63%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/crt_strnlen.o
[ 63%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/service_api.o
[ 64%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/__/__/__/shared/crt_memcpy.o
[ 64%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/__/__/__/shared/crt_memset.o
[ 65%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/sprt_partition_metadata_indicator.o
[ 65%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/sfn_common_thread.o
[ 66%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/psa_api_ipc.o
[ 66%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/__/__/__/spm/core/psa_interface_thread_fn_call.o
[ 67%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/__/__/__/__/interface/src/tfm_attest_api.o
[ 67%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/__/__/__/__/interface/src/tfm_psa_call.o
[ 68%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/__/__/__/__/interface/src/tfm_crypto_api.o
[ 68%] Linking C static library libtfm_sprt.a
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
12500 TI Blvd, MS F-4000
Dallas, TX 75243
214-479-4076
Hi everyone,
We're excited to announce the release of TF-M v2.2.0!
Major Highlights:
*
LLVM build support for MPS2/3/4 and RSE platforms.
* Mbed TLS upgraded to version 3.6.3.
* Now compliant with PSA Architecture Compliance Kit tests v1.6.
* Initial hybrid platform support:
* Enables on-core and off-core clients (A-profile + M-profile or multiple M-profile).
* Uses HYBRID_PLAT_SCHED_TYPE=NSPE (aka Solution 2).
* Note: This feature is under active development and testing.
* New platforms support
* Initial support for building nRF54L15
* Initial support for building stm32wba65i-dk
For full details, please refer to the release notes<https://trustedfirmware-m.readthedocs.io/en/tf-mv2.2.0/releases/2.2.0.html>.
TF-M v2.1.2 (LTS) Release
We've also released TF-M v2.1.2 on the LTS branch, which includes critical bug fixes, such as:
* Fixed issue where Protected Storage content could be lost under full storage conditions followed by device resets.
* Correctly mark NSPE images in the wrapper.
* Various SPM fixes:
* Removed specific section for psa_interface_thread_fn_call.
* Added missing fih_rc return value checks in interrupts.
* Resolved issues with IOVEC unmapping.
* Proper handling of refused psa_connect calls.
* Fixed invalid connection retention after psa_close.
* Resolved issues with reverse-handle usage.
*
*
New platform support:
*
MAX32657 port now available.
A huge thank you to everyone who contributed, reviewed, and supported this release!
The v2.2.0 changes will be ported to the main branch shortly. Stay tuned!
Anton and TF-M team
Hi
Just forwarding older private discussion to mailing list to make it publicly available.
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: Antonio De Angelis <Antonio.DeAngelis(a)arm.com>
Sent: Thursday, December 14, 2023 15:57
To: Mazurak Roman (CSS ICW SW FW 3) <Roman.Mazurak(a)infineon.com>; Anton Komlev <Anton.Komlev(a)arm.com>; Hunko Bohdan (CSS ICW SW FW 3) <Bohdan.Hunko(a)infineon.com>
Subject: Re: Weird behavior of Clang linker
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 Roman,
I tried to look in the ELF spec that I could find by googling, but what I can find online doesn't mention the topic of alignment requirements at all other than a brief mention of how the base address and align requirements must be coherent. How the requirement on alignment propagates from sections to execution regions to load regions is still something that I am trying to understand as I can't find an exhaustive description. The info I shared below stem from a personal conversation that I had with the compiler team internally here in Arm, I have now asked for a reference, will revert back to you in case I get one.
[cid:0aef50f0-9105-480f-8090-06cfaa06b8d3]
Only explicit mention of alignment that I could find is in the armlink manual in section 3.3.3.
[cid:ef5c45ef-7d67-433c-9aba-b8fd7cf0d1c0]
The suggestion from the compiler team are as I mentioned:
1. just disable the strict checks on alignment (i.e. the linker will be then allowed to add padding as required to meet the constraint imposed by the base address of the load region and the ALIGN attributes, by suppressing the diagnostic or using --legacyalign (on a side note, I believe this is the default behaviour on GCC linker for example)
2. rewrite the scatter file to have all the input sections without alignment requirements in the output section where the vector reside, and then have another output section just after the first output section (i.e. with base address +0) to put all the other input sections with increased alignment. As a side note, the suggestion is to also align base addresses of sections using AlignExpr(+0, 4096) (for example, to align to 0x1000) rather than forcing ALIGN attributes. Note that this shouldn't be too complex to attain point 2 but it is something that at the moment we can't work on, but happily merge it in if you're willing to provide a patch for it. Your suggestion of having multiple output section is as well doable, but probably enough to have two of them.
Will get back to you in case I get some more reference about how the alignment requirements in ELF propagate from input section to output sections just to confirm on the spec itself.
Hope this helps, please let me know if any questions!
Thanks, Antonio
________________________________
From: Roman.Mazurak(a)infineon.com<mailto:Roman.Mazurak@infineon.com> <Roman.Mazurak(a)infineon.com<mailto:Roman.Mazurak@infineon.com>>
Sent: Thursday, December 14, 2023 13:37
To: Antonio De Angelis <Antonio.DeAngelis(a)arm.com<mailto:Antonio.DeAngelis@arm.com>>; Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>>; Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com> <Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>>
Subject: RE: Weird behavior of Clang linker
Hi Antonio,
We have a use case when output section has following list of input sections:
* Vectors with alignment by 0x400.
* Partitions sections with alignment by 0x1000.
As result output section alignment is 0x1000 and address is incorrect. So, probably it’s necessary to create a separate output section for each input section.
Can you share a link to ELF specification with requirements for output section alignment?
Best regards,
Roman.
From: Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Sent: Wednesday, December 13, 2023 18:56
To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Hunko Bohdan (CSS ICW SW FW 3) <Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>>
Subject: [TF-M] Re: Weird behavior of Clang linker
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,
For reference, this is due to armlink being strict on following the ELF specification for which the region alignment is derived as the maximum alignment of the input sections. You can relax this requirement with armlink by either using the --legacyalign option (although it's being deprecated) or suppressing the diagnostic --diag_suppress=6244. In the future, we could try to reorganize the scatter file for the armclang toolchain to avoid using directly ALIGN attributes and align the base address of the execution regions using AlignExpr() instead, but even with this strategy, any alignment requirement which stems from using .aligned directive in assembly or attribute __ ((aligned)) attributes will influence the input sections alignment, hence it will require a deeper restructuring of the scatter file, possibly moving sections with increased alignment in a separate load region just after LR_CODE which must have a base address that forces a natural alignment.
Hope this helps.
Thanks, Antonio
________________________________
From: Bohdan.Hunko--- via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Sent: Monday, December 11, 2023 13:39
To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Subject: [TF-M] Re: Weird behavior of Clang linker
Hi Anton,
Here is the version I am using:
$ armclang --version
Product: Arm Development Studio Gold Edition 2020.1
Component: Arm Compiler for Embedded 6.19
Tool: armclang [5e73cb00]
Target: unspecified-arm-none-unspecified
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: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>>
Sent: Monday, December 11, 2023 15:34
To: Hunko Bohdan (CSS ICW SW FW 3) <Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: RE: Weird behavior of Clang linker
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,
What is Clang version you are using?
Thanks,
Anton
From: Bohdan.Hunko--- via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Sent: Monday, December 11, 2023 12:58 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] Weird behavior of Clang linker
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>
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.
Hi, does TF-M use LTO? I didn't see any flags to disable it in toolchain_GNUARM.cmake. I think for GCC, it's enabled by default if no flag is set.
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
12500 TI Blvd, MS F-4000
Dallas, TX 75243
214-479-4076
Hello,
We're kicking off the release process for TF-Mv2.2.0, starting with the TF-Mv2.2.0-RC1 tag.
As part of this release phase, we're also updating the previous version to TF-Mv2.1.2, which includes critical bug fixes and support for new platforms. New TF-Mv2.1.2-RC1 tag will follow shortly.
After completing initial testing on the reference platform and addressing all identified issues, we'll reach out to platform owners to verify TF-M on platforms not available in LAVA. Please note, the verification might be requested on a different tag by that time.
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
Hi Team,
I am setting the TFM_SPM_LOG_LEVEL to DEBUG in platform config.cmake. Yet it is getting overwritten by TFM_SPM_LOG_LEVEL_SILENCE. Is there any other place I need to look for? Thanks.
Michael KH
# LOG LEVEL
set(TFM_SPM_LOG_LEVEL TFM_SPM_LOG_LEVEL_DEBUG CACHE STRING "Set default SPM log level as DEBUG level")
Hello,
TF-M release v2.2.0 is unfortunately delayed for about a month.
The new tentative start date is the end of February with a goal to complete the release at the middle of March.
The main reasons of the delay are:
* Delays in PSA certification of RPi2350 platform
* An opportunity to accommodate of Mbed TLS v3.6.3 planned on February
* Limited availability of TF-M maintainers
Thanks, and sorry for the possible inconveniences caused be this delay,
Anton
Hello,
Following the Tech Forum yesterday I am repeating the questions asked at the time.
Please share your opinions
* Do we need C++ support on S side?
* CLANG/LLVM toolchain name
* toolchain_CLANG.cmake vs toolchain_LLVM.cmake
* Can we drop the support of -march -mtune options in favor of -mcpu only?
* Can we limit supported toolchains to the earliest version with m55 support?
In other words: is there anyone who must use toolchains earlier than in the table?
Toolchain
Cortex-M55 support since
Release Date
ArmClang
V6.14
March 2020
GNU Arm Embedded Toolchain
V10.
December 2020
LLVM Embedded Toolchain for Arm
V11.0.0
September 2020
IAR Embedded Workbench
V8.50
November 2020
Thanks,
Anton
Hi Everyone,
Following today's announcement in the Tech Forum, I am pleased to share that the TF-M maintainer team is expanding.
We warmly welcome back David Hu (davidhuzj(a)gmail.com<mailto:davidhuzj@gmail.com>) to the maintainer team!
David has been a key contributor and TF-M maintainer for several years. After a brief pause, he has kindly agreed to resume his role, overseeing TF-M changes once again.
Thank you, David, for your continued commitment and contributions to the project!
All the best,
Anton
Hi,
In TF-M v2.0, Initial_attestation.h says:
* The initial attestation token is planned to be aligned with future version of
* Entity Attestation Token format:
* https://tools.ietf.org/html/draft-mandyam-eat-01
But that spec is expired and superceded with the following.
Is the implementation aligned with the following spec? If so, what version of this spec is actually supported?
https://datatracker.ietf.org/doc/draft-ietf-rats-eat/02/
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
Hello Everyone,
We are currently working on TF-M for the firmware of our Cortex-M55 based core, part of a bigger platform
including a cortex-A based application processor, a bit like the corstone1000.
We use the RAM_LOAD boot mode of TF-M/MCUBoot and we want to implement an upgrade strategy based on
2 banks, and a switch to decide which bank to boot from. I have a few questions regarding some design choices.
I hope someone can answer them. Please correct me if some of my assumptions are wrong.
*
For the generic Firmware Upgrade partition, are there plans to support the RAM_LOAD mode ? Do you have
suggestions about what is missing or how it should be done ?
*
Currently, MCUBoot in RAM_LOAD mode only supports booting the slot with the highest version.
Do you think it is realistic to try and integrate another boot mode in MCUBoot that matches our needs ?
I'm asking this because I noticed that the corstone1000 platform has been developed working around
this limitation by changing the flash_map at platform initialization in order to abstract the problem from
MCUBoot completely.
Thank you and all the best,
Julien
Hi all,
I would like to know if the PSA ITS is protected in case tearing cases (power failure) happening during write/erase in the internal flash, using `psa_its_set()` or `psa_its_remove()`, please.
Thanks a lot.
Best regards,
Abel.
Could you please help with my issue? Thank you!
From: Michael Ji
Sent: Friday, February 14, 2025 4:15 PM
To: Raef.Coles(a)arm.com; Anton.Komlev(a)arm.com
Subject: TFM build error
Hi Raef and Anton:
I am following the steps in this webpage to build tfm on my Windows laptop:
https://trustedfirmware-m.readthedocs.io/en/latest/getting_started/index.ht…
All my steps are successful till I ran this command below and got error (FYI - I am using the platform arm/mps2/an521 and GNU ARM compiler):
[cid:image001.png@01DB7EFB.878CE310]
Could you share your insight on how to resolve this? Thank you very much!
Best,
Michael
Hi all,
We would like to remove PSA_IOT_PROFILE_1<https://review.trustedfirmware.org/q/topic:%22remove-psa_iot_1%22> which is an early attestation token profile (used for the original
implementation of the PSA Initial Attestation service) and has been superseded by profile PSA 2.0.0
(https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-09.html#nam…).
The above patches include:
* Change the default token profile configuration to: ATTEST_TOKEN_PROFILE_PSA_2_0_0,
* Remove support for PSA_IOT_PROFILE_1.
Please let us know if you have any concerns, suggestions.
Best regards,
David Vincze
Hi,
I'm trying to add platform power control functions (to power off/on peripherials) to the SPM. Are there any examples of this? What is the cleanest way to implement? Can it be done via adding code to source/third_party/tfm/platform/ext/target/<vendor>/ and compiling into the platform_s target?
The diagram below says connection between SPM and PRoT partitions is IMPLEMENTATION DEFINED. How does the TF-M implement PRoT partitions to call the SPM? Can it be a direct API call? I did see platform_svc_handlers() but I assume that was for use by ARoT partitions (unpriviledged).
DEN0063 PSA Firmware Framework:
Some platforms include functionality that can only be accessed by firmware at the highest privilege level. For example, platform power control or control registers that are shared by secure and non-secure firmware. These Platform services must be implemented as part of the SPM, but the mechanism by which the NSPE firmware accesses these services is IMPLEMENTATION DEFINED.
[cid:image001.png@01DB7E32.B6F3B0D0]
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
12500 TI Blvd, MS F-4000
Dallas, TX 75243
214-479-4076
Hi all,
I just wanted to bring to your attention that TF-M has switched<https://review.trustedfirmware.org/q/topic:%22t_cose_upstream%22> to using the upstream t_cose library (which is used during creating and validating
attestation tokens). The main reason for this change is to remove the forked t_cose code from the TF-M repository, along with its maintenance needs
(similarly to the QCBOR library). Additionally, it will also allow us having consistent library code across all tf.org projects.
Under normal circumstances, this change should not have any impact on you – the library code is fetched automatically during build. It might happen
that you encounter CI failures in connection with this change, but you will only need to rebase your patches to align with the changes in the CI.
Best regards,
David Vincze
Hi All,
I have several questions. Thanks in advance for helping out.
1. I am trying to build a TF-M application for my platform with small profile with asymmetric signing module enabled. I tried using following command
cmake -S . -B build -G Ninja -DTFM_PLATFORM=MY/PLATFORM -DTFM_PROFILE="profile_small" -DCRYPTO_ASYM_SIGN_MODULE_ENABLED=y.
However, the asymmetric signing module is not included. More specifically, in trusted-firmware-m/secure_fw/partitions/crypto/crypto_asymmetric.c, the #if CRYPTO_ASYM_SIGN_MODULE_ENABLED is not true.
From what I understand, the -DCRYPTO_ASYM_SIGN_MODULE_ENABLED=y only define the macro, but not set it to 1, therefore, the #if CRYPTO_ASYM_SIGN_MODULE_ENABLED is not true. I am wondering if there is any way I can enable -DCRYPTO_ASYM_SIGN_MODULE_ENABLED module while still staying in small profile. I am aware that the default CRYPTO_ENGINE_BUF_SIZE might not be enough and I am willing to override it with a command line flag. Preferably, I would not want to enable asymmetric module in config.cmake as I only want to enable it for one specific application.
1. If to build with Zephyr and have TF-M as a module, is there anyway to enable asymmetric signing module given a small profile (I actually care more about this question than first question)
1. Just out of curiosity, how do you use menuconfig in TF-M. I did try -DMENUCONFIG=ON, but the compiler complains
CMake Error at config/kconfig.cmake:31 (file):
file STRINGS file
"trusted-firmware-m/config/../platform/ext/target/MY/PLATFORM/preload.cmake"
cannot be read.
Call Stack (most recent call first):
config/kconfig.cmake:174 (convert_normal_cmake_config_to_kconfig)
CMakeLists.txt:26 (include)
I thought preload.cmake is no longer required.
Thank you very much!
Best regards,
Hao
Hi,
I noticed this FIXME note in platform_sp.c. Is it still valid? If so, why does it only work with Isolation level 1? I thought system reset is typically an NVIC register write and platform SP should be able to do that.
enum tfm_platform_err_t platform_sp_system_reset(void)
{
/* FIXME: The system reset functionality is only supported in isolation
* level 1.
*/
tfm_platform_hal_system_reset();
return TFM_PLATFORM_ERR_SUCCESS;
}
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
Hi,
I'm doing a PoC on initial attestation for an university project using a
RP2350 board and I'm not really understanding why boot seed is stored in
OTP, shouldn't it be a value changing on each boot?
Pico SDK conveniently exposes one via a ROM function (rom_get_boot_random).
Another similar doubt I have is w.r.t. implementation id, couldn't it be
read from the board id (pico_get_unique_board_id)? Board id is factory
programmed in otp so it should actually be unique.
Best Regards,
Augusto Zanellato
