I have no access to a B1 target, which is the reason no IAR port exists.
Cheers,
Thomas
24 juli 2021 kl. 22:39 skrev Suresh Marisetty via TF-M <tf-m@lists.trustedfirmware.org>:
Hi,
One of the requests that I have is how the code size differs between GCC and IAR for the Musca-B1 SE build.
However, it appears from the documentation that IAR is not supported on Musca-B1. So, I am wondering if anybody can provide some insight on the size from IAR.
And here are the TF-M image sizes as of now with GCC in release mode:
SE: ~185 KiB code flash and ~63 KiB RAM
Host: ~22 KiB code flash and ~16 KiB RAM
(a few more KiB needed for the images in flash for image header and trailer if loaded by mcuboot)
IAR?
thanks
Suresh Marisetty
Infineon Semiconductor Corporation
From: David Hu <David.Hu@arm.com> Sent: Sunday, July 4, 2021 11:37 PM To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty@infineon.com>; Mark Horvath <Mark.Horvath@arm.com> Cc: nd <nd@arm.com>; tf-m@lists.trustedfirmware.org Subject: RE: Questions on Musca-B1 SE implementation - code size analysis
Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you
validate it is safe.
Hi Suresh,
Please check t Profile Medium and Profile Large design documents below. The ciphers supported are listed in the document.
I don’t think the software countermeasures against physical attacks are enabled in Musca-B1 SE, by default. Mark, please correct me if I misunderstand it.
TF-M implements a Fault Inject Hardening (FIH) library as software countermeasure to mitigate physical attacks.
FIH is enabled as Medium Profile in Profile Large by default. You can set `TFM_FIH_PROFILE` as OFF to disable FIH features.
FIH is not implemented by mebd TLS or CC312. It consists of protections of TF-M SPM critical routine and platform specific isolation configuration.
Wondering if someone can provide more visibility in the following in regards to the SE build with profile medium and large:
What ciphers are supported in medium vs. large (I see the size of the code bloats up almost twice from 30 to 60K approx) – observation from size of libmbedcrypto and libcrypto_service_cc312
– any clear documentation on this or a link would be helpful (besides code review)
When the SE is built for the large profile, assume it also includes “Software countermeasures against physical attacks” since it is offloading to the CC-312
Is there a way to build the large profile without physical attack counter-measures?
While library are these countermeasures implemented in (libmbed or lib_cc312)?
On our initial analysis, for a medium profile these two libraries appears to be 30K-33K in size each and is this in the right ballpark? (with minsizerel)
I assume the code size increase is due to additional cipher support + physical attack countermeasures. Correct me otherwise.
Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments
unless you validate it is safe.
Hi Suresh,
Yes, by default the cc312 acceleration is turned on at build time for SE, and the algorithms will be handled by HW instead of the SW implementation. If you would like to use SW crypto instead you
can pass the HW_ACCELERATOR="OFF" flag to cmake when building the SE TF-M instance.
And here are the TF-M image sizes as of now with GCC in release mode:
SE: ~185 KiB code flash and ~63 KiB RAM
Host: ~22 KiB code flash and ~16 KiB RAM
(a few more KiB needed for the images in flash for image header and trailer if loaded by mcuboot)
I am following up on a question that came up on the TFM Core and MCUBoot image sizes that is built for SE on Musca-B1.
We are trying to figure out the resource requirements for SE, to be able to host the TF-M as suggested in the slides below. Wondering if anyone throw more light on the RAM/FLASH requirements for it.
Also, does the TFM profile small/medium/large map to this at all or is it different from them. Also, what’s are the estimated latencies of boot on SE with all the Flash accesses, etc.