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.

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

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.

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

Cipher/MAC single-shot APIs patches:

Hash: https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/10544
MAC: Support in mbedtls-2.26.0 for the single-shot APIs is not present. I have a patch to enable the tests and the shim layer in TF-M, I will keep it private until support from the backend side is available somehow for the feature-cc-psa-crypto-drivers dev branch.
Cipher: Support in mbedtls-2.26.0 for the single-shot APIs is not present. I have a patch to enable the tests and the shim layer in TF-M, I will keep it private until support from the backend side is available somehow for the feature-cc-psa-crypto-drivers dev branch.
AEAD: Single-shot APIs for AEAD are already supported, multipart is missing (both in TF-M and in the backend and driver entry points, still pending review in mbedTLS)
No Key agreement single shot API test yet. Need to understand and add it.

This patch extends tests coverate in the TF-M regression test suite for the single-shot hash API.

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/

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.

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:

With a recent version of QEMU (i.e. 4.x), it should be enough just to use this to run TF-M on QEMU for AN521:

Preliminary change showing passing TF-M regression available here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2391

Assigned to @davidwang for futher tracking and follow up.

Changes for this issue:

Patch for this is available here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1661

https://review.trustedfirmware.org/c/trusted-firmware-m/+/1654

Hi @qixiang , could you help debugging? Most probably the faulty commit is blocked in an fault handler, it would be good to know which instruction causes the fault to be triggered to speed up analysis from developer's point of view.

This will be completed by an additional refactoring to use abstracted OS interface when possible (i.e. os_wrapper_*) to be done by @kevin-peng-hao . Please use this ticket to keep track of the additional change.

One additional change for this that I missed on the first patch (thanks @matetothpal ): https://review.trustedfirmware.org/c/trusted-firmware-m/+/1594/

As explained above, this is not an issue as if a user project needs to include for some reason more than one implementation of the same PSA crypto interface, it's up to the user to provide a separation of the include trees.

There is no conflict anywhere in the header names of the TF-M project. Your use case is to have both Mbed Crypto and TF-M as part of the same IDE project, at that point is up to you to provide a clear separation of the different include trees of Mbed Crypto and TF-M, and not rely on the fact that having the same names they will have same contents, as they are two different implementations of the same interface, coming from two different projects and not distributed together (i.e. they have different paths by design).

Not sure what is your use case, but I don't see how it's possible to compile Mbed Crypto and TF-M Crypto as part of the same application without doing symbol renaming of one of the two, given that they export the same symbol names. So I assume you have some way of renaming the symbols of either of the two before compilation, or excluding one of the two at link time.

The expected use case is that an application will have to use a single implementation of the PSA Crypto interface at a time, so there won't be any conflict. In this case the module of the application will just "#include psa/crypto.h" as main header.

the only common difference in the headers is the different license used by the headers distributed by TF-M and the ones distributed by Mbed Crypto.

Change for this is available here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1562

HI @qixiang , the option to build with the debug version of Mbed Crypto or Mbed TLS is presented in our documentation just for the sake of completeness, but it's not something that we actively guarantee (i.e. we can't guarantee that the debug version of the mbedcrypto/mbedtls library will fit on all our platforms, due to different requirements in size). The option should be left as default and overriden only on those platforms that can afford it, and only on designed debug sessions. In my experience so far with the Crypto service, there is no need to debug the mbedcrypto/mbedtls libraries, as that would be out of scope for a TF-M deployment. Please let me know if you have questions or doubts about this.

https://review.trustedfirmware.org/c/trusted-firmware-m/+/1531