Hi Roman,

I created a patch that I believe fixes the issue you reported below. 
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/27308

Review comments on the are welcome.

Best Regards,
Mate
From: Roman.Mazurak@infineon.com <Roman.Mazurak@infineon.com>
Sent: 11 March 2024 11:38
To: Mate Toth-Pal <Mate.Toth-Pal@arm.com>; tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.org>; Anton Komlev <Anton.Komlev@arm.com>
Cc: Bohdan.Hunko@infineon.com <Bohdan.Hunko@infineon.com>; Chris.Brand@infineon.com <Chris.Brand@infineon.com>; nd <nd@arm.com>
Subject: RE: SPM thread and FLIH
 

Hi Mate,

 

It would be nice if you will provide a fix for this. Probably you have better idea how to integrate it with SPM.

 

I will be able to test it on our platform and provide a feedback.

 

Best Regards,

Roman.

 

From: Mate Toth-Pal <Mate.Toth-Pal@arm.com>
Sent: Monday, February 19, 2024 17:51
To: Mazurak Roman (CSS ICW SW FW 3) <Roman.Mazurak@infineon.com>; tf-m@lists.trustedfirmware.org; Anton Komlev <Anton.Komlev@arm.com>
Cc: Hunko Bohdan (CSS ICW SW FW 3) <Bohdan.Hunko@infineon.com>; Brand Chris (CSS ICW SW) <Chris.Brand@infineon.com>; nd <nd@arm.com>
Subject: Re: SPM thread and FLIH

 

Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe.

 

Hi Roman,

Thank you for reporting this issue.

 

I didn't yet have the time to reproduce the scenario you posted, but looking at the code, here is what I see: 

The function tfm_hal_activate_boundary, that is called by tfm_flih_return_to_isr seems to be restoring the privilege level for the active secure partition, regardless of whether unprivileged partition code, or privileged SPM code was executing when the interrupt became active. 

 

The problem seems that with the current logic SPM considers the CONTROL.nPRIV mechanism to be an independent thing from the mechanism that provides isolation between secure partitions. However, it is not true, as the HAL implementations are using this same CONTROL.nPRIV mechanism to realise isolation.

 

This should probably be fixed in tfm_flih_return_to_isr, setting CONTROL.nPRIV=0 if the interrupted code was privileged. A getter on this could be added to tfm_svcalls.h.

 

As you already seem to have the environment on reproducing the issue/testing a potential fix, would you mind creating a patch for this? If not, I can create it myself.

 

Best Regards,

Mate

 

Hi Roman,

 

Thank you for sharing your findings. Let us check and back with comments.

 

Thanks and best regards,

Anton

 

From: Roman.Mazurak--- via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Friday, February 16, 2024 11:20 AM
To: tf-m@lists.trustedfirmware.org
Cc: Bohdan.Hunko@infineon.com; Chris.Brand@infineon.com
Subject: [TF-M] SPM thread and FLIH

 

Hi all,

 

It seems that on v2.0 there is a problem with FLIH handling during execution of SPM thread.

  1. A partition #1 is running with unprivileged attribute (CONTROL.nPRIV = 1).
  2. It requests PSA API (for example psa_call).
  3. psa_call is serviced via SVC. prepare_to_thread_mode_spm schedules handling of psa_call in SPM thread mode (by prepare_to_thread_mode_spm).
  4. prepare_to_thread_mode_spm saves CONTROL to saved_control. Than set CONTROL.nPRIV = 0 (privileged for SPM thread).
  5. Exit from SVC starts execution of tfm_spm_client_psa_call in SPM thread (privileged).
  6. SPM thread is interrupted by FLIH IRQ.
  7. FLIH IRQ handler calls spm_handle_interrupt.
  8. spm_handle_interrupt switches boundary to prepare environment for FLIH handler (partition #2) and schedules execution of FLIH handler.
  9. FLIH handler is executed.
  10. tfm_flih_return_to_isr is called on exit from FLIH handler. It restores boundary of partition #1 and set CONTROL.nPRIV = 1. Than returns to FLIH IRQ handler.
  11. FLIH IRQ handler exit to SPM thread that has been interrupted on step #6.
  12. SPM thread have no enough permissions, because it’s running with CONTROL.nPRIV equal to 1 (unprivileged). So, processing environment is unprivileged and tfm_spm_client_psa_call fails on accessing restricted resource.

 

Does my understanding correct? If yes it means that we should fix exit from FLIH to SPM thread.

 

Regards,

Roman.