ITS defines a few structs with specific alignment requirements, like:
struct __attribute__((__aligned__(ITS_FLASH_MAX_ALIGNMENT)))
its_file_meta_t {
uint32_t lblock; /*!< Logical datablock where file is
* stored
*/
size_t data_idx; /*!< Offset in the logical data block */
size_t cur_size; /*!< Size in storage system for this #
* fragment
*/
size_t max_size; /*!< Maximum size of this file */
uint32_t flags; /*!< Flags set when the file was
created */
uint8_t id[ITS_FILE_ID_SIZE]; /*!< ID of this file */
};
This causes issues with the IAR compiler when these structs are declared
as autos:
static psa_status_t its_mblock_copy_remaining_block_meta(
struct its_flash_fs_ctx_t
*fs_ctx,
uint32_t lblock)
{
struct its_block_meta_t block_meta;
psa_status_t err;
uint32_t meta_block;
size_t pos;
uint32_t scratch_block;
size_t size;
...
The IAR compiler gives these errors if the alignment is 0x10 (the stack
is 8 byte aligned):
struct its_block_meta_t block_meta;
^
"C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m\secure_fw\partitions\internal_trusted_storage\flash_fs\its_flash_fs_mblock.c",415
Error[Ta121]:
Auto variable "block_meta" cannot have a stricter alignment
than the
stack
I assume this alignment is only required for the flash, so the alignment
attributes should be set when declaring variables in the flash, not on
the type.
Comments?
Cheers,
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>
The merge of "Build: Add support for specifying GNUARM_PREFIX" appears
to break GNUARM builds.
[100%] Linking C static library mbedcrypto.a
/usr/bin/sh: CMAKE_GNUARM_AR-NOTFOUND: command not found
make[5]: *** [library/mbedcrypto.a] Fel 127
make[4]: *** [library/CMakeFiles/mbedcrypto.dir/all] Fel 2
make[3]: *** [all] Fel 2
make[2]: ***
[secure_fw/partitions/crypto/mbedcrypto_lib-prefix/src/mbedcrypto_lib-stamp/mbedcrypto_lib-build]
Fel 2
make[1]: ***
[secure_fw/partitions/crypto/CMakeFiles/mbedcrypto_lib.dir/all] Fel 2
make: *** [all] Fel 2
Excluding this commit is a workaround.
This is on Win 10.
Cheers,
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>
Hi,
Please find the presentation materials attached for Secure functions topic.
Reminder, the PSA L3 isolation design is here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4730
The best,
Anton
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: 25 June 2020 13:38
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] TF-M Technical Forum Agenda - June 25
Hello,
The agenda for today's forum:
* PSA Isolation (level 3) design review
* Secure Function model
* Any other business, if time permitted.
See you soon,
Anton
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M
Sent: 17 June 2020 12:55
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: [TF-M] TF-M Technical Forum call - June 25
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
Hello,
The agenda for today's forum:
* PSA Isolation (level 3) design review
* Secure Function model
* Any other business, if time permitted.
See you soon,
Anton
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: 17 June 2020 12:55
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] TF-M Technical Forum call - June 25
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
Curious if the intent is that the tf-m-tests repo would eventually be optional?
- k
> On Jun 19, 2020, at 5:29 AM, Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org> wrote:
>
> Hi,
>
> Following TF-M project restructuring, let me bring your attention to the new repository: tf-m-tests repo
> The intention is to migrate testing related code/libraries/tools there and clean the main repository.
> Patches have been made. Please be aware of the change.
> At this moment it does not affect the project development but in the future to test TF-M you will need to use this tf-m-tests repo.
>
> Thanks,
> Anton Komlev
> --
> TF-M mailing list
> TF-M(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hi All,
Both trusted-firmware-m and tf-m-tests repositories are tagged with TF-Mv1.1-RC1 tag marking the code freeze and beginning of the release candidate testing.
Best regards,
Anton Komlev
Tech Lead of TF-M in Arm Ltd.
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shebu Varghese Kuriakose via TF-M
Sent: 10 June 2020 18:28
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] TF-M v1.1 - Heads up
Hi All,
Just a heads up that TF-Mv1.1 tag is planned for middle to end of July. Code freeze of TF-M master is aimed around end of June to allow enough time for testing.
Similar to TF-Mv1.0 and previous tags, v1.1 will include all TF-M changes in TF-M master available till code freeze in end of June.
Availability of the tag will be notified via. this mailing list.
Thanks,
Shebu
Technology Manager-TF-M, Arm Ltd.
Hi everyone,
I would like to inform you about that the default bootloader option in TF-M has been changed from TF-M's MCUBoot fork to the original MCUBoot
by a commit that was merged a few hours ago (https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4551).
Due to this you may experience that your TF-M builds are failing after a recent rebase onto master with the following error message:
"Missing MCUBoot. Please clone the MCUBoot repo to directory....." . To solve this, you can choose from the following options:
1. Follow the instructions of the 'MCUBoot' section in the docs/getting_started/tfm_secure_boot.rst to clone the MCUBoot repository
and fulfill this dependency.
2. Quick but rather temporary solution: Append '-DMCUBOOT_REPO=TF-M' to your CMake configuration command to use the MCUBoot fork
from the TF-M repository as before. Example:
cmake -G"Unix Makefiles" -DTARGET_PLATFORM=AN521 -DCOMPILER=ARMCLANG -DMCUBOOT_REPO=UPSTREAM ../
Please let me know, if you have any difficulties.
Best regards,
David Vincze
Hi,
We have created one PSA Isolation implementation design document and now call for comments:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4730
The overall goal is to cover all isolation levels into this one document, and at current stage we take level 3 as an example.
The image layout and regions are based on the assumption of the existing TF-M code base.
Feel free to put comments, or post under this task:
https://developer.trustedfirmware.org/T778
Thanks.
/Ken
Hi Mate,
Thank you for the confirmation.
To avoid the limitation, I have switched the IRQ test service to PSA-RoT in our code. Should the original TFM do the same?
Thank you,
Andrej
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Mate Toth-Pal via TF-M
Sent: Tuesday, June 23, 2020 1:02 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] MPU Fault Handler in the 'Test secure irq' test
Hi Andrej,
Yes, this is a known limitation of the IRQ test case. Because of the limitation you mention in your mail it cannot be run in isolation levels higher than 1.
This test is part of the core test positive test suite, which is (by default) is disabled in certain cases (mostly because of these limitations):
CommonConfig.cmake:
if (CORE_TEST)
if (NOT CORE_IPC OR TFM_LVL EQUAL 1)
set(CORE_TEST_POSITIVE ON)
endif()
set(CORE_TEST_INTERACTIVE OFF)
endif()
It might be a possible workaround to define the IRQ test service as a PRoT as well.
Regards,
Mate
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: Monday, June 22, 2020 16:45
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] MPU Fault Handler in the 'Test secure irq' test
Hello,
During my update to the new TFM version (after one month pause),
occurs the MPU Fault Handler in the 'Test secure irq' regression test (TFM_ENABLE_IRQ_TEST is enabled).
The reason is that the test partition is defined as APP_ROT (non-privileged), but the test accesses to the NS memory region (dined as Privileged by default):
spm_irq_test_1_prepare_test_scenario_internal(enum irq_test_scenario_t irq_test_scenario, struct irq_test_execution_data_t *execution_data)
"execution_data" points to a global structure in NS RAM area provided by the NS test.
The workaround:
Define the IRQ test partition as PSA_ROT (privileged). Is it OK?
Is this known issue?
Thanks,
Andrej Butok
Hi Andrej,
Yes, this is a known limitation of the IRQ test case. Because of the limitation you mention in your mail it cannot be run in isolation levels higher than 1.
This test is part of the core test positive test suite, which is (by default) is disabled in certain cases (mostly because of these limitations):
CommonConfig.cmake:
if (CORE_TEST)
if (NOT CORE_IPC OR TFM_LVL EQUAL 1)
set(CORE_TEST_POSITIVE ON)
endif()
set(CORE_TEST_INTERACTIVE OFF)
endif()
It might be a possible workaround to define the IRQ test service as a PRoT as well.
Regards,
Mate
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: Monday, June 22, 2020 16:45
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] MPU Fault Handler in the 'Test secure irq' test
Hello,
During my update to the new TFM version (after one month pause),
occurs the MPU Fault Handler in the 'Test secure irq' regression test (TFM_ENABLE_IRQ_TEST is enabled).
The reason is that the test partition is defined as APP_ROT (non-privileged), but the test accesses to the NS memory region (dined as Privileged by default):
spm_irq_test_1_prepare_test_scenario_internal(enum irq_test_scenario_t irq_test_scenario, struct irq_test_execution_data_t *execution_data)
"execution_data" points to a global structure in NS RAM area provided by the NS test.
The workaround:
Define the IRQ test partition as PSA_ROT (privileged). Is it OK?
Is this known issue?
Thanks,
Andrej Butok
Hello,
During my update to the new TFM version (after one month pause),
occurs the MPU Fault Handler in the 'Test secure irq' regression test (TFM_ENABLE_IRQ_TEST is enabled).
The reason is that the test partition is defined as APP_ROT (non-privileged), but the test accesses to the NS memory region (dined as Privileged by default):
spm_irq_test_1_prepare_test_scenario_internal(enum irq_test_scenario_t irq_test_scenario, struct irq_test_execution_data_t *execution_data)
"execution_data" points to a global structure in NS RAM area provided by the NS test.
The workaround:
Define the IRQ test partition as PSA_ROT (privileged). Is it OK?
Is this known issue?
Thanks,
Andrej Butok
Hi Thomas,
Should be review.trustedfirmware.org/c/TF-M/tf-m-tests
Just replace "trusted-firmware-m" with "tf-m-tests" in the URL you push patches for TF-M.
Best Regards,
Kevin
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M
Sent: Monday, June 22, 2020 3:36 PM
To: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] new tf-m-test repository
What is the URL to push patches to this repo?
I attempted to push the IAR RTX libraries but it failed.
Cheers,
Thomas
Den 2020-06-19 kl. 12:29, skrev Anton Komlev via TF-M:
Hi,
Following TF-M project restructuring, let me bring your attention to the new repository: tf-m-tests repo<https://git.trustedfirmware.org/TF-M/tf-m-tests.git/>
The intention is to migrate testing related code/libraries/tools there and clean the main repository.
Patches have been made. Please be aware of the change.
At this moment it does not affect the project development but in the future to test TF-M you will need to use this tf-m-tests repo.
Thanks,
Anton Komlev
--
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>
What is the URL to push patches to this repo?
I attempted to push the IAR RTX libraries but it failed.
Cheers,
Thomas
Den 2020-06-19 kl. 12:29, skrev Anton Komlev via TF-M:
>
> Hi,
>
> Following TF-M project restructuring, let me bring your attention to
> the new repository: *tf-m-tests* repo
> <https://git.trustedfirmware.org/TF-M/tf-m-tests.git/>
>
> The intention is to migrate testing related code/libraries/tools there
> and clean the main repository.
>
> Patches have been made. Please be aware of the change.
>
> At this moment it does not affect the project development but in the
> future to test TF-M you will need to use this tf-m-tests repo.
>
> Thanks,
>
> Anton Komlev
>
>
--
*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>
Hi all,
Symmetric initial attestation patches are merged. Symmetric initial attestation now is enabled in TF-M Profile Small.
Thanks a lot for the review and support.
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M
Sent: Monday, May 18, 2020 3:34 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Ask for final review of symmetric based initial attestation design
Hi all,
May I ask for a final round of review on symmetric initial attestation design document on https://review.trustedfirmware.org/c/trusted-firmware-m/+/3898?
The document has been reviewed for a long time and received many valuable comments. Thanks a lot.
If there is no further critical comment, I'd like to merge this design this Friday.
Best regards,
Hu Ziji
Thanks Anton.
As you may have noticed, the CMSIS RTX libraries have been added to the tf-m-tests.
There are also patches<https://review.trustedfirmware.org/q/topic:%22CMSIS_5_to_tfm_tests%22+(stat…> for TF-M to reference the libraries from tf-m-tests.
The plan is to merge them before TF-M 1.1 release code freeze (around end of June).
You would need to clone the tf-m-tests repo to build TF-M when these patches were merged.
Best Regards,
Kevin
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: Friday, June 19, 2020 6:30 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] new tf-m-test repository
Hi,
Following TF-M project restructuring, let me bring your attention to the new repository: tf-m-tests repo<https://git.trustedfirmware.org/TF-M/tf-m-tests.git/>
The intention is to migrate testing related code/libraries/tools there and clean the main repository.
Patches have been made. Please be aware of the change.
At this moment it does not affect the project development but in the future to test TF-M you will need to use this tf-m-tests repo.
Thanks,
Anton Komlev
Hi,
Following TF-M project restructuring, let me bring your attention to the new repository: tf-m-tests repo<https://git.trustedfirmware.org/TF-M/tf-m-tests.git/>
The intention is to migrate testing related code/libraries/tools there and clean the main repository.
Patches have been made. Please be aware of the change.
At this moment it does not affect the project development but in the future to test TF-M you will need to use this tf-m-tests repo.
Thanks,
Anton Komlev
Hi Everyone
I have pushed the proposal for release cadence and process for here : https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4635
This mainly follows the TF-A release process. The release cadence period is set to be 4 months with a code freeze of up to 3 weeks.
Best Regards
Soby Mathew
Hi Andrej,
The PSA Storage spec (available here https://developer.arm.com/architectures/security-architectures/platform-sec…) states that the Protected Storage service should be implemented inside the Application Root of Trust.
The principle is that the PSA Root of Trust should be kept as small as possible, to reduce the attack surface of the most privileged part of the system. As Protected Storage neither needs the privileges of the PSA Root of Trust nor is used by any PSA Root of Trust service, it should be implemented inside the Application Root of Trust.
Kind regards,
Jamie
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: 18 June 2020 09:16
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] PS => AP ROT
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,
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
