Hi Bohan,

Yes, you are right - the code here needs to be changed. The privileged/unprivileged is the practical hardware concept which should be abstracted for SPM.

This abstraction needs to be thoughtful, but if you are going to put PRoT partitions under an unprivileged level and assign boundaries to them, the code here won't block your work and we can abstract this later.

This is basically checking if SPM has no boundaries between special partitions, hence needs to assign a boundary value for SPM. A rough idea can be: We can change the static boundary set up HAL and make it return a handle for being treated as SPM handle, then we can decide if we need a deprivileged branching by comparing the boundaries.

If you got other ideas please feel free to contribute, thanks.

/Ken ________________________________ From: Bohdan.Hunko@infineon.com Bohdan.Hunko@infineon.com Sent: Friday, September 30, 2022 6:09 AM To: Ken Liu Ken.Liu@arm.com; tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: RE: Level 3 Isolation improvements

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

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.commailto: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 safehttps://intranet-content.infineon.com/explore/aboutinfineon/rules/informationsecurity/ug/SocialEngineering/Pages/SocialEngineeringElements_en.aspx.

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.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Thursday, September 29, 2022 4:59 AM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: Hennadiy.Kytsun@infineon.commailto: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:

* In L3 PSA RoT partitions does not need to be isolated from SPM (and vice versa) * PSA RoT partitions does not need to be isolated from each other * PSA RoT partitions and SPM must be isolated from APP RoT partitions * APP RoT partitions must be isolated from each other

This picture from TFM docshttps://tf-m-user-guide.trustedfirmware.org/docs/technical_references/design_docs/secure_partition_manager.html#components-and-isolation-levels 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 herehttps://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/spm/ffm/backend_ipc.c#n276) and this an521 codehttps://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/ext/target/arm/mps2/an521/tfm_hal_isolation.c#n520 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:

* isolate SPM from PSA RoT partitions * isolate PSA RoT partitions from each other (like APP RoT partitions are isolated)

1. If question 1 make sense then can platform achieve this improved isolation with current code base? From this an521 codehttps://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/ext/target/arm/mps2/an521/tfm_hal_isolation.c#n520 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 needhttps://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/spm/ffm/interrupt.c#n157 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.commailto:Bohdan.Hunko@infineon.com

Hi Bohdan,

I have raised the priority and it is likely to finish it in October if no surprises.

/Ken

From: Bohdan.Hunko@infineon.com Bohdan.Hunko@infineon.com Sent: Monday, October 3, 2022 6:58 PM To: Ken Liu Ken.Liu@arm.com; tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: RE: Level 3 Isolation improvements

Hi Ken,

You are right - we are not blocked by this problem, but we need to ensure that this fix will be present in 1.7 release.

Could you please schedule this work and update me on approximate fix date?

Regards, Bohdan Hunko

Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko@infineon.commailto:Bohdan.Hunko@infineon.com

From: Ken Liu <Ken.Liu@arm.commailto:Ken.Liu@arm.com> Sent: Friday, 30 September 2022 04:39 To: Hunko Bohdan (CSUKR CSS ICW SW FW 3) <Bohdan.Hunko@infineon.commailto:Bohdan.Hunko@infineon.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto:nd@arm.com> Subject: 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 safehttps://intranet-content.infineon.com/explore/aboutinfineon/rules/informationsecurity/ug/SocialEngineering/Pages/SocialEngineeringElements_en.aspx.

Hi Bohan,

Yes, you are right - the code here needs to be changed. The privileged/unprivileged is the practical hardware concept which should be abstracted for SPM.

This abstraction needs to be thoughtful, but if you are going to put PRoT partitions under an unprivileged level and assign boundaries to them, the code here won't block your work and we can abstract this later.

This is basically checking if SPM has no boundaries between special partitions, hence needs to assign a boundary value for SPM. A rough idea can be: We can change the static boundary set up HAL and make it return a handle for being treated as SPM handle, then we can decide if we need a deprivileged branching by comparing the boundaries.

If you got other ideas please feel free to contribute, thanks.

/Ken ________________________________ From: Bohdan.Hunko@infineon.commailto:Bohdan.Hunko@infineon.com <Bohdan.Hunko@infineon.commailto:Bohdan.Hunko@infineon.com> Sent: Friday, September 30, 2022 6:09 AM To: Ken Liu <Ken.Liu@arm.commailto:Ken.Liu@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd@arm.commailto:nd@arm.com> Subject: RE: Level 3 Isolation improvements

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

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.commailto:Bohdan.Hunko@infineon.com

From: Ken Liu via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Thursday, 29 September 2022 04:15 To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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 safehttps://intranet-content.infineon.com/explore/aboutinfineon/rules/informationsecurity/ug/SocialEngineering/Pages/SocialEngineeringElements_en.aspx.

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.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Thursday, September 29, 2022 4:59 AM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: Hennadiy.Kytsun@infineon.commailto: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:

* In L3 PSA RoT partitions does not need to be isolated from SPM (and vice versa) * PSA RoT partitions does not need to be isolated from each other * PSA RoT partitions and SPM must be isolated from APP RoT partitions * APP RoT partitions must be isolated from each other

This picture from TFM docshttps://tf-m-user-guide.trustedfirmware.org/docs/technical_references/design_docs/secure_partition_manager.html#components-and-isolation-levels 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 herehttps://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/spm/ffm/backend_ipc.c#n276) and this an521 codehttps://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/ext/target/arm/mps2/an521/tfm_hal_isolation.c#n520 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:

* isolate SPM from PSA RoT partitions * isolate PSA RoT partitions from each other (like APP RoT partitions are isolated)

1. If question 1 make sense then can platform achieve this improved isolation with current code base? From this an521 codehttps://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/ext/target/arm/mps2/an521/tfm_hal_isolation.c#n520 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 needhttps://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/spm/ffm/interrupt.c#n157 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.commailto:Bohdan.Hunko@infineon.com