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.

fix change need to review at:
11218: fix(xlat): fix crash when enable verbose log on some platform.

https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11159/1
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11160/1

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.

Copying response on mailing list.

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.

This issue has been fixed by:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10402

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.

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:

Hi Kevin.

Hi @ioannisg , my understanding is the same as yours.
In theory, there should be any issues.
May I ask which service were you connecting to and got the invalid handle?
And could you provide more information on how the IRQs are locked? I have not ever used the BASEPRI_NS.
Any other information like the version of TF-M you are integrating and build configurations would also help.
Thanks.

This issue has been fixed.

Single shot key agreement:

hash_compute has been added directly by @salomethirot-arm to the multipart patch available here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10607 as discussed during the last sync-up call. @Vge0rge please do have a round of review of the hash_compute (and the whole patch as well) to get to +1 status.

https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10607

OK, could you take this issue, @adeaarm ?

Probably better to reduce the priority of the ticket but keep it open just to make sure we are reminded to verify it again once the next release of qemu is available.

Thanks Antonio for the information.
Since this is not a TF-M issue, suggest closing it.

Hi @ioannisg , this is due to this bug in QEMU: