Hi everyone,
TFM manifest files allow to specify priority for the partition. FFM 1.0 and FFM 1.1 specify that there are 3 possible values for this field: Low, NORMAL, HIGH.
This field is used in several template files to generate needed for SPM information. From what I see there are several problems with current implementation:
1. In secure_fw/spm/cmsis_func/tfm_spm_db_func.inc.template priority field is used to generate .partition_priority filed of spm_partition_static_data_t structure. It uses TFM_PRIORITY() macro to convert priority to numeric value. The problem is that this field is actually never used, instead all priority checking is done using .flags field of partition_{{manifest.name|lower}}_load_info_t structure (tools/templates/partition_load_info.template file).
2. .flags field uses PARTITION_PRI_ macro to convert priority to numeric value. Possible values for TFM_PRIORITY() are: LOW, NORMAL, HIGH, but PARTITION_PRI_ macro has: LOWES, LOW, NORMAL, HIGH, HIGHEST priorities. More over priorities with same names for these 2 macros have different numeric values (e.g. PARTITION_PRI_LOW is 0x7F while TFM_PRIORITY_LOW is 0xFF)
3. Scatter files does not account for HIGHEST priority (see code herehttps://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/ext/common/armclang/tfm_isolation_l3.sct.template#n74). This is a problem for all toolchains including both common scatter files (L1 and L2) and scatter files templates for L3
So I have several questions on this topic:
1. Are LOWEST and HIGHEST priorities system reserved? Because for now they cant be used in manifest files as TFM_PRIORITY() does not have support them.
2. Should TFM_PRIORITY() macro and .partition_priority filed of spm_partition_static_data_t structure be removed? This will mean that if LOWEST and HIGHEST priorities are system reserved then validation of value for "priority" manifest field should be added to tfm_parse_manifest_list.py
3. Should scatter files be fixed to account for HIGHEST priority?
4. secure_fw/partitions/ns_agent_tz/load_info_ns_agent_tz.c for NS agent TZ specifies (PARTITION_PRI_LOWEST - 1) for a .flags filed. Higher priority numeric values is lower real priority, which means that TZ NS agent partition priority is between LOW and LOWEST priority. This seems like a hack to me, maybe we should introduce One more named priority?
5. In secure_fw/partitions/CMakeLists.txt idle partition is included when IPC backend is used. Idle partition is used to retrigger scheduling before going into WFI state (just to be sure that higher priority partitions were executed and there is not pending request). I can see how this partition is useful for MULTICORE case, to have kind of sleep state. But for TZ case TZ ns agent is always RUNNABLE and have higher priority that IDLE partition so it does not look like IDLE partition will ever be scheduled in TZ case. In such case condition in this Cmake file should be changed from "if (CONFIG_TFM_SPM_BACKEND_IPC)" to "if (TFM_PARTITION_NS_AGENT_MAILBOX)" Am I wrong somewhere?
Sorry, I know that is a lot of questions, but this scheduling stuff is really hard to wrap a head around.
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,
See my inline answers below.
Best Regards, Kevin
From: Bohdan.Hunko--- via TF-M tf-m@lists.trustedfirmware.org Sent: Saturday, July 9, 2022 5:45 AM To: tf-m@lists.trustedfirmware.org Cc: Chris.Brand@infineon.com Subject: [TF-M] Partition priority questions
Hi everyone,
TFM manifest files allow to specify priority for the partition. FFM 1.0 and FFM 1.1 specify that there are 3 possible values for this field: Low, NORMAL, HIGH.
This field is used in several template files to generate needed for SPM information. From what I see there are several problems with current implementation:
1. In secure_fw/spm/cmsis_func/tfm_spm_db_func.inc.template priority field is used to generate .partition_priority filed of spm_partition_static_data_t structure. It uses TFM_PRIORITY() macro to convert priority to numeric value. The problem is that this field is actually never used, instead all priority checking is done using .flags field of partition_{{manifest.name|lower}}_load_info_t structure (tools/templates/partition_load_info.template file).
2. .flags field uses PARTITION_PRI_ macro to convert priority to numeric value. Possible values for TFM_PRIORITY() are: LOW, NORMAL, HIGH, but PARTITION_PRI_ macro has: LOWES, LOW, NORMAL, HIGH, HIGHEST priorities. More over priorities with same names for these 2 macros have different numeric values (e.g. PARTITION_PRI_LOW is 0x7F while TFM_PRIORITY_LOW is 0xFF)
3. Scatter files does not account for HIGHEST priority (see code herehttps://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/ext/common/armclang/tfm_isolation_l3.sct.template#n74). This is a problem for all toolchains including both common scatter files (L1 and L2) and scatter files templates for L3
So I have several questions on this topic:
1. Are LOWEST and HIGHEST priorities system reserved? Because for now they cant be used in manifest files as TFM_PRIORITY() does not have support them. [KP] Yes, they are.
2. Should TFM_PRIORITY() macro and .partition_priority filed of spm_partition_static_data_t structure be removed? This will mean that if LOWEST and HIGHEST priorities are system reserved then validation of value for "priority" manifest field should be added to tfm_parse_manifest_list.py [KP] The partition_priority should be removed if it is not used. Please be noted that secure_fw/spm/cmsis_func is the Library mode which does not have scheduler so priorities does not seem to make sense to it. Must be some historical reasons that they are left there. Validation of values of "priority" should be added.
3. Should scatter files be fixed to account for HIGHEST priority? [KP] I believe they should be.
4. secure_fw/partitions/ns_agent_tz/load_info_ns_agent_tz.c for NS agent TZ specifies (PARTITION_PRI_LOWEST - 1) for a .flags filed. Higher priority numeric values is lower real priority, which means that TZ NS agent partition priority is between LOW and LOWEST priority. This seems like a hack to me, maybe we should introduce One more named priority? [KP] The -1 is to make NS Agent have higher priority than the IDLE partition which has the LOWERT priority. The idle Partitions is an intermediate solution and finally should be combined into the NS Agents. So we don't have the plan to introduce any more priorities.
5. In secure_fw/partitions/CMakeLists.txt idle partition is included when IPC backend is used. Idle partition is used to retrigger scheduling before going into WFI state (just to be sure that higher priority partitions were executed and there is not pending request). I can see how this partition is useful for MULTICORE case, to have kind of sleep state. But for TZ case TZ ns agent is always RUNNABLE and have higher priority that IDLE partition so it does not look like IDLE partition will ever be scheduled in TZ case. In such case condition in this Cmake file should be changed from "if (CONFIG_TFM_SPM_BACKEND_IPC)" to "if (TFM_PARTITION_NS_AGENT_MAILBOX)" Am I wrong somewhere? [KP] The TZ NS Agent is *NOT* always RUNNABLE. It becomes BLOCKED when it requests any RoT Services (on behalf of the NSPE). When there is the case that the requested RoT Service waits for an interrupt, the IDLE Partition becomes the only RUNNABLE Secure Partition.
Sorry, I know that is a lot of questions, but this scheduling stuff is really hard to wrap a head around.
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 Kevin,
Thank you for the answers. I will create a patch and push it to review this week. I will notify you in this mailing thread once it is ready to be reviewed.
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: Kevin Peng Kevin.Peng@arm.com Sent: Monday, 11 July 2022 05:40 To: Hunko Bohdan (CSUKR CSS ICW SW FW 3) Bohdan.Hunko@infineon.com; tf-m@lists.trustedfirmware.org Cc: Brand Chris (CSCA CSS ICW SW PSW 1) Chris.Brand@infineon.com Subject: RE: Partition priority questions
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,
See my inline answers below.
Best Regards, Kevin
From: Bohdan.Hunko--- via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Saturday, July 9, 2022 5:45 AM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: Chris.Brand@infineon.commailto:Chris.Brand@infineon.com Subject: [TF-M] Partition priority questions
Hi everyone,
TFM manifest files allow to specify priority for the partition. FFM 1.0 and FFM 1.1 specify that there are 3 possible values for this field: Low, NORMAL, HIGH.
This field is used in several template files to generate needed for SPM information. From what I see there are several problems with current implementation:
1. In secure_fw/spm/cmsis_func/tfm_spm_db_func.inc.template priority field is used to generate .partition_priority filed of spm_partition_static_data_t structure. It uses TFM_PRIORITY() macro to convert priority to numeric value. The problem is that this field is actually never used, instead all priority checking is done using .flags field of partition_{{manifest.name|lower}}_load_info_t structure (tools/templates/partition_load_info.template file).
2. .flags field uses PARTITION_PRI_ macro to convert priority to numeric value. Possible values for TFM_PRIORITY() are: LOW, NORMAL, HIGH, but PARTITION_PRI_ macro has: LOWES, LOW, NORMAL, HIGH, HIGHEST priorities. More over priorities with same names for these 2 macros have different numeric values (e.g. PARTITION_PRI_LOW is 0x7F while TFM_PRIORITY_LOW is 0xFF)
3. Scatter files does not account for HIGHEST priority (see code herehttps://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/ext/common/armclang/tfm_isolation_l3.sct.template#n74). This is a problem for all toolchains including both common scatter files (L1 and L2) and scatter files templates for L3
So I have several questions on this topic:
1. Are LOWEST and HIGHEST priorities system reserved? Because for now they cant be used in manifest files as TFM_PRIORITY() does not have support them. [KP] Yes, they are.
2. Should TFM_PRIORITY() macro and .partition_priority filed of spm_partition_static_data_t structure be removed? This will mean that if LOWEST and HIGHEST priorities are system reserved then validation of value for "priority" manifest field should be added to tfm_parse_manifest_list.py [KP] The partition_priority should be removed if it is not used. Please be noted that secure_fw/spm/cmsis_func is the Library mode which does not have scheduler so priorities does not seem to make sense to it. Must be some historical reasons that they are left there. Validation of values of "priority" should be added.
3. Should scatter files be fixed to account for HIGHEST priority? [KP] I believe they should be.
4. secure_fw/partitions/ns_agent_tz/load_info_ns_agent_tz.c for NS agent TZ specifies (PARTITION_PRI_LOWEST - 1) for a .flags filed. Higher priority numeric values is lower real priority, which means that TZ NS agent partition priority is between LOW and LOWEST priority. This seems like a hack to me, maybe we should introduce One more named priority? [KP] The -1 is to make NS Agent have higher priority than the IDLE partition which has the LOWERT priority. The idle Partitions is an intermediate solution and finally should be combined into the NS Agents. So we don't have the plan to introduce any more priorities.
5. In secure_fw/partitions/CMakeLists.txt idle partition is included when IPC backend is used. Idle partition is used to retrigger scheduling before going into WFI state (just to be sure that higher priority partitions were executed and there is not pending request). I can see how this partition is useful for MULTICORE case, to have kind of sleep state. But for TZ case TZ ns agent is always RUNNABLE and have higher priority that IDLE partition so it does not look like IDLE partition will ever be scheduled in TZ case. In such case condition in this Cmake file should be changed from "if (CONFIG_TFM_SPM_BACKEND_IPC)" to "if (TFM_PARTITION_NS_AGENT_MAILBOX)" Am I wrong somewhere? [KP] The TZ NS Agent is *NOT* always RUNNABLE. It becomes BLOCKED when it requests any RoT Services (on behalf of the NSPE). When there is the case that the requested RoT Service waits for an interrupt, the IDLE Partition becomes the only RUNNABLE Secure Partition.
Sorry, I know that is a lot of questions, but this scheduling stuff is really hard to wrap a head around.
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
tf-m@lists.trustedfirmware.org
-
Bohdan.Hunko＠infineon.com -
Kevin Peng