The related changes and the reviews can be found on:
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1257/

The related changes and the reviews can be found on:
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1494/

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).

Symbol renaming is OK.
But I have talked about file names, to avoid conflict when TFM and MbedCrypto referencing to "psa/<same_name.h>".
Guess, using a different include directory e.g. "psa_tfm/<same_name.h>" may solve the issue.
P.S. Different headers files should have different names and path - good practice for any use case.

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.

It means that you have decided to add the limitation which is possible to avoid.
It is possible to have and compile TFM, MbedCrypto and PSA test suite without splitting to separate libraries/projects.

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.

It's probably OK when to compile in multiple libraries. The problem happens when to compile sources of MbedCrypto and TFM in one project.
So, as workaround, we have to add psa_ prefix to TFM PSA headers (as it was done in previous version of TFM).

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.

Hi, PSA header files in mbedCrypto and TFM have the same names but a different content.
Guess, if they have the same name and same path, they should have the same content or a have a different prefix.

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

patch has been successfully merged.

Changes for this issue are:

• https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1558/
• https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1559/
• https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1560/

Thanks for your feedback.

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.

Patch link:
https://review.trustedfirmware.org/c/trusted-firmware-m/+/1533

Hi Qixiang, could you check the patch on your side?

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

The change for this issue had been merged

The changes for this issue had been merged

you can find the multi-image support here:
https://developer.trustedfirmware.org/T421

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

Patch link: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1528/

Hi Tamasban,

Reviews:

1. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1511/
2. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1512/
3. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1512/
4. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1512/
5. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1512/
6. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1512/

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

Please email me at soby.mathew@arm.com

ARM Support have asked me not to post any Cryptocell code publicly.

Hi Neil
The Cryptocell variant supported by TF-A is CC-712 which only has support for RSA 2048.

Hi Tamasban,

Hi Tamasban,

multi-image boot support solution is going to be available in review during this week.

$ git push origin master
remote: Not Found
fatal: repository 'http://review.trustedfirmware.org/' not found

git push http://review.trustedfirmware.org
remote: Not Found
fatal: repository 'http://review.trustedfirmware.org/' not found

Another (final) patch:
https://review.trustedfirmware.org/c/trusted-firmware-m/+/1487

Rebase is done and verified

Possible refactoring available here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1460

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

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

The WEAK mechanism sounds OK, but I think not just OS abtraction layer, the TFM NS interface (tfm_ns_lock_dispatch(...), tfm_ns_lock_init()) also needs to be WEAK. For the interrupt-disable scenario, the mutex-like reference implementation cannot apply, and the TFM NS interface may need to implement in a wholly different way.

We have discussed this matter and we would like to propose a solution which might be feasible for you.

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

Thanks, that is helpful. Will let you know after the feature is created.

Product: DS-5 Ultimate Edition 5.29.1
Component: ARM Compiler 6.10.1
Tool: armclang [5d143200]

Hi Kevin,
Can you help to take a look?
-Ken

Hi Qixiang,
Can you help to :

1. provide the version customer are using
2. provide the solution you have created?

Fix for this issue had been merged

So the NS lock in TF-M is a reference implementation. Proprietary implementation may be needed to meet target platform. But per my mbed-os/tf-m port, mbed-os team follows the rule of importing TF-M and not making modification to such as this NS lock implementation for its maintenance. That's one of my dilemma. My biggest dilemma is still how to make secure call in interrupt-disabled context at NS side of mbed-os. The NS lock mechanism with mutex apparently collides with interrupt-disabled context.

Additional change: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1420/

TF-M does not need to be aware of any solution applied on the non-secure side to ensure serialization of secure calls. TF-M does not check the status of the NS lock, what it does is detects concurrent calls to the secure domain using a secure lock that is independent of the NS side implementation.
What we have in the repository for the NS lock is a reference implementation for a generic solution, but use of the non-secure lock is not - and cannot - be enforced by SPM. So if the NS OS you are using in your build exposes the functions you mention, your application is free to call them. It does not need support in the TF-M repository.
The only thing to note is that any proprietary implementation should ensure single entry to the secure domain as any concurrent calls would be flagged up as severe security violations. Any NS policy that avoids this scenario is transparent and acceptable.

One idea for heuristic. With NS secure call run-to-completion, it can run in interrupt-disabled context with mutex removed. For example, disable task switch during NS secure call period:

Related changes:
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1404/
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1405/
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1406/
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1407/

Thanks, hope it will be implemented.