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
.