Hi Anton and Chris,
Thank you for your replies.
I have TFM_NS_MANAGE_NSID set to off. That does not prevent client_id translation to happen. `tfm_nspm_get_current_client_id` seems to do translation unconditionally here: https://git.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m.git/.... But as said, setting client_id_limit in code to -1 helps. Maybe there could be additional configuration #define whether to do translation when TFM_NS_MANAGE_NSID is off.
Transition approach to convert the old PS data format to new one on the flash when reading data in new format fails sounds reasonable assuming there's no security problems involved in retrying to read the objects using the old format after a failure. Probably not. It anyways sounds better than supporting the old one "forever". At least to me, being able to do that transition would require a bit of learning what exactly was the old and what is the new layout. If there's some material in addition to source code, I'd be happy to check that.
-Miika
ke 27.11.2024 klo 23.01 Chris.Brand--- via TF-M ( tf-m@lists.trustedfirmware.org) kirjoitti:
Hi Miika,
Unfortunately there have been a couple of changes to the way that PS data is stored in flash. I hope that we are getting better at considering backwards compatibility. In general I think that whenever we do introduce a change like this, we need to ensure that data stored with the old layout can still be read by newer code.
I believe the patch that you’ve identified was part of the work to make PS encryption optional. Looking at it now, I don’t see that the layout was a necessary part of that work. Unfortunately, we’re now in a position where there could be PS data stored on devices in this new format, so just reverting that part of that patch would cause other problems.
The bad news is that there’s another stored format change post-v2.1.1. The good news is that we did think about existing data and introduced a build option to read the old format.
One solution to your problem would be similar to https://github.com/TrustedFirmware-M/trusted-firmware-m/commit/e8d48d78c166c...
- a build option to support reading the old format, with stores then using
the new format. Another option would be to introduce the 1.8.1 format as an alternative implementation i.e. a second struct inside union ps_crypto_t and provide the 1.8.1 code as well as the current code (this would mean picking a storage format at build time and using it forever).
Regarding the client_id. You’re correct that the client_id is used as a kind of access control (the client_id and UID together identify the stored object). Yes, there was a major change to the way that client_ids are used, with the mapping being added. Do you have TFM_NS_MANAGE_NSID set to ON? I believe that if it is set to OFF then -1 is used inside TF-M to represent all non-secure clients, which sounds like it may be what you need.
Chris
Hi Miika,
Interesting. I’m not sure whether that is intentional or not. It may be necessary that multiple NSPEs use distinct client_ids. Regardless, I believe that the intent is that the base and limit for each NSPE is tunable, and you should be fine using a 1:1 mapping.
I’m not aware of anything other than the source and the design documentation at and around https://trustedfirmware-m.readthedocs.io/en/latest/design_docs/services/inde... and https://trustedfirmware-m.readthedocs.io/en/latest/integration_guide/service... feel free to ask questions. A lot of the people who have contributed to PS are still around.
Chris
From: Miika Karanki via TF-M tf-m@lists.trustedfirmware.org Sent: Tuesday, December 3, 2024 2:01 AM To: tf-m@lists.trustedfirmware.org Subject: [TF-M] Re: Backwards compatibility of Protected Storage implementation (TF-M 1.8.1 -> 2.1.1)
Caution: This e-mail originated outside Infineon Technologies. Please be cautious when sharing information or opening attachments especially from unknown senders. Refer to our intranet guidehttps://intranet-content.infineon.com/explore/aboutinfineon/rules/informationsecurity/ug/SocialEngineering/Pages/SocialEngineeringElements_en.aspx to help you identify Phishing email.
Hi Anton and Chris,
Thank you for your replies.
I have TFM_NS_MANAGE_NSID set to off. That does not prevent client_id translation to happen. `tfm_nspm_get_current_client_id` seems to do translation unconditionally here: https://git.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m.git/.... But as said, setting client_id_limit in code to -1 helps. Maybe there could be additional configuration #define whether to do translation when TFM_NS_MANAGE_NSID is off.
Transition approach to convert the old PS data format to new one on the flash when reading data in new format fails sounds reasonable assuming there's no security problems involved in retrying to read the objects using the old format after a failure. Probably not. It anyways sounds better than supporting the old one "forever". At least to me, being able to do that transition would require a bit of learning what exactly was the old and what is the new layout. If there's some material in addition to source code, I'd be happy to check that.
-Miika
ke 27.11.2024 klo 23.01 Chris.Brand--- via TF-M (tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org) kirjoitti: Hi Miika,
Unfortunately there have been a couple of changes to the way that PS data is stored in flash. I hope that we are getting better at considering backwards compatibility. In general I think that whenever we do introduce a change like this, we need to ensure that data stored with the old layout can still be read by newer code.
I believe the patch that you’ve identified was part of the work to make PS encryption optional. Looking at it now, I don’t see that the layout was a necessary part of that work. Unfortunately, we’re now in a position where there could be PS data stored on devices in this new format, so just reverting that part of that patch would cause other problems.
The bad news is that there’s another stored format change post-v2.1.1. The good news is that we did think about existing data and introduced a build option to read the old format.
One solution to your problem would be similar to https://github.com/TrustedFirmware-M/trusted-firmware-m/commit/e8d48d78c166c... - a build option to support reading the old format, with stores then using the new format. Another option would be to introduce the 1.8.1 format as an alternative implementation i.e. a second struct inside union ps_crypto_t and provide the 1.8.1 code as well as the current code (this would mean picking a storage format at build time and using it forever).
Regarding the client_id. You’re correct that the client_id is used as a kind of access control (the client_id and UID together identify the stored object). Yes, there was a major change to the way that client_ids are used, with the mapping being added. Do you have TFM_NS_MANAGE_NSID set to ON? I believe that if it is set to OFF then -1 is used inside TF-M to represent all non-secure clients, which sounds like it may be what you need.
Chris
Hi Miika,
tfm_nspm_get_current_client_id is used to distinguish the Client IDs from different non-secure domains. If you are developing your system with TrustZone, it will map your Non-secure Client IDs into the following range in the TF-M secure world. This mapping is transparent to Non-secure world. #define TZ_NS_CLIENT_ID_BASE (-0x3c00ffff) #define TZ_NS_CLIENT_ID_LIMIT (-0x3c000000) https://github.com/TrustedFirmware-M/trusted-firmware-m/blob/main/secure_fw/...
This range is hard-coded in TrustZone based system. Tbh, I’m not sure if there is an easy way to bypass it in current code base. But it might be helpful to add a config to bypass the mapping if it is unnecessary.
Best regards, David
From: Chris.Brand--- via TF-M tf-m@lists.trustedfirmware.org Sent: Tuesday, December 3, 2024 7:20 PM To: miika.karanki@gmail.com; tf-m@lists.trustedfirmware.org Subject: [TF-M] Re: Backwards compatibility of Protected Storage implementation (TF-M 1.8.1 -> 2.1.1)
Hi Miika,
Interesting. I’m not sure whether that is intentional or not. It may be necessary that multiple NSPEs use distinct client_ids. Regardless, I believe that the intent is that the base and limit for each NSPE is tunable, and you should be fine using a 1:1 mapping.
I’m not aware of anything other than the source and the design documentation at and around https://trustedfirmware-m.readthedocs.io/en/latest/design_docs/services/inde... and https://trustedfirmware-m.readthedocs.io/en/latest/integration_guide/service... feel free to ask questions. A lot of the people who have contributed to PS are still around.
Chris
From: Miika Karanki via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Tuesday, December 3, 2024 2:01 AM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Subject: [TF-M] Re: Backwards compatibility of Protected Storage implementation (TF-M 1.8.1 -> 2.1.1)
Caution: This e-mail originated outside Infineon Technologies. Please be cautious when sharing information or opening attachments especially from unknown senders. Refer to our intranet guidehttps://intranet-content.infineon.com/explore/aboutinfineon/rules/informationsecurity/ug/SocialEngineering/Pages/SocialEngineeringElements_en.aspx to help you identify Phishing email.
Hi Anton and Chris,
Thank you for your replies.
I have TFM_NS_MANAGE_NSID set to off. That does not prevent client_id translation to happen. `tfm_nspm_get_current_client_id` seems to do translation unconditionally here: https://git.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m.git/.... But as said, setting client_id_limit in code to -1 helps. Maybe there could be additional configuration #define whether to do translation when TFM_NS_MANAGE_NSID is off.
Transition approach to convert the old PS data format to new one on the flash when reading data in new format fails sounds reasonable assuming there's no security problems involved in retrying to read the objects using the old format after a failure. Probably not. It anyways sounds better than supporting the old one "forever". At least to me, being able to do that transition would require a bit of learning what exactly was the old and what is the new layout. If there's some material in addition to source code, I'd be happy to check that.
-Miika
ke 27.11.2024 klo 23.01 Chris.Brand--- via TF-M (tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org) kirjoitti: Hi Miika,
Unfortunately there have been a couple of changes to the way that PS data is stored in flash. I hope that we are getting better at considering backwards compatibility. In general I think that whenever we do introduce a change like this, we need to ensure that data stored with the old layout can still be read by newer code.
I believe the patch that you’ve identified was part of the work to make PS encryption optional. Looking at it now, I don’t see that the layout was a necessary part of that work. Unfortunately, we’re now in a position where there could be PS data stored on devices in this new format, so just reverting that part of that patch would cause other problems.
The bad news is that there’s another stored format change post-v2.1.1. The good news is that we did think about existing data and introduced a build option to read the old format.
One solution to your problem would be similar to https://github.com/TrustedFirmware-M/trusted-firmware-m/commit/e8d48d78c166c... - a build option to support reading the old format, with stores then using the new format. Another option would be to introduce the 1.8.1 format as an alternative implementation i.e. a second struct inside union ps_crypto_t and provide the 1.8.1 code as well as the current code (this would mean picking a storage format at build time and using it forever).
Regarding the client_id. You’re correct that the client_id is used as a kind of access control (the client_id and UID together identify the stored object). Yes, there was a major change to the way that client_ids are used, with the mapping being added. Do you have TFM_NS_MANAGE_NSID set to ON? I believe that if it is set to OFF then -1 is used inside TF-M to represent all non-secure clients, which sounds like it may be what you need.
Chris
tf-m@lists.trustedfirmware.org
-
Chris.Brand＠infineon.com -
David Hu -
Miika Karanki