Hello,
I followed this tutorial to add an example secure partition in TF-M ( https://tf-m-user-guide.trustedfirmware.org/integration_guide/services/tfm_… ) and then followed these instructions to flash the application to my Nucleo-L552ZE-Q board ( https://tf-m-user-guide.trustedfirmware.org/platform/stm/common/stm32l5xx/r… ). However, the script regression.sh returned the error:
Error: Cannot connect to access port 0!
If you are trying to connect to a device with TrustZone enabled please try to connect with HotPlug mode.
If you are trying to connect to a device which supports Debug Authentication with certificate or password, please open your device using it.
After this, I am unable to connect my board STM32Cube Programmer or to flash any application using Keil MDK ARM, CubeIDE, etc. The same error is returned every time. Before I runned the regression.sh script, the board was working as expected and I was able to flash simple applications (non using TF-M) to the board. I've already tried to connect the board to the STM32Cube Programmer using the Hot Plug mode - (i) pulled BOOT0 pin to HIGH, (ii) connected the board to the PC, (iii) selected Hot Plug mode in STM32Cube Programmer and Hit Connect - but did not work. I get this log:
[cid:20937ade-7ed2-4beb-bced-d577c3e58dd3]
Hi all,
Why does TFM assigns function to psa_interface_thread_fn_call section and then never places them anywhere specific?
This way functions assigned to this section are placed outside of the code region which may result in unpredictable behavior.
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>
Thanks Antonio! 😊
(fixed typo in subject, sorry ☹)
Thanks,
William
From: Antonio De Angelis <Antonio.DeAngelis(a)arm.com>
Date: Wednesday, May 15, 2024 at 2:18 PM
To: "Lee, William" <William.Lee(a)garmin.com>, "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org>
Subject: Re: Is crytocell-312 now maintaining by TF-M mainly?
Yes, CryptoCell code in the TF-M repo is the only maintained repository. Thanks, Antonio Sent from Outlook for Android From: Lee, William via TF-M <tf-m@ lists. trustedfirmware. org> Sent: Wednesday, May 15, 2024 5: 32: 59 am To: tf-m@ lists. trustedfirmware. org
Yes, CryptoCell code in the TF-M repo is the only maintained repository.
Thanks, Antonio
Sent from Outlook for Android<https://urldefense.com/v3/__https:/aka.ms/AAb9ysg__;!!EJc4YC3iFmQ!Q29CY2id1…>
________________________________
From: Lee, William via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: Wednesday, May 15, 2024 5:32:59 am
To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>
Subject: [TF-M] Is crytocell-312 now maintaining by TF-M mainly?
Hello!
I saw [1] is not updating anymore, but [2] is still active, anyone knows if [2] is the main place for cryptocell-312? Thanks!
[1] https://github.com/ARM-software/cryptocell-312-runtime<https://urldefense.com/v3/__https:/github.com/ARM-software/cryptocell-312-r…>
[2] https://git.trustedfirmware.org/TF-M/trusted-firmware-m/+log/refs/heads/mai…<https://urldefense.com/v3/__https:/git.trustedfirmware.org/TF-M/trusted-fir…>
Thanks,
William
Hello,
I am happy to announce the new release of TF-M v2.1.0.
New major features are:
* TF-M aligns the Crypto service to the same PSA Crypto headers used by the Mbed TLS 3.6.0 reference implementation.
* Initial support for on-core and off-core clients on Hybrid platforms (A-profile + M-profile or M-profile + M-profile) using solution 1. The functionality is still under active development.
* P256-M component is enabled on the BL2 stage for image signature verification based on ECDSA.
* MCUboot upgrade to v2.1.0.
* Mbed TLS upgrade to v3.6.0.
* BL2 now provides a thin PSA Crypto core layer when MCUBOOT_USE_PSA_CRYPTO=ON and can use builtin keys when ECDSA based signature verification is selected with MCUBOOT_SIGNATURE_TYPE="EC-P256".
This version is the first, intended for Long Term Support (LTS) after PSA certification and tagging TF-Mv2.1.0-LTS as described in the updated Release Process.
Please check the release notes for more information.
The release branch changes will be ported to the main branch shortly.
Many thanks to everyone for contributing, reviewing and supporting this milestone.
Anton and TF-M team.
Hi
I am trying to use iatverifier tool from tf-m-tools repo to verify token and it seems like the values for Security Lificycle in the tool are wrong, because:
this spec https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-21.html defines them as
psa-lifecycle-unknown-type = 0x0000..0x00ff
psa-lifecycle-assembly-and-test-type = 0x1000..0x10ff
psa-lifecycle-psa-rot-provisioning-type = 0x2000..0x20ff
psa-lifecycle-secured-type = 0x3000..0x30ff
psa-lifecycle-non-psa-rot-debug-type = 0x4000..0x40ff
psa-lifecycle-recoverable-psa-rot-debug-type = 0x5000..0x50ff
psa-lifecycle-decommissioned-type = 0x6000..0x60ff
Which is consistent with values of tfm_security_lifecycle_t enum in TFM
enum tfm_security_lifecycle_t {
TFM_SLC_UNKNOWN = 0x0000u,
TFM_SLC_ASSEMBLY_AND_TEST = 0x1000u,
TFM_SLC_PSA_ROT_PROVISIONING = 0x2000u,
TFM_SLC_SECURED = 0x3000u,
TFM_SLC_NON_PSA_ROT_DEBUG = 0x4000u,
TFM_SLC_RECOVERABLE_PSA_ROT_DEBUG = 0x5000u,
TFM_SLC_DECOMMISSIONED = 0x6000u,
TFM_SLC_MAX_VALUE = UINT32_MAX,
};
But in the tf-m-tools/iat-verifier/iatverifier/psa_iot_profile1_token_claims.py these values are defined differently
# Security Lifecycle claims
SL_UNKNOWN = 0x1000
SL_PSA_ROT_PROVISIONING = 0x2000
SL_SECURED = 0x3000
SL_NON_PSA_ROT_DEBUG = 0x4000
SL_RECOVERABLE_PSA_ROT_DEBUG = 0x5000
SL_PSA_LIFECYCLE_DECOMMISSIONED = 0x6000
Thus I am getting SL_UNKNOWN instead of TFM_SLC_ASSEMBLY_AND_TEST
Is this a known issue? Can this be fixed?
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,
For Isolation Level 2, ARoT cannot access PRoT data. If PRoT partition makes a call to ARoT partition, how are the input/output buffers made accessible to the ARoT partition so a transient copy of the data can be made? I looked at the AN521 implementation of tfm_hal_activate_boundary() and it does add any MPU regions to allow unprivileged access under Isolation Level 2.
For Isolation Level 3, I assume the input/output buffers would need to added to a runtime memory asset to allow unprivileged access. Is my understanding correct?
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
12500 TI Blvd, MS F-4000
Dallas, TX 75243
214-479-4076
Hi,
I see that tfm_crypto_call_srv() unmaps output vectors if PSA_FRAMEWORK_HAS_MM_IOVEC == 1, but I never see psa_unmap_invec called. This doesn't seem to be required from a functional standpoint but I was wondering if psa_unmap_invec() was purposely skipped to save some unnecessary execution time. Is psa_unmap_invec() only implemented for testing purposes?
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
12500 TI Blvd, MS F-4000
Dallas, TX 75243
214-479-4076
Hi,
I noticed this build warning with PSA_FRAMEWORK_HAS_MM_IOVEC enabled. runtime_defs.h need to be updated to add the `const` qualifier I think.
tfm/secure_fw/spm/core/psa_interface_thread_fn_call.c:287:33: warning: initialization of 'void * (*)(psa_handle_t, uint32_t)' {aka 'void * (*)(long int, long unsigned int)'} from incompatible pointer type 'const void * (*)(psa_handle_t, uint32_t)' {aka 'const void * (*)(long int, long unsigned int)'} [-Wincompatible-pointer-types]
287 | psa_map_invec_thread_fn_call,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tfm/secure_fw/spm/core/psa_interface_thread_fn_call.c:287:33: note: (near initialization for 'psa_api_thread_fn_call.psa_map_invec')
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
