Hi all,
I found that using FIH medium/high profile with gcc generates code that uses stack extensively. It happens because fih_int structure is marked as volatile. Is there any reason why structure itself is marked as volatile? Why it's not enough to make val and msk volatile members of fih_int structure?
Best regards, Roman.
Hey Roman
That is interesting - I was under the impression that having the structure marked as volatile was semantically the same as having all of its member volatile. Do you notice a considerable stack usage change with this fix?
I think if you do notice one, we'd be happy to have that change upstream. There's always some performance/size penalty to the FIH code but we should definitely try to minimize it if we can.
Raef
________________________________________ From: Roman.Mazurak--- via TF-M tf-m@lists.trustedfirmware.org Sent: 08 December 2023 19:58 To: tf-m@lists.trustedfirmware.org Subject: [TF-M] FIH volatile structure and stack usage
Hi all,
I found that using FIH medium/high profile with gcc generates code that uses stack extensively. It happens because fih_int structure is marked as volatile. Is there any reason why structure itself is marked as volatile? Why it’s not enough to make val and msk volatile members of fih_int structure?
Best regards, Roman.
Hi Raef,
It's look like GCC create a separate instance for each fih_int variable and keep it even out of scope of visibility. So, each FIH_CALL produces own set of variables in function stack even for a release build.
That is interesting - I was under the impression that having the structure marked as volatile was semantically the same as having all of its member volatile. Do you notice a considerable stack usage change with this fix?
For example there is difference about 500 bytes for tfm_hal_set_up_static_boundaries in our platform.
Best regards,
Roman.
-----Original Message-----
From: Raef Coles Raef.Coles@arm.com
Sent: Monday, December 11, 2023 11:09
To: tf-m@lists.trustedfirmware.org; Mazurak Roman (CSS ICW SW FW 3) Roman.Mazurak@infineon.com
Subject: Re: FIH volatile structure and stack usage
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.
Hey Roman
That is interesting - I was under the impression that having the structure marked as volatile was semantically the same as having all of its member volatile. Do you notice a considerable stack usage change with this fix?
I think if you do notice one, we'd be happy to have that change upstream. There's always some performance/size penalty to the FIH code but we should definitely try to minimize it if we can.
Raef
________________________________________
From: Roman.Mazurak--- via TF-M tf-m@lists.trustedfirmware.org
Sent: 08 December 2023 19:58
To: tf-m@lists.trustedfirmware.org
Subject: [TF-M] FIH volatile structure and stack usage
Hi all,
I found that using FIH medium/high profile with gcc generates code that uses stack extensively. It happens because fih_int structure is marked as volatile.
Is there any reason why structure itself is marked as volatile? Why it's not enough to make val and msk volatile members of fih_int structure?
Best regards,
Roman.
Ah that sounds like a huge difference, and a welcome optimization - If you can push a patch for review I'd be happy to take a look at it.
Raef
________________________________________ From: Roman.Mazurak@infineon.com Roman.Mazurak@infineon.com Sent: 11 December 2023 13:20 To: Raef Coles; tf-m@lists.trustedfirmware.org Subject: RE: FIH volatile structure and stack usage
Hi Raef,
It's look like GCC create a separate instance for each fih_int variable and keep it even out of scope of visibility. So, each FIH_CALL produces own set of variables in function stack even for a release build.
That is interesting - I was under the impression that having the structure marked as volatile was semantically the same as having all of its member volatile. Do you notice a considerable stack usage change with this fix?
For example there is difference about 500 bytes for tfm_hal_set_up_static_boundaries in our platform.
Best regards,
Roman.
-----Original Message-----
From: Raef Coles Raef.Coles@arm.com
Sent: Monday, December 11, 2023 11:09
To: tf-m@lists.trustedfirmware.org; Mazurak Roman (CSS ICW SW FW 3) Roman.Mazurak@infineon.com
Subject: Re: FIH volatile structure and stack usage
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.
Hey Roman
That is interesting - I was under the impression that having the structure marked as volatile was semantically the same as having all of its member volatile. Do you notice a considerable stack usage change with this fix?
I think if you do notice one, we'd be happy to have that change upstream. There's always some performance/size penalty to the FIH code but we should definitely try to minimize it if we can.
Raef
________________________________________
From: Roman.Mazurak--- via TF-M tf-m@lists.trustedfirmware.org
Sent: 08 December 2023 19:58
To: tf-m@lists.trustedfirmware.org
Subject: [TF-M] FIH volatile structure and stack usage
Hi all,
I found that using FIH medium/high profile with gcc generates code that uses stack extensively. It happens because fih_int structure is marked as volatile.
Is there any reason why structure itself is marked as volatile? Why it’s not enough to make val and msk volatile members of fih_int structure?
Best regards,
Roman.
Hi Raef,
There is the patch that removes volatile attribute. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/25443
Best regards, Roman.
-----Original Message----- From: Raef Coles Raef.Coles@arm.com Sent: Tuesday, December 12, 2023 14:03 To: Mazurak Roman (CSS ICW SW FW 3) Roman.Mazurak@infineon.com; tf-m@lists.trustedfirmware.org Subject: Re: FIH volatile structure and stack usage
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.
Ah that sounds like a huge difference, and a welcome optimization - If you can push a patch for review I'd be happy to take a look at it.
Raef
________________________________________ From: Roman.Mazurak@infineon.com Roman.Mazurak@infineon.com Sent: 11 December 2023 13:20 To: Raef Coles; tf-m@lists.trustedfirmware.org Subject: RE: FIH volatile structure and stack usage
Hi Raef,
It's look like GCC create a separate instance for each fih_int variable and keep it even out of scope of visibility. So, each FIH_CALL produces own set of variables in function stack even for a release build.
That is interesting - I was under the impression that having the structure marked as volatile was semantically the same as having all of its member volatile. Do you notice a considerable stack usage change with this fix?
For example there is difference about 500 bytes for tfm_hal_set_up_static_boundaries in our platform.
Best regards,
Roman.
-----Original Message-----
From: Raef Coles Raef.Coles@arm.com
Sent: Monday, December 11, 2023 11:09
To: tf-m@lists.trustedfirmware.org; Mazurak Roman (CSS ICW SW FW 3) Roman.Mazurak@infineon.com
Subject: Re: FIH volatile structure and stack usage
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.
Hey Roman
That is interesting - I was under the impression that having the structure marked as volatile was semantically the same as having all of its member volatile. Do you notice a considerable stack usage change with this fix?
I think if you do notice one, we'd be happy to have that change upstream. There's always some performance/size penalty to the FIH code but we should definitely try to minimize it if we can.
Raef
________________________________________
From: Roman.Mazurak--- via TF-M tf-m@lists.trustedfirmware.org
Sent: 08 December 2023 19:58
To: tf-m@lists.trustedfirmware.org
Subject: [TF-M] FIH volatile structure and stack usage
Hi all,
I found that using FIH medium/high profile with gcc generates code that uses stack extensively. It happens because fih_int structure is marked as volatile.
Is there any reason why structure itself is marked as volatile? Why it's not enough to make val and msk volatile members of fih_int structure?
Best regards,
Roman.
tf-m@lists.trustedfirmware.org
-
Raef Coles -
Roman.Mazurak＠infineon.com