Prototypes derived from: https://github.com/ARMmbed/mbedtls/blob/development/library/psa_crypto_driver_wrappers.h

Prototypes derived from: https://github.com/ARMmbed/mbedtls/pull/4338/

Prototypes derived from: https://github.com/ARMmbed/mbedtls/blob/development/library/psa_crypto_driver_wrappers.h

These prototypes are available upstream either in https://github.com/ARMmbed/mbedtls/blob/development/library/psa_crypto_driver_wrappers.h or as a Pull Request: https://github.com/ARMmbed/mbedtls/pull/4338/

I think you could start from the single-shot AEAD APIs because it's the only single shot API that I am sure we test 100% in the TF-M regression tests.

Due to a bug recently discovered in Qemu, we should mention in the docs that minimum required version is 6.1 (to be released around mid-end of August)

There is also an hash_clone entry point which is not currently documented in the spec draft but is present as a call in the core layer.

Given that there's no activity to get the submission rule issues in 9990 resolved, I followed CJKay's and jwerner's instructions and made https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/10415, hopefully more ready for inclusion.

Still happens with TF-A 2.5.

Duplicate of T873.

Note that as part of this activity the following bug in the Qemu porting of the mps2-an521 board has been found and fixed with the following pull request:

Patches available here:

FYI I removed the previous SPAM comment.

As you know, for secure and non-secure side are closely related in TF-M. In latest TF-M v1.3 release, FP support (in secure side either non-secure side) are not official announced, so the problem you reported is not a TF-M bug.

Thank you for letting us know the problem when you are using TF-M, this is helpful for all stakeholder of TF-M.

Hi Feder,
Honestly, I've only faced this issue when doing some advance scheduling manipulations on the Non-Secure side (modifying LSPACT, FPCA, etc.), so not in mainline TF-M/RTOS use-cases. Please disregard it for now.

In T921#10778, @ioannisg wrote:

However, this is only a partial solution. That is because a Secure thread re-scheduling will clear the .FPCA flag, but leave the LSPACT set, meaning that a NS IRQ with FP instructions will trigger again an FP stacking. But this FP stacking will be done on the memory where FPCAR is pointing at, and FPCAR is only updated in exception entry, if .FPCA is set. As a result, it does not seem that you avoid a stack corruption.

Let me know if you've understood this argumentation, or you need more information.

Any updates here, Feder?

However, this is only a partial solution. That is because a Secure thread re-scheduling will clear the .FPCA flag, but leave the LSPACT set, meaning that a NS IRQ with FP instructions will trigger again an FP stacking. But this FP stacking will be done on the memory where FPCAR is pointing at, and FPCAR is only updated in exception entry, if .FPCA is set. As a result, it does not seem that you avoid a stack corruption.

Hi Feder, correct; setting CPACR_S solves the problem of Secure No-Coprocessor Usage Fault.

Please try to add code below just before setting NSACR in tfm_arch_config_extensions() and let me know the result. Thanks!

Following the discussion on the meeting I would update my comment:

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

Anton, could you please, suggest an assignee for this one? Thanks!

Hi Feder,