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.
Hello,
TF-M OpenCI fails all LAVA tests and all builds are fail consequently, probably because of a new license mechanism. An investigation and problem fixing are ongoing. I will update you when the problem will be resolved.
Best regards,
Anton
Hi Ruchika,
thanks for your email and apologies for the late reply but I did not receive this directly so I am replying only because I was pointed to this.
TF-M would really welcome a contribution to move those drivers to the autogen framework. This has not been done yet due to lack of bandwidth on TF-M side. Would like to note that the TF-M builtin key loader driver can't be (maybe, just completely) moved to the autogen framework because it patches some internals of Mbed TLS as well (i.e. you would need to patch the jinja template as well). But the CC3XX driver is absolutely something that we would like to move to the autogen framework without any issue.
Thanks,
Antonio
Hello,
We plan to initiate TF-M v2.1.0 release with a feature freeze on April 8th targeting completion before April 28th.
Please let me know if there are pending patches critical to be included in this release and shall be merged before the feature freeze.
Thanks,
Anton