- TF-M - lists.trustedfirmware.org

by Bohdan.Hunko＠infineon.com

Hi all, I have tried building Extra S and NS tests from tf-m-extras repo for PSoC64 and the result I got is that device prints message that extra S test started and reboots. Here is the command line I used: cmake -S . -B build_psoc64 -G "Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DTFM_LVL=2 -DEXTRA_S_TEST_SUITES_PATHS=< tf-m-extras path>/examples/extra_test_suites_example/extra_s -DEXTRA_NS_TEST_SUITES_PATHS=<tf-m-extras path>/examples/extra_test_suites_example/extra_ns I have also tries building with following command line (same as before but -DTEST_S=ON and -DTEST_NS=ON added): cmake -S . -B build_psoc64 -G "Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DTFM_LVL=2 -DEXTRA_S_TEST_SUITES_PATHS=< tf-m-extras path>/examples/extra_test_suites_example/extra_s -DEXTRA_NS_TEST_SUITES_PATHS=<tf-m-extras path>/examples/extra_test_suites_example/extra_ns -DTEST_S=ON -DTEST_NS=ON The result is the same - message about starting Extra S test suite is printed and then device reboots. Could someone please test it on other platform and let me know whether Extra S and NS tests works there. 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>

3 years

2
1
0 0

Use original CMSIS files

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

3 years

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…>

3 years

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

3 years

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

3 years

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>

3 years

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…>

3 years

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>

3 years, 1 month

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

3 years, 1 month

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

3 years, 1 month

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

3 years, 1 month

2
1
0 0

Failure mode of protected storage with faulty NV counters?

by Jeremy Herbert

Hi, I am not too familiar with TF-M, so please forgive me if this is a silly question. The protected storage APIs appear to require the use of on-die flash to store a non-volatile counter that is used for rollback protection. This is severely limiting in terms of the number of writes, because basically you get as many writes as the endurance of the flash on the MCU (for example, the nordic cortex M33 devices have a rated write endurance of 10k cycles per page, and I don't think there is any wear levelling in TF-M). For example, assuming that a device was configured to write to the protected storage on boot, one could pretty easily exhaust this flash in a few hours by continuously power cycling it. Even if the 10k writes is a very conservative rating, it seems pretty likely that the counter flash will fail before UINT32_MAX. My question is: what happens to the security and functionality of the protected storage if the internal NV flash write fails silently? I don't know much about the semiconductor physics at play here, but presumably it could fail to make the counter a constant number, or fail to a random number. I had a quick look but there don't appear to be any checks in the code to ensure that a value was actually written correctly to the NV counters flash in case of silent corruption - it seems to just assume that any error would be detectable by some return code from the flash write driver. I was looking for some check like: if (value_to_write != value_read_back) return FLASH_WORN_OUT_ERROR; But I wasn't able to find it. So assuming it isn't actually there, if the counter fails to a constant (which is not UINT32_MAX) then presumably the rollback protection would be broken for all writes after that point (and maybe some before depending on the constant). If it fails to a random number, then it would be broken in a more "random" way - ie it would randomly work/not work depending on the value of the counter, until all UINT32_MAX numbers are randomly selected as the counter value. Also, given that typical AEAD ciphers like AES-GCM typically fail catastrophically with nonce reuse and the protected storage is indeed AEAD (though I can't quite work out yet which cipher is used), if these non-volatile counters are used to generate a nonce then potentially the encryption of the device could be broken just by rebooting the device until the flash is worn out, and then the nonce will be reused if the flash fails to a constant value. Could someone please help me clear up if my understanding here is correct? As is, I am struggling a bit to understand how to use the protected storage API in a secure way with this constraint, because if an attacker has any way to repeatedly cause a flash write it is basically game over. Any help would be greatly appreciated. Thanks, Jeremy

3 years, 1 month

4
15
0 0

Re: [TF-M] Supporting encryption with ITS

by Sherry Zhang

Hi George, The ITS without encryption is not a compromised RoT. In the PSA Secure Storage API spec, the PSA Internal Trust Storage aims at providing a place for devices to store their most intimate secrets. Also “””””””””””””””””””” 1. The storage underlying the PSA Internal Trusted Storage Service MUST be protected from read and modification by attackers with physical access to the device. 2. The storage underlying the PSA Internal Trusted Storage Service MUST be protected from direct read or write access from software partitions outside of the PSA Root of Trust (PRoT). “””””””””””””””””””” So, for internal trusted storage service, it requires the underlying storage itself should provide being read or write protection. The storage area should be a “trusted” area. Does the storage area on your device meet this requirement? Is the memory physically isolated? If not, I wonder why not uses the Protected Storage service instead? For the design of adding encryption in ITS, in the PS partition, the `iv` and the encrypted object data are stored with the object file while the tag of each object is stored with the object table file. So, if encrypt the PS object in the ITS file system, how the PS partition get the `tag` of each object? After a rough thought, I think probably a standalone encryption for ITS is more reasonable. As this is a relatively “big topic”, would you like to hold a discussion on the TF-M Tech forum if it is not limited by confidential information? The next Tech forum will be hold on this Thursday 3:00 PM UTC time. Regards, Sherry Zhang From: Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>> Sent: Friday, September 24, 2021 8:52 PM To: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Supporting encryption with ITS Hello Sherry, Thank you for your input! 1. Our threat model is more concerned about attacks which can happen very early in the boot process, I think. A completely compromised RoT is not in our threat model. 2. I see that, ITS is supposed to store small objects. The storage overhead of adding encryption will be probably bigger than 20 bytes I think but the intention is to have this only as a configuration, not as the default option. 3. Agreed, a HAL API should be used for this. Do you have any opinion on the design of it? Do you think that it adds value to do try to use a common design for the object handling of both PS and ITS or is it better to have it as a standalone thing for the ITS. Regards, George ________________________________ From: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>> Sent: Friday, September 24, 2021 11:58 AM To: Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: [TF-M] Supporting encryption with ITS Hi George, Some comments from my side: 1. Internal trusted storage is part of the Root of Trust domain. If ITS storage device is attacked, then the code flash where the PSA Rot SP locates may also be attacked. Does the thread model of your system require the encryption in ITS? 2. The ITS service is intended to be used to interface to a small piece of storage. Encryption would increase the context for each ITS file. For example, similarly to PS object context, the `IV` which is used in encryption as well as the generated `tag` should be added into each file context. They total together can be about more than 20 bytes. 3. If the encryption is mandatory/ necessary required by the thread model of your system, as discussed, the PSA crypto service should not be called to avoid the circular. I think a HAL API for encryption may be created in ITS for platform implementation defined encryption/decryption. Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vasilakis, Georgios via TF-M Sent: Thursday, September 23, 2021 10:47 PM To: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>; Fabian Schmidt <fabian.schmidt(a)nxp.com<mailto:fabian.schmidt@nxp.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Supporting encryption with ITS Hey Gyorgy, These are very valuable comments! I am aware of the circular dependency issue because the PSA apis are using the ITS as a storage backend. This, as you said, can be circumvented by using a software crypto library or an implementation specific API. So, for the encryption a flexible API can be used which can allow externals to use their own function calls. Regarding the key storage, this is what I had in mind as well, using derived keys from the HUK. So that we don't need to store anything but the crypto metadata. Adding another layer of storage will raise more issues, I think. ________________________________ From: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>> Sent: Thursday, September 23, 2021 4:30 PM To: Fabian Schmidt <fabian.schmidt(a)nxp.com<mailto:fabian.schmidt@nxp.com>>; Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: [TF-M] Supporting encryption with ITS Hi, AFAIK the main reason for ITS not using encryption is the problem of circular dependency. ITS is used by crypto SP for key storage, so how will crypto fetch the key from ITS to decrypt ITS? You could use a software crypto implementation (another mbed-tls instance) in ITS, but where would you safely store the keys? If you have a two layer ITS, one for only storing the keys for the second instance, and a second, encrypted one, then you end up with something like ITS and PS. You may not need a full blown on-chip FLASH device for ITS. If you have a HUK available, you can derive the same SP specific keys from that at each boot, and store these in RAM backed ITS. You won’t be able to store other keys in ITS in a persistent way of course, but for that you can use PS. Well, something along these lines. Perhaps the TF-M team could help better if you could share some details on why your customer would need encrypted ITS. (A PSA for Cortex-A (TS) maintainer chiming in to a “not his business” discussion here 😉 ) /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Fabian Schmidt via TF-M Sent: September 23, 2021 15:51 To: Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Supporting encryption with ITS Hi George, I’m wondering if that would add value. To my understanding, ITS was never designed to be encrypted because of the way it’s supposed to be set up. (It’s Internal Trusted Storage.) I believe best practice is to place it in a “trusted” location, one that is ideally only accessible from Secure world, and also ideally on-die. If you then restrict outside access to the internal flash (JTAG, flash programmer ports,…), you’re pretty golden, in that no unauthorized party should be able to read from or write to the ITS.* Let me know if I misunderstand anything about ITS or TrustZone, but that’s my view. Maybe I’m painting an idealized picture. Greetings, Fabian Schmidt * at least short of a sophisticated physical attack or finding some loophole in TrustZone… From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vasilakis, Georgios via TF-M Sent: Donnerstag, 23. September 2021 15:28 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [EXT] [TF-M] Supporting encryption with ITS Caution: EXT Email Hey all, Lately the requirement for an encrypted ITS solution is being asked from our customers and I would like to have a discussion here on how we can design this in a reasonable way. The first thought that came to my mind was to add the functionality to the ITS flash-fs layer. This layer contains file metadata in the its_file_meta_t structure and it should be possible to expand this to include additional crypto metadata (conditionally). This seems to be the less invasive change to me, even though it will introduce some increased memory usage since supporting encryption will mean that we cannot read the data in chunks anymore, we will have to use static buffers. At the same time, I looked at the PS partition since I knew that it has support for encryption. I believe that some core concepts of both solutions have similarities even though the code is quite different. For example, a file in ITS is similar to an object in PS and the (linear) list of file metadata in ITS is similar to the concept of the object table in PS. So, I think that it should be possible to design some generic-enough APIs that we can use for both the ITS and PS. Even though this will require some major refactoring in both partitions, it will decrease the code of these services which will probably decrease maintenance later. What are your thoughts on this? Regards, George

3 years, 1 month

6
16
0 0

Re: Status of RSS platform?

by Maulik Patel

Hi Chris, RSS build requires new runtime Measured Boot Service. This service partition is not yet part of PSA specification and hence it resides in the tf-m-extras repository. (https://git.trustedfirmware.org/TF-M/tf-m-extras.git/) For out of tree partition build, if you map the tf-m-extras repo and provideTFM_EXTRA_MANIFEST_LIST_FILES =<path_to_measured_boot_manifest_list.yaml> and TFM_EXTRA_PARTITION_PATHS=<path_to_measured_boot_partition> (example as below), then it should fix build issue. -DTFM_EXTRA_MANIFEST_LIST_FILES=../../tf-m-extras/partitions/measured_boot/measured_boot_manifest_list.yaml -DTFM_EXTRA_PARTITION_PATHS=../../tf-m-extras/partitions/measured_boot If the error persists, could you please send me the build options you are using and I'll look into this further. Best Regards, Maulik ________________________________ From: tf-m-request(a)lists.trustedfirmware.org <tf-m-request(a)lists.trustedfirmware.org> Sent: Wednesday, September 7, 2022 1:00 AM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: TF-M Digest, Vol 47, Issue 7 Send TF-M mailing list submissions to tf-m(a)lists.trustedfirmware.org To subscribe or unsubscribe via email, send a message with subject or body 'help' to tf-m-request(a)lists.trustedfirmware.org You can reach the person managing the list at tf-m-owner(a)lists.trustedfirmware.org When replying, please edit your Subject line so it is more specific than "Re: Contents of TF-M digest..." Today's Topics: 1. Status of RSS platform? (Chris.Brand(a)infineon.com) ---------------------------------------------------------------------- Message: 1 Date: Tue, 6 Sep 2022 21:48:05 +0000 From: <Chris.Brand(a)infineon.com> Subject: [TF-M] Status of RSS platform? To: <tf-m(a)lists.trustedfirmware.org> Message-ID: <2441d128df93483abc1da39c38e89885(a)infineon.com> Content-Type: multipart/alternative; boundary="_000_2441d128df93483abc1da39c38e89885infineoncom_" Hi, I'm wondering what the status of the RSS platform is. I tried to build it from the current HEAD of master and also from a few earlier commits, and cannot get it to build (I get an error about TFM_MEASURED_BOOT_SID being undeclared in some of the generated code). I was curious about the implementation of tfm_hal_get_mem_security_attr(), tfm_hal_get_secure_access_attr() and tfm_hal_get_ns_access_attr() on an ARMv8 multi-core platform, but there doesn't currently seem to be an implementation of those HAL functions. Thanks, Chris Brand Cypress Semiconductor (Canada), Inc. An Infineon Technologies Company Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com> International Place 13700 V6V 2X8 Richmond Canada www.infineon.com<www.cypress.com<http://www.cypress.com>> www.cypress.com<http://www.cypress.com> Discoveries<http://www.infineon.com/discoveries> Facebook<http://www.facebook.com/infineon> Twitter<http://www.twitter.com/Infineon> LinkedIn<http://www.linkedin.com/company/infineon-technologies> Part of your life. Part of tomorrow. NOTICE: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material of Infineon Technologies AG and its affiliated entities which is for the exclusive use of the individual designated above as the recipient. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact immediately the sender by returning e-mail and delete the material from any computer. If you are not the specified recipient, you are hereby notified that all disclosure, reproduction, distribution or action taken on the basis of this message is prohibited.

3 years, 1 month

3
3
0 0

TF-M configurability

by Anton Komlev

Hello, Recently we discussed the movement of relevant options into C header files as a potential configuration improvement. By this mail thread, I would like to provoke discussion on what else we are lacking in TF-M configurability and thoughts to make it better. Please share your ideas to review them in the upcoming tech forum. Thanks, Anton

3 years, 1 month

2
2
0 0

Status of RSS platform?

by Chris.Brand＠infineon.com

Hi, I'm wondering what the status of the RSS platform is. I tried to build it from the current HEAD of master and also from a few earlier commits, and cannot get it to build (I get an error about TFM_MEASURED_BOOT_SID being undeclared in some of the generated code). I was curious about the implementation of tfm_hal_get_mem_security_attr(), tfm_hal_get_secure_access_attr() and tfm_hal_get_ns_access_attr() on an ARMv8 multi-core platform, but there doesn't currently seem to be an implementation of those HAL functions. Thanks, Chris Brand Cypress Semiconductor (Canada), Inc. An Infineon Technologies Company Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com> International Place 13700 V6V 2X8 Richmond Canada www.infineon.com<www.cypress.com> www.cypress.com<http://www.cypress.com> Discoveries<http://www.infineon.com/discoveries> Facebook<http://www.facebook.com/infineon> Twitter<http://www.twitter.com/Infineon> LinkedIn<http://www.linkedin.com/company/infineon-technologies> Part of your life. Part of tomorrow. NOTICE: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material of Infineon Technologies AG and its affiliated entities which is for the exclusive use of the individual designated above as the recipient. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact immediately the sender by returning e-mail and delete the material from any computer. If you are not the specified recipient, you are hereby notified that all disclosure, reproduction, distribution or action taken on the basis of this message is prohibited.

3 years, 1 month

2
1
0 0

Reproducible test builds

by Bøe, Sebastian

Hello, when building TF-M you get the same result no matter what computer you build from assuming all the tooling is the same version. The builds are reproducible in other words. But when building TF-M together with the tests, e.g. by building the regression test suite you will get a different binary depending on where in the filesystem the tf-m-tests repository has been installed. This is because the TEST_FAIL macro uses the gcc macro _FILE_ which injects the absolute paths of source files into strings in the binary. This is a big problem for people using CI systems as a different sized binary can affect race conditions, flash region usage overflows, etc.. I think we should make builds reproducible by default, possibly with a configuration for adding absolute paths into the binary for those that prefer so. I would like to write a patch to this affect, but would prefer to get some feedback now so I don't have to re-write it in review. The simplest solution is to remove __FILE__ from the TEST_FAIL macro,but this would remove useful information and may also fail in the future if someone else uses __FILE__. The more common way of solving this problem is to add a flag to the compiler that instructs it to replace any occurrences of the absolute path with something else during macro expansion. For instance replace "C:/repos/tf-m-tests/source_file.c" with "TFM_TESTS/source_file.c". For gcc the flag is -fmacro-prefix-map=<old_string>=<new_string>. I don't know what the flag is for the other supported compilers or if they support it at all. Would it be OK to only support reproducible builds for the compilers that support an equivalent of macro-prefix-map?

3 years, 1 month

2
4
0 0

What do you think using configuration headers in TF-M ?

by Anton Komlev

Hello, TF-M has many options to configure. All of them are declared as a CMake variables and many of them translated to compiler definitions later. Since the idea of TF-M configuration via config header file(s) was warmly received on the last tech forum I would like to check with community opinion on such hypothetical move: Configure TF-M via definitions in header files while leave CMake for a building control only. Please share your thoughts, opinions and the possible dependencies. Thanks, Anton

3 years, 2 months

6
9
0 0

[RFC] Fault Injection Hardening (FIH) re-enablement on AN521 are ready for review

by Ken Liu

Hello, The FIH functionality reference implementation on AN521 was there before, and then get turned off last year because it increases the effort of updating the HAL interface. Now the HAL interface update is done, this functionality is re-enabled on AN521, based on the updated HAL. The patches are pushed for your review: https://review.trustedfirmware.org/q/topic:%22FIH_AN521_RE%22+(status:open%… The mechanism is mainly the same as the previous implementation, The document is under modifying to reflect the re-enablement changes but still can be read to recall the general concept: https://tf-m-user-guide.trustedfirmware.org/technical_references/design_doc… Please leave your comments in the patches or do overall discussions in this mail thread. Thanks! /Ken

3 years, 2 months

1
0
0 0

AN524 Flash_Driver issue consult

by jidong.mei＠armchina.com

Hi All : I'm developing Flash Driver for TF-M AN524 demo , and trobuled by some code logic . It's that : For , AN524 , PS storage Area is redirect to BRAM , so PS area related read and write can be done using memcpy without Flash driver being implementened . see : platform/ext/target/arm/mps3/an524/cmsis_driver/Driver_Flash.c /* Redirecting PS storage to BRAM */ if (addr >= FLASH_REDIRECT_BASE && addr <= FLASH_REDIRECT_LIMIT) { start_addr = FLASH_REDIRECT_DEST + (addr - FLASH_REDIRECT_BASE); /* PS Flash is emulated over BRAM. use memcpy function. */ memcpy((void *)start_addr, data, cnt); } else { /* Flash driver for QSPI is not ready */ return ARM_DRIVER_ERROR_UNSUPPORTED; } My question is : What the purpose of "else" branch above ? After I implement QSPI driver , in "if" branch , I remove redirect operation , and use Flash Write APIs to replace memcpy func. Then , shoud "else" branch be removed? Or , should I put Flash write driver in "else" branch , and keep "if" branch the same with origion? Best regards, Jidong Mei

3 years, 2 months

2
2
0 0

CMSIS in TF-M

by Chris.Brand＠infineon.com

TF-M includes platform/ext/cmsis, which is CMSIS v5.9.0 with some TF-M-specific changes. Looking at the history for that directory, it seems that we periodically update it and have to re-apply the TF-M-specific changes (which looks to be the naming of the stack and the copy table size). I'm wondering whether there's a plan to either push the TF-M changes into upstream CMSIS or to change TF-M so that they're not needed? It would be nice to just pull CMSIS from upstream like we do with other external libraries... Chris Brand Cypress Semiconductor (Canada), Inc. An Infineon Technologies Company Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com> International Place 13700 V6V 2X8 Richmond Canada www.infineon.com<www.cypress.com> www.cypress.com<http://www.cypress.com> Discoveries<http://www.infineon.com/discoveries> Facebook<http://www.facebook.com/infineon> Twitter<http://www.twitter.com/Infineon> LinkedIn<http://www.linkedin.com/company/infineon-technologies> Part of your life. Part of tomorrow. NOTICE: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material of Infineon Technologies AG and its affiliated entities which is for the exclusive use of the individual designated above as the recipient. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact immediately the sender by returning e-mail and delete the material from any computer. If you are not the specified recipient, you are hereby notified that all disclosure, reproduction, distribution or action taken on the basis of this message is prohibited.

3 years, 2 months

2
1
0 0

ITS/PS improvements

by Roman.Mazurak＠infineon.com

Hello all, I made a patch (https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/16214) that reorganize interaction between ITS partition, ITS file system and ITS flash driver. 1. ITS flash driver interface is decoupled from ITS file system. 2. ITS flash driver interface isn't dependent on upper layers like ITS FS or ITS. 3. ITS flash driver emulated in RAM (its_flash_ram) can be used without CMSIS flash driver even in production environment if needed. 4. Target can provide own implementation of ITS flash driver without implementing CMSIS flash driver. Which can be more flexible or simple in some cases. 5. Allocation of ITS flash driver instance by ITS partition is not dependent on lower layers like CMSIS driver. ITS partition uses abstract flash driver interface to bind ITS file system and driver instance. This changes gives following benefits. 1. Vendors can provide ITS flash driver without need to create an intermediate CMSIS flash driver. 2. It's possible to implement ITS encryption by adding a new ITS flash driver that performs encryption and uses existing drivers (NOR, NAND, RAM, platform specific) as the storage backend. 3. It's possible to use ITS file system + ITS encryption driver (b) for Protected Storage directly without additional context switching during access to PS file system handled by ITS partition. I think it should improve performance of PS. 4. Use ITS file system directly in application specific custom partitions by allocating ITS file system context and ITS flash driver. Best regards, Roman.

3 years, 2 months

1
0
0 0

Service vs Partition wording in manifest files

by Bohdan.Hunko＠infineon.com

Hi everyone, From what I see manifest lists (e.g. tools/tfm_manifest_list.yaml) describe partitions, but "name" field there (which is a description of the partition) uses "Service" word, for example: "name": "Protected Storage Service", Shouldn't this be "name": "Protected Storage Partition" ? Why do TFM uses Service when describing the Partition? 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>

3 years, 2 months

3
12
0 0

TF-M Tech Forum minutes / upcoming Tech Forums calendar

by Don Harbin

Hi All, A gentle reminder that past TF-M Tech Forum minutes/recordings including the last one from August 4th can be found *here <https://www.trustedfirmware.org/meetings/tf-m-technical-forum/>* . Also, the public calendar that includes upcoming TF-M tech forums can be found *here* <https://www.trustedfirmware.org/meetings/>. Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

3 years, 2 months

1
0
0 0

Request about local test with IAR compiler

by Jianliang Shen

Hi, I made a patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/16106> to change CMSIS-RTOS RTX library attribute for ARMv8-M Mainline platforms in TF-M, the reference is CMSIS-RTOS2<https://www.keil.com/pack/doc/CMSIS/RTOS2/html/pDirectory_Files.html#libFil…>. As CI doesn't cover IAR compiler, I'm very grateful if someone who is convenient can help me build and run it with IAR toolchain locally. Best Regards Jianliang Shen

3 years, 2 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M