- TF-M - lists.trustedfirmware.org

by david.hazi＠arm.com

Hi all, We've created a change, which is using original CMSIS headers in TF-M. Current patch is only for arm/mps3/an552 platform. Our plan is to create a public review only for this (which will NOT be merged), and after the review, we would like to extend this patch to all of the platforms. The main changes in the chain: - copy and zero_table size fix in the GNU linker scripts and initial startup code - Removed __INITIAL_SP and __STACK_LIMIT patch form gcc and iar cmsis files, NS linker scripts using CMSIS style naming, the secure and bl2 build's linker scripts remains untouched (ARMCLANG style naming, __INITIAL_SP and __STACK_LIMIT patched with cmsis_stack_override interface library) - NS process stack removed from NS linkers (PSP) - Common startup file for bl2 and ns builds - Add original cmsis headers, updated system and startup files - Stack sealing done twice, once from startup (to resemble CMSIS startup template) and once from TF-M secure main Feedback is welcome: https://review.trustedfirmware.org/q/topic:%2522use-original-cmsis-headers%… David Hazi

2 years, 10 months

2
3
0 0

TF-M psa crypto test do not set the algorithms in psa_key_attributes_t

by Swarowsky, Markus

Hello, I was adding sanity checks to the psa_crypto_driver_wrappers to validate bits/type and policy->alg of the given psa_key_attributes_t attributes for the psa_generate_key, psa_import_key, and psa_copy_key calls. To check it the given combination is within the psa specification. In the PSA crypto spec it says: The key permitted-algorithm policy is required for keys that will be used for a cryptographic operation, see Permitted algorithms<https://armmbed.github.io/mbed-crypto/html/api/keys/policy.html#permitted-a…>. [https://armmbed.github.io/mbed-crypto/html/api/keys/management.html?highlig…] Which is most likely the case for all key types except of PSA_KEY_TYPE_RAW_DATA But after adding the sanity checks the TF-M crypto tests(test_c*_testing_* and TFM_S/NS_CRYPTO_TEST_10*) failed. I took a look at these tests, it turned out that they don't set the algorithm flag for the key attributes. My question now is, is the algorithm flag skipped on purpose or just missed during the test case creation as It should be set according to the psa crypto spec? Thanks for the help and the feedback Markus Swarowsky | R & D Engineer M +47 404 66 922 | Trondheim, Norway nordicsemi.com<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.nordic…> | devzone.nordicsemi.com<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdevzone.n…> Facebook<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.faceb…> | LinkedIn<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linke…> | Twitter<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.c…> | YouTube<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtu…> | Instagram<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.insta…> [Nordic_logo_signature]<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.nordic…>

2 years, 11 months

2
5
0 0

TF-M Open CI Unstable

by Xinyu Zhang

Hi, TF-M Open CI is unstable for the time being because of the ArmClang license issue in Jenkins. Sorry for any inconvenience! I'll let you know once it is back to normal. Thanks, Xinyu

2 years, 11 months

1
1
0 0

[RFC]Moving faults handlers to dedicated file

by Kevin Peng

Dear platform owners, I'm moving faults handlers to dedicated files from spm_hal.c as this file should be for Library Model only. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/16858 Please check your platforms respectively. Plan to merge it on next Monday. Best Regards, Kevin

2 years, 11 months

1
0
0 0

Level 3 Isolation improvements

by Bohdan.Hunko＠infineon.com

Hi everyone, I have several questions related to L3 isolation in TFM. First of all, FFM specifies that: * In L3 PSA RoT partitions does not need to be isolated from SPM (and vice versa) * PSA RoT partitions does not need to be isolated from each other * PSA RoT partitions and SPM must be isolated from APP RoT partitions * APP RoT partitions must be isolated from each other This picture from TFM docs<https://tf-m-user-guide.trustedfirmware.org/docs/technical_references/desig…> seem to illustrate statements above. Currently platforms with L3 support (e.g. an521) follow the rules stated above. They achieve this by executing PSA RoT partitions and SPM in privileged mode, and APP RoT partitions in unprivileged mode. Partition boundaries are only updated when switching to APP RoT partition. From description of tfm_hal_activate_boundary (see code here<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…>) and this an521 code<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…> seems like platform can determine whether partition will be executed in privileged or unprivileged mode. So my questions are: 1. For improved isolation in L3 does it make sense to: * isolate SPM from PSA RoT partitions * isolate PSA RoT partitions from each other (like APP RoT partitions are isolated) 1. If question 1 make sense then can platform achieve this improved isolation with current code base? From this an521 code<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…> it seems like platform may set all partitions to be executed in unprivileged mode and dynamically switch boundaries between them (between both PSA and APP RoT partitions). SPM will remain in privileged mode. It seems like this approach is possible with minor changes to SPM. For example this code will need<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…> to be changed to call tfm_hal_activate_boundary regardless of partition privilege level. Are there any other changes needed to make this approach work? Regards, Bohdan Hunko Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>

2 years, 11 months

2
5
0 0

Enable stack protection in the regression tests

by Swarowsky, Markus

Hey, While trying to debug a crash in the TF-M regression tests, I noticed that the msplim_ns register is set to 0x0, leaving the non-secure application without any stack to protection, sadly I wasn't able to figure out how to enable the stack protection, which would be nice as we suspect that a stack overflow could cause the crash. Therefore, I would be interested if it possible to enable stack protection for the non-secure application of the TF-M regression tests and if so, how? Thanks for the help Markus Swarowsky | R & D Engineer M +47 404 66 922 | Trondheim, Norway nordicsemi.com<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.nordic…> | devzone.nordicsemi.com<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdevzone.n…> Facebook<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.faceb…> | LinkedIn<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linke…> | Twitter<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.c…> | YouTube<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtu…> | Instagram<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.insta…> [Nordic_logo_signature]<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.nordic…>

2 years, 11 months

5
4
0 0

Partition assets attributes

by Bohdan.Hunko＠infineon.com

Hi everyone, I have several questions related to partition assets attributes. FFM specifies 2 types of assets (mmio_regions): * Named MMIO region * Numbered MMIO region FFM does not really specify the use cases for these 2 different types. I expect that Named region is only used for peripherals and numbered region is only used for memory regions. Am I right here? If no, then what the use cases for these 2 types are and what is currently supported in TFM? Also I see that in tools/templates/partition_load_info.template lines 221-224 ASSET_ATTR_NUMBERED_MMIO or ASSET_ATTR_NAMED_MMIO are assigned for assets from manifest files depending on their type, but tools/templates/partition_load_info.template#187<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/tools/temp…> does not assign any of these attributes for "PART_REGION_ADDR(PT_{{manifest.name}}_PRIVATE, _DATA_START$$Base)" at isolation level 3. Is this some a bug or I am missing some knowledge on this mmio_regions stuff? Regards, Bohdan Hunko Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>

2 years, 11 months

2
3
0 0

TF-M Library model deprecation proposal

by Anton Komlev

Hello, Following tech forum today and the presentation on August 18 (to be published asap), I propose to deprecate TF-M library model as an obsolete and replace it with SFN model as a successor. PSA compliant SFN and IPC, defined in FF_M will then be the 2 supported models in TF-M going forward. Please share your thoughts and concerns on the proposal. Having no objections, we will depreciate the Library model after October 1 and it will be removed in TF-M v1.7.0 Thanks, and best regards, Anton

2 years, 11 months

1
1
0 0

Template implementations used in production

by Bøe, Sebastian

Hi, we wish to avoid the pitfalls of "doing your own security", and at the same time not use dummy/template code that is not meant for production. May I ask if it is still accurate what the docs say here about the template folder, namely that nothing in the template folder should be used in production without being ported first? This directory contains platform-independent dummy implementations of the interfaces in platform/include. These implementations can be built directly for initial testing of a platform port, or used as a basic template for a real implementation for a particular target. They must not be used in production systems. $ ls platform/ext/common/template/ attest_hal.c flash_otp_nv_counters_backend.c otp_flash.c tfm_initial_attest_pub_key.c crypto_keys.c flash_otp_nv_counters_backend.h tfm_fih_rng.c tfm_rotpk.c crypto_nv_seed.c nv_counters.c tfm_initial_attestation_key.pem tfm_symmetric_iak.key

2 years, 11 months

2
1
0 0

SFN non-secure interface sources

by Andersson, Joakim

Hi. I was testing the SFN model on the TF-M 1.6 release and I am confused about which API source files should be used for the non-secure application. The documentation here is lacking, so I am going by what we do in the build scripts of TF-M and tf-m-tests. The non-secure source files that are exported and included in the nonsecure API library are tfm_<partition>_ipc_api.c. This strikes me as odd, to use the IPC source files for the SFN model. If this is correct the naming is misleading. From the code the selection is done based on PSA_API definition. Based on this if this is the correct source files to use then I would think this should either be documented or renamed to something that better reflect the use, perhaps tfm_<partition>_psa_api.c? In the documentation there is a lot of room for improvements, the existence of tfm_<partition>_secure_api.c could lead to confusion since it is not always well described. tfm_attestation_integration_guide.rst: System integrators might need to port these interfaces to a custom secure partition manager implementation (SPM). Implementations in TF-M project can be found here: - ``interface/src/tfm_initial_attestation_func_api.c``: non-secure interface implementation for library model - ``interface/src/tfm_initial_attestation_ipc_api.c``: non-secure interface implementation for IPC model - ``secure_fw/partitions/initial_attestation/tfm_attestation_secure_api.c``: secure interface implementation Here it is not clear to me what "secure interface implementation" means, it could be interpreted as the SFN API. tfm_crypto_integration_guide.rst: - ``tfm_crypto_secure_api.c`` : This module implements the PSA Crypto API client interface exposed to the Secure Processing Environment Here it is clearer that tfm_<partition>_secure_api.c is the interface to the SPE. However the documented NSPE interface source file does not even exist, and does not explain the IPC / FUNC difference: | NSPE client API interface | This module exports the client API of PSA Crypto to the NSPE | ``./interface/src/tfm_crypto_api.c`` tfm_fwu_service.rst: | NSPE client API interface | This module exports the client API of PSA Firmware Update to | ``./interface/src/tfm_firmware_update_func_api.c`` | | | the NSPE(i.e. to the applications). | ``./interface/src/tfm_firmware_update_ipc_api.c`` | Here it is mentioned the two possible source files, but it is not specified when to use which source file. Generally: Between all the services this is not consistently listed, for example the tfm_its_service.rst file does not have the table of source files. If there is a general description of the non-secure interface sources, I couldn't find it. -Joakim AnderSSON

2 years, 11 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M