Hi Ken,

 

Thanks for the quick reply.

 

Indeed I can see that most of the platform independent code allows to have this improved isolation, but there is this code (https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/spm/ffm/interrupt.c#n157 )

Here is snippet

        if (GET_PARTITION_PRIVILEGED_MODE(p_part->p_ldinf) ==

                                                TFM_PARTITION_PRIVILEGED_MODE) {

            flih_result = p_ildi->flih_func();

        } else {

            flih_result = tfm_flih_deprivileged_handling(

                                                p_part,

                                                (uintptr_t)p_ildi->flih_func,

                                                GET_CURRENT_COMPONENT());

        }

 

GET_PARTITION_PRIVILEGED_MODE macro determines partition privilege level by checking whether partition is PSA RoT (PSA RoT == privileged; APP RoT == unprivilaged).

tfm_flih_deprivileged_handling internally calls tfm_hal_activate_boundary .

This means that tfm_hal_activate_boundary will not be called for PSA RoT partitions because tfm_flih_deprivileged_handling is not called for PSA RoT partitions.

 

If I am right then this code will have to be changed.

Am I correct or I am missing something?

 

 

Other than that I don’t see any problems with implementing improved isolation in a way I have described it in my last email.

 

 

Bohdan Hunko

 

Cypress Semiconductor Ukraine

Engineer

CSUKR CSS ICW SW FW

Mobile: +38099 50 19 714
Bohdan.Hunko@infineon.com

 

From: Ken Liu via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Thursday, 29 September 2022 04:15
To: tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: [TF-M] Re: Level 3 Isolation improvements

 

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

 

Hi Bohdan,

 

FF-M proposes a balanced design to leave flexibility for those platforms that lack hardware resources or have concerns about performance. It is a plus if one platform can improve the isolation.

 

TF-M showcases the specification proposal mainly, and leaves the flexibility in the HAL API to give the platform that wants to improve the isolation a chance to do it in an easier way.

 

Yes, your findings are correct, SPM switches the boundaries when the boundary handle is different – so if you assign unique handles to PRoT partitions, the boundary is switched. What you need to do is changing the implementation of isolation boundary HAL implementation, no need to change the SPM code.

 

BR.

 

/Ken

 

From: Bohdan.Hunko--- via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Thursday, September 29, 2022 4:59 AM
To: tf-m@lists.trustedfirmware.org
Cc: Hennadiy.Kytsun@infineon.com
Subject: [TF-M] Level 3 Isolation improvements

 

Hi everyone,

 

I have several questions related to L3 isolation in TFM.

 

First of all, FFM specifies that:

This picture from TFM docs seem to illustrate statements above.

 

Currently platforms with L3 support (e.g. an521) follow the rules stated above.

They achieve this by executing PSA RoT partitions and SPM in privileged mode, and APP RoT partitions in unprivileged mode. Partition boundaries are only updated when switching to APP RoT partition.

From description of tfm_hal_activate_boundary (see code here) and this an521 code seems like platform can determine whether partition will be executed in privileged or unprivileged mode.

 

So my questions are:

  1. For improved isolation in L3 does it make sense to:
  1. If question 1 make sense then can platform achieve this improved isolation with current code base?
    From this an521 code it seems like platform may set all partitions to be executed in unprivileged mode and dynamically switch boundaries between them (between both PSA and APP RoT partitions). SPM will remain in privileged mode.
    It seems like this approach is possible with minor changes to SPM. For example this code will need to be changed to call tfm_hal_activate_boundary regardless of partition privilege level.
    Are there any other changes needed to make this approach work?

 

Regards,

 

Bohdan Hunko

 

Cypress Semiconductor Ukraine

Engineer

CSUKR CSS ICW SW FW

Mobile: +38099 50 19 714
Bohdan.Hunko@infineon.com