Hi Andrej,
You seem to be right.
In the current platforms NS_DATA_SIZE is defined as either of the following:
* #define NS_DATA_SIZE (TOTAL_RAM_SIZE - S_DATA_SIZE)
* #define NS_DATA_SIZE (TOTAL_RAM_SIZE / 2)
Which means NS_DATA_SIZE Is the maximum available RAM for the NS Software.
So the maximum available size of the RW and ZI data is decreased by the amounts you enumerate in your mail.
I created a task to fix this: https://developer.trustedfirmware.org/T687
Thanks,
Mate
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: Thursday, March 12, 2020 9:23 AM
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] NS DATA Linker file
Hello,
It looks like there is a mistake for ER_DATA region in the NS armclang linker file.
...
ER_DATA NS_DATA_START NS_DATA_SIZE {
* (+ZI +RW)
}
/* MSP */
ARM_LIB_STACK_MSP +0 ALIGN 32 EMPTY NS_MSP_STACK_SIZE {
}
/* PSP */
ARM_LIB_STACK +0 ALIGN 32 EMPTY NS_PSP_STACK_SIZE {
}
ARM_LIB_HEAP +0 ALIGN 8 EMPTY NS_HEAP_SIZE {
}
...
ER_DATA does not take into account the NS_MSP_STACK_SIZE+NS_PSP_STACK_SIZE+EMPTY NS_HEAP_SIZE size:
#define NS_DATA_SIZE (TOTAL_RAM_SIZE - S_DATA_SIZE)
Guess, the NS linker file should be:
...
ER_DATA NS_DATA_START NS_DATA_SIZE-NS_MSP_STACK_SIZE-NS_PSP_STACK_SIZE-EMPTY NS_HEAP_SIZE {
* (+ZI +RW)
}
...
Or, did I miss something?
Thank you,
Andrej Butok
Hi Tamas,
I have noticed today, that the PSA test suite has done several merges to its master branch.
Based the PSA test-suit readme, it has switched to newer versions of the PSA API.
Should we try to update or better to wait for a right signal from the TFM team?
Thanks,
Andrej
From: Tamas Ban <Tamas.Ban(a)arm.com<mailto:Tamas.Ban@arm.com>>
Sent: Thursday, February 6, 2020 2:09 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>>
Subject: RE: PSA Test Suite - Attestation test
Hi Andrej,
The v19.08_TBSA0.9 version of psa-arch test suite is aligned with current TF-M master.
I have executed the test suite and found that unfortunately the attestation test suite is currently broken:
* It was introduced by the QCBOR library update in https://review.trustedfirmware.org/c/trusted-firmware-m/+/2679/6<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>
* Currently there is a misalignment between psa-arch and tf-m in terms of QCBOR version. psa-arch still relies on older version of QCBOR.
* The version mismatch lead some parsing error in CBOR that is the reason why the test suite is failing.
* Other issue is that v19.08_TBSA0.9 version of psa-arch mandates the key-id in unprotected COSE header, however that field is optional according to the standard. In TF-M the inclusion of key-id was bind to ATTEST_INCLUDE_TEST_CODE_AND_KEY_ID, which was split to two compile time switch (https://review.trustedfirmware.org/c/trusted-firmware-m/+/3147<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>) ATTEST_INCLUDE_COSE_KEY_ID and ATTEST_ INCLUDE_TEST_CODE.
Way forward:
* I let the psa-arch test team to update QCBOR.
* Fix will be put on master, but currently the tip of the psa-arch master is not aligned with TF-M master. They are supports different PSA API versions.
* In TF-M there is a branch<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust…> where the PSA API update is happening. This branch is intended to be merged to master in Q1.
Tamas
From: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>>
Sent: 05 February 2020 14:21
To: Tamas Ban <Tamas.Ban(a)arm.com<mailto:Tamas.Ban@arm.com>>
Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: RE: PSA Test Suite - Attestation test
Hi Tamas
> Could you tell what was the values of these compile time switches in your test?
For the previous TFM, we have used INCLUDE_TEST_CODE_AND_KEY_ID. For the current TFM it was renamed to INCLUDE_TEST_CODE.
Other parameters are new, so I have tried different combinations of these parameters, but the PSA Test-Suite Attestation is still failed.
> Further do you implemented the boot data sharing between bootloader and runtime firmware?
It's used the TFM template code without change from tfm\platform\ext\common\template
> Do you sign SPE and NPSE images together or they are signed separately?
We do not use the secondary bootloader so far, so image is not signed.
As the Attestation Regression tests are passed. It's good to know what combination of parameters have to be used to generate the same token as it was generated by the older TFM and accepted by the PSA Test Suite (last commit on master branch). Or the PSA Test Suite is obsolete.
Thank you,
Andrej
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Tamas Ban via TF-M
Sent: Wednesday, February 5, 2020 1:13 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: Re: [TF-M] PSA Test Suite - Attestation test
Hi Andrej,
Could you tell what was the values of these compile time switches in your test? I assume you did the test on NXP board. Further do you implemented the boot data sharing between bootloader and runtime firmware? Do you sign SPE and NPSE images together or they are signed separately?
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: 04 February 2020 17:33
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] PSA Test Suite - Attestation test
Hello,
After upgrade to the latest version of TFM, the Attestation test from the PSA Test Suite is failed (but the TFM Attestation regression tests are passed).
What combination of configuration parameters must be used (INCLUDE_OPTIONAL_CLAIMS, INCLUDE_TEST_CODE, INCLUDE_COSE_KEY_ID, BOOT_DATA_AVAILABLE) to follow PSA Test Suite expectations?
What commit of the PSA Test-suite must be used for the latest TFM? We are still on the 2019-07-25 (c80681ed7c7f3e2cbf02ded1ef2464ba2ca7ccd5) commit, which was OK with 2-month old TFM.
Is the PSA Test Suite Attestation test valid for the latest TFM?
Thank you,
Andrej Butok
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi All,
I would like to give a short talk about a tool proposal to test IRQ handling in TF-M core.
Regards,
Mate
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: Wednesday, March 11, 2020 1:27 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] TF-M Technical Forum call - March 19
Hello,
The next Technical Forum is planned on Thursday, March 19 at 7:00-8:00 UTC.
Please reply on this email with your proposals for agenda topics.
Best regards,
Anton Komlev
Hello,
It looks like there is a mistake for ER_DATA region in the NS armclang linker file.
...
ER_DATA NS_DATA_START NS_DATA_SIZE {
* (+ZI +RW)
}
/* MSP */
ARM_LIB_STACK_MSP +0 ALIGN 32 EMPTY NS_MSP_STACK_SIZE {
}
/* PSP */
ARM_LIB_STACK +0 ALIGN 32 EMPTY NS_PSP_STACK_SIZE {
}
ARM_LIB_HEAP +0 ALIGN 8 EMPTY NS_HEAP_SIZE {
}
...
ER_DATA does not take into account the NS_MSP_STACK_SIZE+NS_PSP_STACK_SIZE+EMPTY NS_HEAP_SIZE size:
#define NS_DATA_SIZE (TOTAL_RAM_SIZE - S_DATA_SIZE)
Guess, the NS linker file should be:
...
ER_DATA NS_DATA_START NS_DATA_SIZE-NS_MSP_STACK_SIZE-NS_PSP_STACK_SIZE-EMPTY NS_HEAP_SIZE {
* (+ZI +RW)
}
...
Or, did I miss something?
Thank you,
Andrej Butok
Hello everyone, I'm new to the list. Quick introduction: I work at Texas Instruments and I'm investigating TFM for use in some of our platforms here.
I'm trying to understand the scheduling and task architecture for PSA and the TFM implementation and how that intersects with NS tasks.
I found the following:
https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…https://arm-software.github.io/CMSIS_5/Core/html/group__context__trustzone_…
The existing TFM implementation doesn't seem to do much with the tz_context interface. It looks like it tracks which NS client is active, but I don't see where it uses that information to do anything.
Am I missing something?
I'd like to understand more about where TFM is going with the tz_context interface.
Will there be a tz_context focused scheduler? I can imagine one where the SPM associates NS clients with running Secure Partitions and resumes execution of a running a Secure Partition when the NS RTOS indicates the NS client is "active." But it isn't clear to me if this is the direction or not.
I note that the text for TZ_LoadContext_S says "**Prepare** the secure context for execution so that a thread in the non-secure state can call secure library modules." Preparing sounds different than immediate execution.
Are there other documents I can read or source implementations I can reference to get more of a handle on this?
Thanks,
Erik Shreve, PSEM
Software Security Engineer & Architect (CMCU Platform Development)
Texas Instruments
Hello,
The next Technical Forum is planned on Thursday, March 19 at 7:00-8:00 UTC.
Please reply on this email with your proposals for agenda topics.
Best regards,
Anton Komlev
Hi,
TF-M version information is carried by manifest data, which is appended to the image in a post build step (at image signing):
* Image header: Contains image actual version: 1.0.0
* Image TLV (footer): Can contains a dependency TLV entry which refers to the dependent image by an ID and its minimum version.
Dependency verification:
* At boot time the bootloader checks whether the dependency would be satisfies after a software upgrade. If not then it deny the update.
* https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/user_guide…
At runtime there is no API to get the image version or its capability.
Did I answer your question?
Tamas
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M
Sent: 09 March 2020 09:45
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Product Lifecycle Management: TF-M + Non-Secure Application
Hi,
How does TF-M consider Product Lifecycle Management (PLM)?
Assuming the following scenario where TF-M and Non-Secure Application are independently developed/updated in a deployed system:
* TF-M is delivered i.e. by a silicon vendor in a pre-configured variant and Non-Secure Application starts to use this configuration.
* During PLM there is a decision to update/upgrade/downgrade TF-M. The new image is pushed to deployed devices independent of Non_Secure application.
Questions that I have:
* Is there a way for the Non-Secure application to identify the functionality available in TF-M?
* How is it ensured that new TF-M versions are compatible with previous versions?
Reinhard
Abhishek,
A few days, I posted the reasons why MPC/PPC should not be used for level 3 isolation. Did you had a chance to read that?
MPC/PPC implement system wide isolation. IMHO, reprogramming it for level 3 isolation should be not considered as it creates various problems for the system designer.
You did also ask, how to ensure that security is actually enabled, basically if security has been initalized. The best approach would be to check if the SAU->CTRL is correctly set; if not the system should shut down.
Reinhard
Hi,
How does TF-M consider Product Lifecycle Management (PLM)?
Assuming the following scenario where TF-M and Non-Secure Application are independently developed/updated in a deployed system:
* TF-M is delivered i.e. by a silicon vendor in a pre-configured variant and Non-Secure Application starts to use this configuration.
* During PLM there is a decision to update/upgrade/downgrade TF-M. The new image is pushed to deployed devices independent of Non_Secure application.
Questions that I have:
* Is there a way for the Non-Secure application to identify the functionality available in TF-M?
* How is it ensured that new TF-M versions are compatible with previous versions?
Reinhard
We need to be cognizant of the target usage and user base. The vast majority of usage is v8m in which case the HAL can be simple and targeted for TrustZone. Based on what I have witnessed other than the changes required to support dual/multicore usage. Why not offer a HAL option for TrustZone and one for dual/multicore?
All the best!
Reed
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Abhishek Pandit via TF-M <tf-m(a)lists.trustedfirmware.org>
Reply-To: Abhishek Pandit <Abhishek.Pandit(a)arm.com>
Date: Friday, March 6, 2020 at 4:28 AM
To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] TrustZone initialisation procedure
Hi,
I see this slight differently. The purpose of TF-M HAL is to abstract out specific HW dependencies from the SW framework for creating isolated secure partitions. As you can understand, various systems have differences in what components are utilized for isolation, but TF-M needs to implement a generic mechanism that works across multiple platforms. Therefore it’s important to consider what’s platform specific and what’s generic.
In that sense, SAU and other system components are specific to the underlying HW hence should be part of platform implementation. Of course, it is possible to implement a unified HAL for a family of devices, however I would still expect the hardware abstraction layer in TF-M to remain agnostic of how the HW implements/facilitates isolation of secure world.
I don’t disagree with the suggestion about enhancements but they seem platform specific to me so should be discussed in that context.
Thanks,
Abhishek
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: 04 March 2020 03:14
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] TrustZone initialisation procedure
Hi Jonatan,
The enhancement of this TZ_SAU_Setup() sounds reasonable, and there are more background items to be considerate:
* The SPM need to re-configure the isolation hardware dynamically under isolation level 3 while SPM scheduling, and MPC/PPC is potentially included. So I am not sure what the ‘system isolation’ mean in your mail, if you want a static initialization for all isolation settings then it will not work for SPM at least for the isolation level 3 design. If it includes the minimal security (and fundamental) setting while system booting and there are other functions to update the isolation setting later, it is do-able.
* How does the parameter pass into this function? Because SPM needs to know the status of the existing isolation setting for some purposes (such as security checking), so there needs to be a way to let SPM know the isolation status.
So if we do the fundamental security setup in SystemInit(), the advantage is the protection is already enabled between SystemInit() exits and SPM_Init() (There are platform init process in this stage). The cons are SPM may not check the isolation status. And if we do isolation in SPM_Init(), the advantage is SPM can know the status and the cons are Platform Init is not restricted (It could access anywhere).
I would suggest not to propose the calling time strictly for this new enhanced API.
I know cypress uses customized protection initialization mechanism so any ideas?
BR
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Jonatan Antoni via TF-M
Sent: Tuesday, March 3, 2020 11:09 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] TrustZone initialisation procedure
Hi all,
I am trying to align TrustZone initialisation procedure between TF-M and CMSIS.
In CMSIS the approach from the early v8-M days is to have a “partition.h” file providing “TZ_SAU_Setup()” function. This function is called during low level “SystemInit()” which runs as part of the pre-main (called from ResetHandler and before running C lib init).
In contrast TF-M calls “tfm_spm_hal_init_isolation_hw()” (which is similar to “TZ_SAU_Setup()” plus PPC/MPC configuration) during “tfm_core_init()” (which runs in secure “main()”).
The advantage of “TZ_SAU_Setup()” is that this function is available by standard for all TrustZone devices. The shortcoming is it doesn’t cover MPC/PPC configuration, yet. Ideally we can enhance CMSIS standard to offer a “TrustZone_Setup()” function (the name is still to be defined) that does all this. That would simplify the TF-M HAL to just one single function call that should be provided by each TrustZone-Device low level init code.
The final question is: When does this function need to be called? Are you aware of any reason why we should not configure the “system isolation” already during low level init (pre-main)? This could simplify TF-M code even more. In TF-M we could simply rely on a properly configured TrustZone isolation before running any TF-M code.
Cheers,
Jonatan Antoni
Senior Engineering Manager - CMSIS [Germany on Google Android 8.0] [United Kingdom on Google Android 8.0]
Arm Germany GmbH
Phone: +49 (0)89 262 029 618 | Fax: +49 (0)89 456 040-19
Email: jonatan.antoni(a)arm.com<mailto:jonatan.antoni@arm.com> | Visit: www.keil.com<http://www.keil.com > | Address: Bretonischer Ring 16, 85630 Grasbrunn, Germany
Sitz der Gesellschaft: Grasbrunn | Handelsregister: München (HRB 175362) | USt-IdNr.: DE 187925309
Geschäftsführer: Joachim Krech, Reinhard Keil
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
