Hello,
I have just notices that the TFM Protected Storage service partition has been changed from PSA ROT to APP ROT.
Just curious, what is a reason?
May it stay PSA ROT?
Thank you in advance,
Andrej Butok
Hello,
The next Technical Forum is planned on Thursday, June 25 at 15:00-16:00 UTC (US time zone).
This is exceptional time zone change because of a public holiday in China that day.
Please reply on this email with your proposals for agenda topics.
Best regards,
Anton Komlev
Hi Tamas,
> I do not know whether the this two phase setting of MSP_LIMIT is still in use or not. If not the no need for S_MSP_STACK_SIZE_INIT.
The only place where it's used is the GCC linker file:
__msp_init_stack_size__ = S_MSP_STACK_SIZE_INIT
So for GCC __msp_init_stack_size__ is in 2 times less (0x400) than for Keil and IAR (0x800) "__msp_init_stack_size__ = S_MSP_STACK_SIZE".
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M
Sent: Tuesday, June 16, 2020 10:17 AM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] S_MSP_STACK_SIZE_INIT vs S_MSP_STACK_SIZE
Hi Andrej,
The BOOT_TFM_SHARED_DATA and the MSP_STACK area are overlapping on purpose. The partitions which are expecting to receive data from bootloader is intended to get their own data during the partition init phase with calling tfm_core_get_boot_data() with the partition's major_type. Then the data will be copied from shared area to partition's memory.
So after all partition's init is executed then the data from the shared buffer is distributed to the owning partitions and resides in their memory. At this point the shared_data area can be overwritten by growing MSP, without destroying shared data.
Originally there was an S_MSP_STACK_SIZE_INIT size which was used to setup the MSP_LIMIT for the init phase to avoid overwriting the shared data area. After the init phase the MSP_LIMIT was set again with its full size S_MSP_STACK_SIZE.
I do not know whether the this two phase setting of MSP_LIMIT is still in use or not. If not the no need for S_MSP_STACK_SIZE_INIT.
+-> +-> +--------------+ <- Shared boot data base, S_MSP_STACK_SIZE
| Shared| | |
M | Data | | |
S | | | |
P | +-> +--------------+ <- S_MSP_STACK_SIZE_INIT
| | |
| | |
| | |
+-> +--------------+ <- Top of MSP
Tamas
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M
Sent: 16 June 2020 09:52
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] S_MSP_STACK_SIZE_INIT vs S_MSP_STACK_SIZE
Hello,
What is a difference between S_MSP_STACK_SIZE_INIT and S_MSP_STACK_SIZE defined in partition\region_defs.h:
#define S_MSP_STACK_SIZE_INIT (0x0000400)
#define S_MSP_STACK_SIZE (0x0000800)
S_MSP_STACK_SIZE_INIT is used only for gcc.
S_MSP_STACK_SIZE is used for armclang and iar.
Guess, it should be used only one definition. So in our platform code we are going to use only S_MSP_STACK_SIZE.
Should you fix it for all platforms in the original TFM?
Thanks,
Andrej Butok
SW Tech Lead
Security & Connectivity, Microcontrollers
NXP Semiconductors
Hi Andrej,
The BOOT_TFM_SHARED_DATA and the MSP_STACK area are overlapping on purpose. The partitions which are expecting to receive data from bootloader is intended to get their own data during the partition init phase with calling tfm_core_get_boot_data() with the partition's major_type. Then the data will be copied from shared area to partition's memory.
So after all partition's init is executed then the data from the shared buffer is distributed to the owning partitions and resides in their memory. At this point the shared_data area can be overwritten by growing MSP, without destroying shared data.
Originally there was an S_MSP_STACK_SIZE_INIT size which was used to setup the MSP_LIMIT for the init phase to avoid overwriting the shared data area. After the init phase the MSP_LIMIT was set again with its full size S_MSP_STACK_SIZE.
I do not know whether the this two phase setting of MSP_LIMIT is still in use or not. If not the no need for S_MSP_STACK_SIZE_INIT.
+-> +-> +--------------+ <- Shared boot data base, S_MSP_STACK_SIZE
| Shared| | |
M | Data | | |
S | | | |
P | +-> +--------------+ <- S_MSP_STACK_SIZE_INIT
| | |
| | |
| | |
+-> +--------------+ <- Top of MSP
Tamas
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: 16 June 2020 09:52
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] S_MSP_STACK_SIZE_INIT vs S_MSP_STACK_SIZE
Hello,
What is a difference between S_MSP_STACK_SIZE_INIT and S_MSP_STACK_SIZE defined in partition\region_defs.h:
#define S_MSP_STACK_SIZE_INIT (0x0000400)
#define S_MSP_STACK_SIZE (0x0000800)
S_MSP_STACK_SIZE_INIT is used only for gcc.
S_MSP_STACK_SIZE is used for armclang and iar.
Guess, it should be used only one definition. So in our platform code we are going to use only S_MSP_STACK_SIZE.
Should you fix it for all platforms in the original TFM?
Thanks,
Andrej Butok
SW Tech Lead
Security & Connectivity, Microcontrollers
NXP Semiconductors
Hello,
What is a difference between S_MSP_STACK_SIZE_INIT and S_MSP_STACK_SIZE defined in partition\region_defs.h:
#define S_MSP_STACK_SIZE_INIT (0x0000400)
#define S_MSP_STACK_SIZE (0x0000800)
S_MSP_STACK_SIZE_INIT is used only for gcc.
S_MSP_STACK_SIZE is used for armclang and iar.
Guess, it should be used only one definition. So in our platform code we are going to use only S_MSP_STACK_SIZE.
Should you fix it for all platforms in the original TFM?
Thanks,
Andrej Butok
SW Tech Lead
Security & Connectivity, Microcontrollers
NXP Semiconductors
Hi,
This design addressing to share the code of the common crypto primitives(SHA256, RSA, later AES) between MCUboot and runtime SPE. The goal is to reduce the flash footprint of SPE.
Design proposal:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4587
Implementation:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4583/
TL;DR:
SPE binary size can be reduced with 10KB. If image encryption will be turned on then ~12-13KB is the gain. Please let us know if you think this improvements would be useful.
@Thomas Törnblom<mailto:thomas.tornblom@iar.com>:
Could you check the porting to IAR toolchain?
BR,
Tamas Ban
Hi Thomas,
My bad, I merged a patch today that broke it. The fix is here https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4562. I will merge it once the CI has verified it.
Kind regards,
Jamie
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M
Sent: 12 June 2020 14:00
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Does FVP_SSE300_MPS2 target build?
I just noticed the merge of the FVP_SSE300_MPS2 support and I'm trying to build, but it fails with:
---
[ 23%] Building C object test/secure_test/CMakeFiles/tfm_secure_tests.dir/suites/ps/secure/psa_ps_s_interface_testsuite.o
C:/Users/thomasto/Projects/tf-m1/trusted-firmware-m/test/suites/ps/secure/psa_ps_s_interface_testsuite.c:46:39: error:
use of undeclared identifier 'PS_MAX_ASSET_SIZE'
static const uint8_t write_asset_data[PS_MAX_ASSET_SIZE] = {0xBF};
...
---
Known issue?
Thomas
--
Thomas Törnblom, Product Engineer
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com>
Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>
I just noticed the merge of the FVP_SSE300_MPS2 support and I'm trying
to build, but it fails with:
---
[ 23%] Building C object
test/secure_test/CMakeFiles/tfm_secure_tests.dir/suites/ps/secure/psa_ps_s_interface_testsuite.o
C:/Users/thomasto/Projects/tf-m1/trusted-firmware-m/test/suites/ps/secure/psa_ps_s_interface_testsuite.c:46:39:
error:
use of undeclared identifier 'PS_MAX_ASSET_SIZE'
static const uint8_t write_asset_data[PS_MAX_ASSET_SIZE] = {0xBF};
...
---
Known issue?
Thomas
--
*Thomas Törnblom*, /Product Engineer/
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com>
Website: www.iar.com <http://www.iar.com>
Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>
