Looking at the declaration and body of this function, the first parameter is clearly a partition index (index into g_spm_partition_db.partitions[]), and all the call sites in secure_fw/spm/cmsis_func/spm_func.c use it that way. The three call sites in secure_fw/spm/cmsis_func/main.c, though, all pass a PID instead. This happens to work because g_spm_partition_db.partitions[0].static_data->partition_id == 0 and g_spm_partition_db.partitions[1].static_data->partition_id == 1. I don't see anything that guarantees that that will always be true, though.
There is a static function get_partition_id() in secure_fw/spm/cmsis_func/spm_func.c that maps from PID to partition index - should that be exported and called to address this?
Thanks,
Chris Brand
.
I pushed a patch to address this at https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15438
Chris
From: Chris.Brand--- via TF-M tf-m@lists.trustedfirmware.org Sent: June 8, 2022 2:17 PM To: tf-m@lists.trustedfirmware.org Subject: [TF-M] Mis-use of tfm_spm_partition_set_state()
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.
Looking at the declaration and body of this function, the first parameter is clearly a partition index (index into g_spm_partition_db.partitions[]), and all the call sites in secure_fw/spm/cmsis_func/spm_func.c use it that way. The three call sites in secure_fw/spm/cmsis_func/main.c, though, all pass a PID instead. This happens to work because g_spm_partition_db.partitions[0].static_data->partition_id == 0 and g_spm_partition_db.partitions[1].static_data->partition_id == 1. I don't see anything that guarantees that that will always be true, though.
There is a static function get_partition_id() in secure_fw/spm/cmsis_func/spm_func.c that maps from PID to partition index - should that be exported and called to address this?
Thanks,
Chris Brand
.
Thanks to Chris for the fix. The fix has been merged.
Best regards, Hu Ziji
From: Chris.Brand--- via TF-M tf-m@lists.trustedfirmware.org Sent: Thursday, June 9, 2022 5:40 AM To: tf-m@lists.trustedfirmware.org Subject: [TF-M] Re: Mis-use of tfm_spm_partition_set_state()
I pushed a patch to address this at https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15438
Chris
From: Chris.Brand--- via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: June 8, 2022 2:17 PM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Subject: [TF-M] Mis-use of tfm_spm_partition_set_state()
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.
Looking at the declaration and body of this function, the first parameter is clearly a partition index (index into g_spm_partition_db.partitions[]), and all the call sites in secure_fw/spm/cmsis_func/spm_func.c use it that way. The three call sites in secure_fw/spm/cmsis_func/main.c, though, all pass a PID instead. This happens to work because g_spm_partition_db.partitions[0].static_data->partition_id == 0 and g_spm_partition_db.partitions[1].static_data->partition_id == 1. I don't see anything that guarantees that that will always be true, though.
There is a static function get_partition_id() in secure_fw/spm/cmsis_func/spm_func.c that maps from PID to partition index - should that be exported and called to address this?
Thanks,
Chris Brand
.
tf-m@lists.trustedfirmware.org
-
Chris.Brand＠infineon.com -
David Hu