The 1.4.x branch is only intended for security fixes.
https://developer.trustedfirmware.org/w/collaboration/tf_m_security_patch_release/
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Sep 28 2021
Sep 27 2021
Sep 25 2021
Sep 24 2021
Sep 23 2021
Sep 22 2021
Thanks for your check. Would you also backport the patch to TF-M 1.4?
Sep 20 2021
Sep 18 2021
Hi ioannisg,
I think you're right.
The Secure PendSV is masked by NSPE, although it has the same priority value 0x80.
It has to have a lower value to preempt the NSPE, having an equal priority value does not work.
Sep 17 2021
Sep 16 2021
Sep 15 2021
Sep 13 2021
Sep 10 2021
Note: Feedback to the PSA spec team for a priority value to be associated to each JSON file for those configurations where we have multiple accelerators available.
Sep 6 2021
The spec currently defines an attribute for an entry point (or family of) in the JSON file, i.e. algorithms, which is used by the core to decide if the entry point needs to be applied for a particular algorithm or not. The JSON file is meant to be consumed as a description of the driver by the mbedTLS parser at build time, in order to link the driver entry points properly into the driver core.
Sep 4 2021
After additional analysis, the summary of the discussion is that these entry points are more suited to be implemented for an hardware which implements a fast way to provide random numbers. CC-312 exposes a TRNG source through the get_entropy entry point, but the remaining part of the DRBG algorithms is implemented in firmware (possibly only partially accelerating parts of them through the driver crypto core transparently calling into the driver from within its own software implementation). For this reason, I am marking this item as Won't do.
Sep 3 2021
Sep 2 2021
Aug 31 2021
Verified by building qemu 6.1.0 from source as it's been released on 24/08. Regression for AN521 passes without problem on this version. Closing this ticket with a recommendation to re-enable Open CI test cases based on Qemu after upgrading the Qemu version available in Open CI to 6.1.0.
Aug 26 2021
fix change need to review at:
11218: fix(xlat): fix crash when enable verbose log on some platform.
Aug 25 2021
Aug 24 2021
Aug 21 2021
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11159/1
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11160/1
Aug 20 2021
Aug 16 2021
Aug 13 2021
This is pending on this PR from mbedTLS for support on the backend side: https://github.com/ARMmbed/mbedtls/pull/4338
Associated ticket: https://github.com/ARMmbed/mbedtls/issues/3257
This would require some reworking of the low level CC driver as well as the current implementation only supports single-shot AEAD operations.
Aug 9 2021
Aug 6 2021
Aug 4 2021
Copying response on mailing list.
Aug 3 2021
For PSA_ALG_MD4 error, I think it is the mismatch between tfm and psa arch test. We have a patch to workaround this issue in tfm (lib/ext/psa_arch_tests/0004-Align-with-mbedtls-3.0.0.patch).
Suggest you apply these patches if you specify your own psa arch test path.
I tested with the following command with TF-Mv1.4.0-RC3:
-DTFM_PLATFORM=nordic_nrf/nrf5340dk_nrf5340_cpuapp -DTFM_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Debug -DTEST_PSA_API=INITIAL_ATTESTATION -DTFM_PSA_API=ON
If it's an RTX issue, then please contact RTX people. Thanks very much.
Aug 2 2021
Aug 1 2021
This issue has been fixed by:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10402
Jul 30 2021
Ran into this as well when porting a new target and trying to get all constellations of test suites up and running. It seems to be an issue with how thread joins are handled during RtxThreadExit in RTX 5.5.0. Tracing the disassembly in the kernel makes me think there's some sort of optimisation bug in the precompiled libraries, since the idle thread is marked for running instead of the test thread (which was waiting on the join).
i will try to revert the patch that is mentioned above and report here.
Jul 29 2021
I think it's not the priority issue.
I'm testing with:
- The NS is bare metal (is that the terminology? Only a main function, NO RTOS)
- The NS calls test_app(NULL) directly - some RTOS dependencies have been removed such as the PS test suites and the tfm_ns_interface implementations.
- Before the test_app was called, I set the BASEPRI_NS to 32 using the debugger
It looks like a:
Jul 28 2021
Hi Kevin.