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/

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

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

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 related to this task:

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/+/1513/
4. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1514/
5. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1515/
6. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1516/
7. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1517/
8. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1518/
9. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1519/
10. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1520/
11. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1521/
12. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1522/
13. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1523/
14. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1524/
15. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1525/
16. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1526/

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

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

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

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.

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

For the design proposal published to the TSC please refer to the archive of the TSC mailing-list: https://lists.trustedfirmware.org/mailman/listinfo/tsc .

patches:
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1024/
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1025/

Patch for this issue: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1409

Change for this ticket: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1389

Patch for this task: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1369

patch link:
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1379/
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1380/
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1381/
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1382/

Patch for this: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1373

Related change:
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1237/

Related change:
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1238/

Hi Thomas,

change for this task: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1363/

Change https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1180/ for this issue have been merged.

Patch link:
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1352/
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1353/
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1354/
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1355/
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1356/

Change associated to this is here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1260

Hi Thomas, I see you mention a failure with GNUARM 7.3.1 with some build config. Can you please provide instructions on how to reproduce the build failure? As you say the failure happens with the mainline as well, that shouldn't happen and I am not seeing the failure either. Would like to try to reproduce it here if it's a genuine issue.

Related change:
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1256/

Further patch for this after document migration
https://review.trustedfirmware.org/c/trusted-firmware-m/+/1249/

Further patch for this after document migration
https://review.trustedfirmware.org/c/trusted-firmware-m/+/1248

Patches link about change the context of the manifest file to align with PSA:
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1240/
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1241/
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1242/
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1243/
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1244/
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1245/
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1246/
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1247/

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

The secure partition init function cannot cover all use cases. The requirement of pre-rtos secure call actually comes from my mbed-os/tf-m port on Nuvoton's M2351 chip. For example, on mbed-os, the CMSIS API SystemCoreClockUpdate(...) is called to update SystemCoreClock in pre-rtos stage on NS side. On Nuvoton's M2351, SystemCoreClockUpdate(...)'s implementation needs to access CLK space registers which are hardwired to secure. That's where secure call in pre-rtos stage is necessary. I've also checked SystemCoreClockUpdate(...)'s implementation on Arm's Musca A1. It has SystemCoreClock fixed in macro, and so it needn't.

I don't really know the full context of this, so maybe I am way off here, but if there is some secure code that needs to be executed before the NS RTOS is started, is it not best executed as part of secure init? The secure partition containing the secure function (the one that must be called before the RTOS is started) will have an init function, so could that be used to execute the required code?

Pushed the changes: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1233

In T376#4490, @ccli8 wrote:

This call involves a Thread -> Handler mode request on every service call to check if we are in pre-RTOS stage. I think this will introduce a non-negligible penalty; in most of the cases, we expect this call to happen when the RTOS has been loaded.

For the osKernelGetState() overhead in tfm_ns_lock_dispatch(...), I think it can be replaced by just checking ns_lock.init.

This call involves a Thread -> Handler mode request on every service call to check if we are in pre-RTOS stage. I think this will introduce a non-negligible penalty; in most of the cases, we expect this call to happen when the RTOS has been loaded.

Upstream change 1231 to support secure call in pre-rtos stage in tfm_ns_lock_dispatch(...). I think some audience would benefit from it. Without it, I need to make an extra check for pre-rtos scenario before making a secure call.