Re: [TF-M] Eliminate unnecessary space in tfm_s.bin

Hi all,

The patchhttps://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/12620/ for this proposal has been reviewed for about one week. Also thanks to @Thomas Törnblommailto:thomas.tornblom@iar.com 's effort, the link script for IAR compiler has been updated in this patchhttps://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/13171/. I would like to merge the patches on this Thursday if no more comments. May I ask for the final review on these two patches?

Thanks,

Regards, Sherry Zhang

From: Sherry Zhang Sent: Wednesday, December 15, 2021 1:02 PM To: Bøe, Sebastian Sebastian.Boe@nordicsemi.no; Tamas Ban Tamas.Ban@arm.com; tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: RE: Eliminate unnecessary space in tfm_s.bin

Hi,

If no objections, I would like to ask for code review on the patchhttps://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/12620/. The patch has been verified by CI.

Thanks,

Regards, Sherry Zhang

From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Bøe, Sebastian via TF-M Sent: Friday, December 10, 2021 9:20 PM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org; Tamas Ban <Tamas.Ban@arm.commailto:Tamas.Ban@arm.com> Cc: nd <nd@arm.commailto:nd@arm.com> Subject: Re: [TF-M] Eliminate unnecessary space in tfm_s.bin

Great, then no objections from our side on this change. ________________________________ From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> on behalf of Tamas Ban via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Friday, December 10, 2021 2:18 PM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd@arm.commailto:nd@arm.com> Subject: Re: [TF-M] Eliminate unnecessary space in tfm_s.bin

Hi Sebastian,

The veneers location is a built time contract between the Secure and the Non-secure image. When NS image calls a Secure function it jumps to build time hardcoded (by the compiler) address.

This mandates that for supporting independent updates (either S or NS) the veneer location must be on a fixed address. Otherwise, the contract will be broken and the secure function call not working anymore.

So, if we would move the veneer region from the end of the image to the beginning (behind the vector table) then this requires updating the device once with both images together to keep them synced. When this is done then again the images can be updated independently because the new veneer location will be fixed again.

Is it DFU from 1.5 to 1.6 that would not be possible?

It works but S and NS must be updated together.

Tamas

From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Bøe, Sebastian via TF-M Sent: 2021. december 10., péntek 13:28 To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org; Sherry Zhang <Sherry.Zhang2@arm.commailto:Sherry.Zhang2@arm.com> Cc: nd <nd@arm.commailto:nd@arm.com> Subject: Re: [TF-M] Eliminate unnecessary space in tfm_s.bin

Hi,

we are concerned about the time it will take to do Over-the-Air Device Firmware Update

when we can't update the images independently.

This timing is of critical importance for products that don't want downtime during updates.

Also, we don't understand why the veneers are not considered to be fixed in both situations.

And consequently, why moving them prevents update of the images independently.

Please clarify.

Is it DFU from 1.5 to 1.6 that would not be possible?

That we are OK with.

________________________________

From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> on behalf of Sherry Zhang via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Thursday, December 9, 2021 11:18 AM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd@arm.commailto:nd@arm.com> Subject: [TF-M] Eliminate unnecessary space in tfm_s.bin

Hi,

Currently, in the compiler link script, the CMSE VENEER section is placed at a fixed address which is at the end of tfm code. See code for armclanghttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trustedfirmware.org%2FTF-M%2Ftrusted-firmware-m.git%2Ftree%2Fplatform%2Fext%2Fcommon%2Farmclang%2Ftfm_common_s.sct%23n260&data=04%7C01%7Csebastian.boe%40nordicsemi.no%7C09b34ee83892461f383708d9bbdf8c03%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637747391069012969%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=LOMCBff1qL0N9uG5DhD9LzwNHrvrYCYmfCKoQh%2ByssM%3D&reserved=0 and gnu armhttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trustedfirmware.org%2FTF-M%2Ftrusted-firmware-m.git%2Ftree%2Fplatform%2Fext%2Fcommon%2Fgcc%2Ftfm_common_s.ld%23n569&data=04%7C01%7Csebastian.boe%40nordicsemi.no%7C09b34ee83892461f383708d9bbdf8c03%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637747391069022911%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=NV27JGpbfUyz0S5t4zPsKEFuE2fpX2dAq2kZbOC%2BOOU%3D&reserved=0.

Placing the veneers at the fixed address has the benefit that the when the secure image updates, the veneer symbols remain unchanged. So, the nonsecure image does not have to be updated together.

The problem is that the size of tfm_s.bin is always the same in different TF-M build configurations(debug mode, release mode, profile small, profile large and so on). So, there can be large empty space between the end of tfm code and the veneer section.

As we discussed on today's tech forum meeting, I propose to move the LR_VENEER from the end of tfm code to right after the secure vector table. In this way, the space between the tfm code and the veneers section is eliminated. Also, the supported number of interrupts for each platform is fixed. So, the size of the vector table is fixed for each platform. So, the start address of veneer section is still fixed for each platform. The size of tfm_s.bin is reduced significantly after this change. Take the AN521 platform for example, the size of tfm_s.bin has a 70 percent reduction.

The link script change for armclanghttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.trustedfirmware.org%2Fc%2FTF-M%2Ftrusted-firmware-m%2F%2B%2F12620%2F6%2Fplatform%2Fext%2Fcommon%2Farmclang%2Ftfm_common_s.sct&data=04%7C01%7Csebastian.boe%40nordicsemi.no%7C09b34ee83892461f383708d9bbdf8c03%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637747391069022911%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Vic9%2FvVOAebFe2wmDhOnRGH%2Foqk7OLcIFAf%2BjtNWGV0%3D&reserved=0 and gnu armhttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.trustedfirmware.org%2Fc%2FTF-M%2Ftrusted-firmware-m%2F%2B%2F12620%2F6%2Fplatform%2Fext%2Fcommon%2Fgcc%2Ftfm_common_s.ld&data=04%7C01%7Csebastian.boe%40nordicsemi.no%7C09b34ee83892461f383708d9bbdf8c03%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637747391069032884%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=E08t1YQCAJFmvnDES3iU5ReqEfOo5Az9VzJQj6GftBQ%3D&reserved=0 in this patchhttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.trustedfirmware.org%2Fc%2FTF-M%2Ftrusted-firmware-m%2F%2B%2F12620%2F&data=04%7C01%7Csebastian.boe%40nordicsemi.no%7C09b34ee83892461f383708d9bbdf8c03%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637747391069032884%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=eQ7QWZNKML73bh0Gxt3bGGSmzXGBbDeqX0WLFj70Wbg%3D&reserved=0 can help me demonstrating my proposal. I am not hurry asking for review and merge this patch. As it impacts all the platforms, I want to get confirmed that all platforms which are using the common link script are happy with this proposal.

Any comments or especially concerns on this proposal?

Thanks,

Regards,

Sherry Zhang