Hello
We have some platform-specific values provisioned in OTP that we need to retrieve and store in ITS (with encryption enabled) during initialization. We could do something similar to template file crypto_nv_seed.c, where the tfm_plat_crypto_provision_entropy_seed function is invoked from tfm_crypto_engine_init within secure_fw/partitions/crypto/crypto_init.c. However, we have a few questions:
1. Adding something similar in tfm_its_init won’t work as psa_its_* would again call into ITS via SPM which could be a problem? Also there is no hook in its_init to add platform specific routines as well? Is this correct?
2. Since crypto_init.c is part of secure_fw/, we’re uncertain about adding new platform-specific routines directly in tfm_crypto_engine_init. If this is not advisable, could you suggest an ideal place for implementing this functionality?
3. Regarding the SFN model, our understanding is that SPM initializes all partitions (and their respective services) before transitioning control to the NS side. Could you confirm if this is correct? We want to make sure that the provisioned values are stored in ITS before receiving request from NS client.
Thank you for your guidance!
Saurabh
Open CI infrastructure has been down since this morning and currently still not working. Will post updates to the mailing list once they are available.
Thanks,
Antonio
Hi All
I am quite new to TF-M and would like some insight into the query below. I appreciate any help you can provide.
We're adding encryption support for ITS and for nonce requirement, we're thinking of accessing TRNG which is part of the crypto partition. Now, we're aware of the possible cyclic dependency issue with the IPC model but since we're using the SFN model, will it be okay to access crypto service(TRNG) from ITS? In other words, would cyclic dependency be a concern in SFN model provided there are no limitations on hardware?
Thanks in advance.
Saurabh
Hi all,
A heads up that the Total Compute 2022 (TC2) platform is due to be deprecated. If there is no objection, I will go ahead and remove TC2 from the TF-M codebase a month from now (25/11/24). Thank you.
Thanks,
Jackson
Hi all,
I'm currently looking into an issue reported internally where the maximum latency for a zero-latency, priority 0 interrupt dramatically increases during a call to the PSA Protected Storage (PS) API.
The maximum interrupt latency goes up ~10-fold, or even some more at times (it varies), and this is not acceptable to code running on the NS side for normal operation.
It's as simple as calling psa_ps_set(1, 4, buf, PSA_STORAGE_FLAG_NONE) once.
During that call (which I am told was also seen to be unreasonably long: 600ms for 4 bytes, 1s for 1000 bytes), the maximum interrupt latency goes up.
It (the maximum) seems to not vary too much even if increasing the size of stored assets (tested up to 4000 bytes), though it can get up to 20 times higher than the normal interrupt latency.
Also, other functions were tested (psa_generate_random(), psa_hash_compute()).
Those don't provoke an increased interrupt latency. Maybe it's only about the PS, or maybe some other calls can provoke that as well.
Does someone have an explanation for that?
And even more importantly, can that interrupt latency be reduced, ideally down to normal levels?
Thanks in advance.
Tomi
Hi,
We are going to set the PSA_2_0_0 profile as the default for the initial attestation service. This will impact which claims are included in the token and their key values.
More details are here:
https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-24.html
Changes on review:
https://review.trustedfirmware.org/q/topic:%22attest_profile_update%22
As a follow-up action, the PSA_IOT_PROFILE_1 is being deprecated.
We are planning to remove it from the code base as well.
To figure out the timing of this we would like to collect some data:
* If you are using the PSA_IOT_PROFILE_1 please let us know what would be a feasible time for you to switch over the PSA_2_0_0 profile. Thanks!
Best regards,
Tamas Ban
Hello,
This email is a notification of a new security vulnerability reported to TF-M by Infineon Technologies AG, in collaboration with: Tobias Scharnowski, Simon Wörner and Johannes Willbold from fuzzware.io.
Unchecked user-supplied pointer via mailbox messages may cause write of arbitrary address.
Please find the security advisory attached. The fix has been merged on the latest main branch tfm_spe_mailbox: Do not write-back on input vectors checks failure<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/31512>
We're preparing a hotfix release v2.1.1 to include fixes for this vulnerability and bugs reported till that date via TF-M issue tracker: https://github.com/TrustedFirmware-M/trusted-firmware-m/issues?q=is%3Aissue
Thanks and best regards
Author
