- TF-M - lists.trustedfirmware.org

Lost data when overwriting object using its_set?

by Stefan Krug

Hello! While playing around with TF-M I have stumbled upon unexpected behavior: In a sequence of ITS api calls like: a.) psa_its_set(TEST_UID_1, sizeof(write_data_1), write_data_1, PSA_STORAGE_FLAG_NONE); b.) psa_its_set(TEST_UID_2, 0, NULL, PSA_STORAGE_FLAG_NONE); c.) psa_its_remove(TEST_UID_1); d.) psa_its_set(TEST_UID_2, sizeof(write_data_2), write_data_2, PSA_STORAGE_FLAG_NONE); e.) psa_its_get(TEST_UID_2, 0, sizeof(read_data_2), read_data_2, &read_data_length); with #define TEST_UID_1 2U #define TEST_UID_2 3U const uint8_t write_data_1[] = "ONE"; const uint8_t write_data_2[] = "TWO"; It seems that step e) does not return the data written in step d). I believe I have root-caused it to an issue in its_flash_delete_idx() (see below), but since this is a rather straightforward API call sequence, I wonder whether this is not rather an issue in my environment and would be glad if someone could confirm it or point me to a direction of a potential different cause? I am using TF-M version 1.6, a nor flash with (erase) block size 0x1000 bytes and a program unit size (page size) of 0x100 bytes. Thank you, best regards Stefan Krug More analysis details: After step c) there will be the following relevant metadata blocks in the filesystem: 1.) unused metadata block (used to have the metadata of TEST_UID_1) 2.) metadata block of TEST_UID_2 During step d) the update of TEST_UID_2 is done in two steps - first step is to write metadata + content of TEST_UID_2. After this step, the metadata blocks look like: 1.) NEW metadata block of TEST_UID_2 2.) old metadata block of TEST_UID_2 (indicating TEST_UID_2 to be erased) The second step is to delete the outdated file, and compact/defragment the data in the file system. This is done in its_flash_fs_delete_idx(). its_flash_fs_delete_idx will collect the amount of data bytes to preserve. There are two parts of data to be preserved, a chunk of data before the deleted file (of size del_file_data_idx) and a chunk of data after the deleted file. Calculation of del_file_data_idx is done by taking the start offset of the to-be-deleted file. In this particular situation the start of the old TEST_UID_2 is the same as the start of the new TEST_UID_2. The subsequent its_flash_fs_dblock_compact_block will only keep data up to del_file_data_idx - in this case it will NOT keep the data of the new TEST_UID_2 - this data is lost.

4 years

2
1
0 0

Latest status of S/NS build split PoC

by David Hu

Hi all, I rebase and update the S/NS build split PoC as requests. Could you please take a look at the latest patch set if you are interested? Trusted-firmware-m part: https://review.trustedfirmware.org/q/project:TF-M%252Ftrusted-firmware-m+br… Tf-m-tests part: https://review.trustedfirmware.org/q/project:TF-M%252Ftf-m-tests+branch:mas… The general idea was presented in https://www.trustedfirmware.org/docs/tf-m_forum_20220120_Restructure_TF-M_b… while some details are improved in code. Any comment and feedback is welcome! Best regards, Hu Ziji

4 years

1
0
0 0

TFM_PARTITION_AUDIT_LOG references in the code after Lib Model deprecation

by Bohdan.Hunko＠infineon.com

Hi all, TFM Library model has been deprecated, thus AUDIT logging partition has been deleted, but I still see a reference to that partition in config/check_config.cmake lines 102-103: #Audit log is not supported in IPC model, disable it by default tfm_invalid_config(TFM_PARTITION_AUDIT_LOG) Looks like this should be removed or comment fixed. An I missing something or this is a mistake that should be fixed? 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>

4 years

3
2
0 0

an521 L3 protection setting questions

by Bohdan.Hunko＠infineon.com

Hi all, I have a few questions regarding an521 platform protection settings for Level 3 isolation. In platform/ext/target/arm/mps2/an521/tfm_hal_isolation.c there is an const static struct mpu_armv8m_region_cfg_t region_cfg[] - for L3 it specifies to protect: * Code (from Image$$PT_RO_START$$Base to Image$$PT_RO_END$$Base) to be accessible in both PRIV and UNPRIV states. * PSA RoT partitions data in RAM (from Image$$PT_PRIV_RWZI_START$$Base to Image$$PT_PRIV_RWZI_END$$Base)to be accessible only in UNPRIV state. * TFM_SP_META_PTR to be accessible in both PRIV and UNPRIV states. Also in this file mpu_armv8m_enable() function call specifies PRIVILEGED_DEFAULT_ENABLE for MPU. I have following question to this configuration * Does this configuration mean that in L3 PSA RoT code is not isolated from APP RoT (APP RoT can read/execute PSA RoT domain code)? * How SPM data (TFM_BSS and TFM_DATA sections from scatter file) is protected? I cant see it being protected by MPU. * Is it skipped because PRIVILEGED_DEFAULT_ENABLE is set which means that SPM will be able to access this data and this allows to save one MPU region? * If so then why MPU region is used for PSA RoT partitions data? 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>

4 years

2
2
0 0

[RFC]Library Model deprecation

by Summer Qin

Hi, We plan to merge Library Model deprecation patches<https://review.trustedfirmware.org/q/topic:%22library-model-deprecation%22+…> this Friday since some other development work depends on this. May I ask for a review on these patches? Best Regards, Summer

4 years

2
1
0 0

Open CI Infrastructure in Maintenance

by Xinyu Zhang

Hi, Open CI infrastructure is in an emergency maintenance. Tests will be impacted. I'll let you know once it is back to normal. Best Regards, Xinyu

4 years

1
1
0 0

State of Extra tests

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>

4 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

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

4 years, 1 month

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

4 years, 1 month

1
1
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M