Page MenuHomePhabricator
Create Task
Maniphest T950

NS interrupt masking prevents from executing PSA calls
Open, HighPublic
Actions

Description

I am integrating the latest version of upstream TF-M with Zephyr.
It seems that when Zephyr locks IRQs (using BASEPRI_NS) psa_calls do not function properly. In particular, psa_connect returns an invalid (zero) handle, while psa_call() also seems to hang.

To reproduce:
It seems as simple as setting BASEPRI to 32, in the non-secure world. Higher values of BASEPRI allows the psa connect calls to function properly.

This is strange because, to the best of my knowledge, TFM is setting AIRCR.PRIS=1 to de-prioritize non-secure interrupts, so setting NS BASEPRI to 32 should not mask any secure IRQs.

Calling PSA API with IRQs locked was working with earlier versions of TF-M, so perhaps this has something to do with TFM features merged lately, e.g. the FLIH feature.
Assigning Kevin to take a look.

If, indeed, it should not be possible for PSA calls to proceed with NS IRQs being locked, this deserves a documentation edit, IMHO.

Related Objects

Event Timeline

ioannisg triaged this task as High priority.Jul 16 2021, 11:53 AM
ioannisg created this task.
ioannisg updated the task description. (Show Details)
ioannisg updated the task description. (Show Details)Jul 16 2021, 12:06 PM
kevin-peng-hao added a comment.Jul 28 2021, 1:05 PM

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.

ioannisg added a comment.Jul 28 2021, 1:42 PM

Hi Kevin.

The service does not really matter. I checked PS and platform (system reset) services; both throw an error, so I suppose this issue is not service-specific.

IRQs in Zephyr are locked by setting BASEPRI to a non-zero value. In particular for Cortex-M33, BASEPRI is set to 32 to lock IRQs (i.e. the IRQs with priority level 0 are still unmasked).

This link contains all the info you need (e.g. TFM SHA I am updating to): https://github.com/zephyrproject-rtos/zephyr/pull/36954

Basically we have a list of TF-M integration samples. Search for "tfm_ipc" sample under: samples/tfm_integration.
Configuration: nothing particular really; default TF-M builds with PSA API.

KenLSoft added a subscriber: KenLSoft.Jul 29 2021, 4:13 AM

It looks like a:

(32 / 2 + 0x80) VS (0x256 - 1) issue.

Does this patch matter:
91d9f7403cb476539b74cc06de82483977daf3a0

kevin-peng-hao added a comment.Jul 29 2021, 6:08 AM

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

I'm not seeing any hangs or errors, the FLIH tests (TFM_FLIH_TEST=ON) are passing as well.

Hi @ioannisg
Do you have any secure IRQs enabled in your case? Or are you just running the TF-M tests?

You might also try to revert the change mentioned by Ken.

ioannisg added a comment.Jul 30 2021, 10:43 AM

i will try to revert the patch that is mentioned above and report here.

kevin-peng-hao added a comment.Sep 18 2021, 6:53 AM

Hi ioannisg,

I think your issue might be the same as:
https://developer.trustedfirmware.org/T966

Have you tried to revert that patch (91d9f7403cb476539b74cc06de82483977daf3a0) to see this issue is gone?